Architectural in-a-nutshell of Merg-E

[Rob Meijer]

I made an attempt at an architectural in-a-nutshell overview of my (slowly) ongoing efforts on the Merg-E DSL and its runtimes. Merg-E is intended to become a closure-only, security-focused DSL and runtime for Web 3.0 and data-flow applications.

Unfortunately, HIVE's 64,000-character limit on blog posts turned what was meant to be a single walkthrough into two posts. The link to part 2 is at the end of part 1:

https://peakd.com/hive-139531/@pibara/a-language-architectural-in-a-nut-shell-of-the-merg-e-language-part-12

I feel the language features are fitting increasingly better together into what feels like a holistic whole, but I'm "very" close to the project, and therefore likely "too" close to judge that objectively.

Any feedback, both positive and negative, would be greatly appreciated.

[Matt Rice]

Still only about half way through the first part, most of my feedback
is pretty superficial/dumb parsing stuff, like having both "arg type",
and "func arg", and that the indentation in `use ambient` blocks
scoping variables is at the same indentation levels as the imports in
functions. I kind of naively expect that we should only be able to
refer to variables at the same indentation level if they are also in
the same block.

Probably my biggest thought is about function level closure capture,
and modern editors. It might be nice to be able to view the closure
capture + function names, absent the function logic, and function
logic absent the closure capture. It kind of feels like modern editors
could put the closure capture and the function implementations in a
separate declaration type of file, and use lsp-esque 'inlay hints', to
combine them into a single text stream. I suppose there are two
arguments against having separate declarations and implementations,
the first being the pain involved with maintaining separate files. It
seems like there is no harm in basically auto-generating declarations
from the implementation with empty closure capture environments. The
second being local reasoning is enhanced by displaying both the
closure and the implementation. So I suppose my question is whether
modern editors are sufficient in their ability to either display
inlays, or jump between a declaration with the closure capture and the
implementation offsets the burden while still providing local
reasoning. Because for me, it feels a bit busy having all this in one
file.

[David Nicol]

Thanks! That's just what Merg-E needed.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/fd47489d-48e0-437f-91a5-059297f6b93fn%40googlegroups.com.

--

"The profit motive is often in conflict with the aims of art." -- Ursula K. Le Guin