shelby3
commented
7 years ago The problem is how to side-step the purity and lack of imperativity of PureScript while gaining its typechecker.
I thought about employing the FFI in that for the body of every function we emit, we place it in a JavaScript function and call it from the body of the emitting PureScript function. But then we lose typechecking within the body of the function, which we need in order for PureScript to typecheck the call sites.
Perhaps we could devise some transpiling (without type checking on our end?) from our syntax to the do notation? Probably not. :disappointed:
Closing this because it is not feasible to do without building a type checker, which defeats the point.
I need a working language pronto. As in last week I needed it. Not next week, not next month.
It will take us many months if not year or more before we can produce a stable language and compiler. Also we are having some disagreement (lack of mutual understanding) about how to handle the type theory of the compiler.
So I suggest we first decide on the syntax, so we (I) can produce a transpiler to PureScript and then use PureScript as the compiler. This would fast track testing the design of our syntax in working programs.
PureScript is lacking first-class, structural anonymous unions, so we won't be able to support that feature. Appears PureScript can support all our other features such
data, typeclasses, and typeclass objects.I want something tangible for my effort pronto. I don't want to go off on some long-winded effort, before getting feedback on the utility of our new syntax and concept.
I think an incremental approach to engineering is usually best. Design, implement, test, and repeat.
@keean what do you think?