Readit NewsI've spent the last couple of months porting the compiler from Julia to TypeScript. That's nearly done, so I'm hoping I can post an interactive web demo next month!
Droplet: "Datalog in time and space" - https://github.com/jamii/droplet
Eve: "Datalog meets Smalltalk" - https://witheve.com
Imp: "An Eve for people who build Eves" - https://github.com/jamii/imp
These are some pretty "out there" languages with a high strangeness budget, so I'd expect the same of Zest.
I like the idea of exploring the interaction models that Eve provided but instead with a "well-trodden ground of a mostly-familiar imperative language", but I'm curious how that will work since the interactions in Eve were made possible due to the datalog-like language design. So my initial question is how "mostly-familiar" Zest really is; what imperative concessions does the language make to gain which interactions?
With Eve, a lot was gained just by keeping a database of compiler artefacts that would normally be thrown away. This allowed for a degree of "provenance" tracking, where you can ask the compiler how a runtime value came to be.
I think there's an interesting middle ground where maybe we can get a bunch of the things in Eve that were nice, but maybe tone down the weirdness budget to lower the learning curve. Maybe that's Zest? Will be interesting to follow this project.
What Datalog and co give you is the ability to do interesting program transformations. Mostly that's not because they are "declarative", if that means anything, but because they avoid all the little bits of non-determinism that imperative languages include. If you avoid those you're pretty much set. Coming from another angle, JAX [1] shows how you can do program transformations in Python with a relatively small set of semantic restrictions.
[0]: https://www.scattered-thoughts.net/writing/unexplanations-sq... [1]: https://github.com/jax-ml/jax
Something cool the web can do is static, reliable, easily readable documents – might be nice to show that off.
This will output a pkg/ directory containing our wasm module, wrapped in a js object.
The WASI project specifies wasm-native APIs (modelled on posix) for running locally without JS, so you could imagine something similar for the browser. But the complexity of the DOM is forbidding.
I've not tried Emscripten hello world for a while, but I imagine it depends on things like optimisation level, dead code elim etc. In general to compile C code you'll need a malloc, string support and so on as you say. You can make the wasm file tiny if you lean on JS strings, but that increases the amount of support code again. Languages other than C will have an easier time reusing parts of the JS runtime (like strings or GC).
If the function started to provide different results for the same arguments, that’s different from what he’s talking about and would be a breaking change.
Worrying about the internals of the function is a violation of encapsulation. We care what we provide and what we receive back.
Deleted Comment
I've been working through advent of code using my own little compiler/language. It's in such an early state that some creative problem solving is required, not to mention the compiler bugs! But I'm very pleased to have it running interactively on my blog like this – I want to work towards some bigger notebooks in the style of explorable explanations.