ethereum / moon-lang

Minimal code-interchange format
MIT License
193 stars 20 forks source link

Incomplete interop with JavaScript #8

Closed Pyrolistical closed 7 years ago

Pyrolistical commented 7 years ago

You have implemented a runtime in JavaScript and moon-lang is meant to be called from JavaScript, yet there lacks faculties to return null, booleans, or arrays from moon-lang.

Is your goal to be useful from JavaScript, or are you just using JavaScript because its everywhere?

If you intend to have different non-JavaScript runtimes, then what you have today is fine.

However, my goals with deft is to interop fully with JavaScript, which means we might not be able to share runtimes/syntaxes

VictorTaelin commented 7 years ago

The primitives were not added for JS interop! They were added because they're required for performance: there is, so far, no obvious way to get floating point arithmetic, strings and hash tables to run with λ-encoding as efficiently as the native representations. As such, Map, Str and Num are the minimal set of additions to make the λ-calculus practical. Note that JIT engines compile arrayish-map usage to actual arrays, so arrays are not needed for performance!

Host-language interop is a different concern, and it does not require those primitives! It just requires a consistent way to translate from native terms to Moon-terms, and back. The untyped λ-calculus with λ-encodings (i.e., no primitives) is already sufficient to any kind of interop. Now, of course, given that Str, Num and Map behave exactly like JS numbers, strings and objects, you should use those for performance. For arrays, I simply interpret any Moon Map with a .length field and numeric indices as a JS array. Of course, that means there is no way to encode an actual map with a .length field and numeric indices. If you don't want that ambiguity, you can just use a scott-encoded sum type on Moon's side (i.e., Either Array Map).

Note, again, primitives have nothing to do with interoperability, they're a short-term pollution that is there only for practicality. As soon as I find a way to get rid of them (i.e., a satisfactory way to compile λ-encodings to native Strings, Maps and Array), I will. Moon 2.0 will likely be just Morte (ironically killing it).

Pyrolistical commented 7 years ago

ok cool, I think this is where we'll have to part ways then. my ast will mirror the capabilities of javascript 1:1 in order to have simple interop. I could have full interop with moon-lang if i keep additional data while translating from deft -> moon -> javascript, but honestly that seems like a waste of time and will bloat the binary encoding.

thank you for inspiring me and i'll definitely keep an eye on this project

VictorTaelin commented 7 years ago

Ah, that's sad. Wish you all the best and I hope you come back!

thank you for inspiring me and i'll definitely keep an eye on this project

No problems, and thank you actually!