What are the limitations?

[RaoulSchaffranek]

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 to true w.r.t call-by-value or call-by-need, but to false w.r.t. call-by-name (the same holds for == and Object.is). There are at least two possible solutions to this problem:

• Completely give up on objects and symbols and stay only with primitive values.
• Suspend === 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?

[steida]

@RaoulSchaffranek Just for fun, your surname comes from Czech language, it's Šafránek :-)

[devinrhode2]

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.