Repository navigation
Custom num-encodings create unexpected eagerness #110
Description
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. The K is compiled as LC to retain laziness, but due to the "layer of eagerness" caused by the wrapper function around K in Javascript, each argument to K is eagerly evaluated and so the test fails with an evaluation error.
import { assert, LC, getSolution } from "./lc-test.js";
const { K } = LC.compile(String.raw`
K = \ k _ . k
`);
const toInt = () => 0;
const fromInt = () => K;
LC.configure({ purity: "Let", numEncoding: {toInt, fromInt}, verbosity: "Concise" });
const { foo } = LC.compile(String.raw`
True = \ a _ . a
foo = 0 True ()
`);
describe("Example", () => {
it("example tests", () => {
assert.strictEqual( foo(true)(false), true );
});
});Potential fixes would be:
a) Improve the logic of fromInt to detect LC wrapper functions, and to use the underlying term directly (removing the eagerness layer)
b) Add an explicite alternative fromInt which is expected to return a LC term
c) Allow fromInt to accept strings, which it could compile itself into LC terms to use (??)
Activity
JohanWiltink commentedon Sep 4, 2025
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.JohanWiltink commentedon Sep 16, 2025
I've tested it locally and it works.
A custom
fromIntwould look somewhat likeJohanWiltink commentedon Sep 21, 2025
solved by #111. needs to be deployed yet, but the source tree now allows importing the parser. closing.