[afranchuk]

Really neat. I've been working on a lazy parallel language and so I read the "HOW" document closely to see the secret sauce. What's exciting to me is that, while I'm not familiar with the academia behind their decisions, it seems that I arrived at the same result with regard to their lazy clones: I realized early in the language that caching the eval results would make things really fast, and this caching ends up doing exactly what their lazy clones achieves!

Of course one place I don't cache is in function application because the language is not pure (so we want side effects to occur again), but this makes me think it might be really good to derive which functions/subexpressions are pure and allow the cache to be retained through function calls for those.

I'm gonna keep a close watch on this. I should probably read more white papers :)

[chriswarbo]

> I realized early in the language that caching the eval results would make things really fast, and this caching ends up doing exactly what their lazy clones achieves!

Sounds similar to the evaluation model of the Nix expression language (the pure functional programming language used by the Nix package manager). It caches evaluation results, which (a) avoids re-computing identical expressions, and (b) allows some infinite loops to be detected.

See https://www.researchgate.net/publication/222827743_Maximal_L...

[afranchuk]

Thanks for bringing that up! I suspected that nix did that, but wasn't sure. This language is also a "task runner" (being used for build systems mainly), so it's not surprising that it behaves like nix does.

[LightMachine]

Thank you!