Repository navigation
Custom num-encodings create unexpected eagerness #110
Description
Activity
Most elegant fix is
exportingparse.Normal users don't need or want it, but defining custom numEncodings is arguably outside the scope of normal use anyway.
One could, of course, get stuck in an endless loop when using numeric literals in source code for
fromInt, but don't do that and you'll be fine. This is howfromIntis meant to function; usingLC.compileforfromIntis a kludge that relies on feeding JS toevalLC, instead of AST.LC.parsehas access to all the constructors it needs.I've tested it locally and it works.
A custom
fromIntwould look somewhat likeconst fromInt = n => LC.parse( "number = " + function go(n) { if ( n ) if ( n&1 ) return String.raw`\ _zero _bit0 bit1 . bit1 ${ go(-(n>>1)) }`; else return String.raw`\ _zero bit0 _bit1 . bit0 ${ go(-(n>>1)) }`; else return String.raw`\ zero _bit0 _bit1 . zero`; } ( n ) ).getValue("number").term ;
solved by #111. needs to be deployed yet, but the source tree now allows importing the parser. closing.
Custom number encodings which use other compiled LC terms create awkward and unnecessary "layers of eagerness".
As an example, this code creates a dummy number encoding in which every number is represented as
K. TheKis compiled as LC to retain laziness, but due to the "layer of eagerness" caused by the wrapper function aroundKin Javascript, each argument to K is eagerly evaluated and so the test fails with an evaluation error.Potential fixes would be:
a) Improve the logic of
fromIntto detect LC wrapper functions, and to use the underlying term directly (removing the eagerness layer)b) Add an explicite alternative
fromIntwhich is expected to return a LC termc) Allow
fromIntto accept strings, which it could compile itself into LC terms to use (??)