lambda-calculus icon indicating copy to clipboard operation
lambda-calculus copied to clipboard

Use `BigInt` instead of `Number` internally

Open JohanWiltink opened this issue 1 year ago • 2 comments

There is no reason to limit numbers to 2**32 or 2**53 ( this limit has already been exceeded in the wild), and floats are unsupported anyway ( negative numbers, however, have, with a Custom numEncoding, already actually been used in anger :] ). Binary Scott numEncoding has handled at least 2**600 in the wild.

The parser and compiler should use BigInts instead of Numbers internally.

JohanWiltink avatar Jan 06 '24 00:01 JohanWiltink

BigInt should probably be used externally as well. It's not possible to mix the two in JS, and (1) they're gonna leak and (2) you need them to support possible return values anyway ( because you can't mix. defining a custom encoding will leak - see (1) ).

I see no backwards compatible way to do this, so two language versions would have to be available ( temporarily ) on CW.

JohanWiltink avatar Feb 08 '24 00:02 JohanWiltink

It might be possible to have not only toInt and fromInt but toBigInt and fromBigInt as well in a custom numEncoding, use Number internally for now and BigInt later, and explicitly convert all values in testing code. By not relying on implicit coercion between JS and LC values, Number and BigInt may be kept separate, number literals in code can be handled up to the precision of the internal representation, and LC return values can be Number where possible and BigInt where necessary.

toBigInt and fromBigInt may even be supported in the LC object by checking the incoming datatype and acting accordingly.

I'll be trying to translate https://www.codewars.com/kata/fractran-interpreter-1 ( again ) as a proof of concept. I abandoned an earlier attempt because of problems mixing Number and BigInt.

JohanWiltink avatar Feb 08 '24 01:02 JohanWiltink