This repository has been archived by the owner on Jun 22, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 33
What are the limitations? #15
Comments
@RaoulSchaffranek Just for fun, your surname comes from Czech language, it's |
The goal stated in the readme is to get "as close to an idealised pure functional language as possible" ... "without becoming a subset of itself." However, I think it would be great if the readme included a link to a wiki, thread, or blog post talking about what that idealised language could be. ReasonML might fit the bill, but I think developers would like a well written argument for why that might be the case. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi,
i'm excited about the objective and limitations of your project. I wrote my Bachelor Thesis earlier this year about a purely function subset of EcmaScript2015. There, i discovered that comparisons for object-identity naturally conflict with purity. For example, the expression
(x => x === x)({})
evaluates totrue
w.r.t call-by-value or call-by-need, but tofalse
w.r.t. call-by-name (the same holds for==
andObject.is
). There are at least two possible solutions to this problem:===
and everything, which depends on object-identity.In absense of a value-based notion of equality both of these limitations would clearly make the target-language impractical. Another limitation today is, that nearly all of the APIs which deal with effects (like I/O) depend on side-effects. Do you have any thoughts on how to gap these parts?
The text was updated successfully, but these errors were encountered: