passerine VS proposal-record-tuple

It's still a long way from being complete, but I'm working on something like that[0]. Eventual plans are to have good Rust library interop (e.g. bindings to hyper for http) while also being able to compile to Wasm (to run on an erlang-style distributed runtime / the browser). The language is currently interpreted, but one I get typechecking working, I should be able to merge in the Wasm codegen backend I'm working on (with eventual plans for LLVM). Current compiler has zero external dependencies.

Language itself could be described as a mix of OCaml, Scheme, and Lua. Currently working on the hygienic procedural macro system and system injection through algebraic effects.

[0]: https://github.com/vrtbl/passerine

Passerine was the next language i decided to try to fit onto paka, but alas this one too was eventually put aside for the time being.

Tossing my hat in for Passerine [1]. Gorgeous ML inspired syntax. Built for scripting Rust applications.

Dreaming here: Lua is a fantastic scripting language, but the Rust FFI isn’t as ergonomic as it could be. Enter Luster [2], which is basically LuaJIT rewritten in Rust.

Embedding a scripting language in a Rust application gives you tons of power (e.g. scripting Rust structs from Lua [3]), and setting this up isn’t terribly difficult.

[1] https://github.com/vrtbl/passerine

[2]: https://github.com/kyren/luster

[3]: https://git.sr.ht/~ioiojo/kiwi

Seed7 and https://github.com/vrtbl/passerine (and seemingly more as others have suggested) have direct / first-class support of syntax declaration/definition in a homoiconic way, as powerful as LISPs, but feels more "natural" compared to a LISP.

It used to work pretty well only if the core PL makes semicolons programmable, but given the development of effect systems, plus customizable syntax as in https://github.com/ThomasMertes/seed7 and https://github.com/vrtbl/passerine , I'd say, there are much more we can do about it.

git clone https://github.com/vrtbl/passerine

relevant issue, which is at the crux of this problem: https://github.com/tc39/proposal-record-tuple/issues/387

There are still so many basic things that aren't in the JS stdlib, though. A good example is Map - if you need to use a tuple of two values as a key, you're SOL because there's no way to customize key comparisons. Hopefully we'll get https://tc39.es/proposal-record-tuple/ eventually, but meanwhile languages ranging from C++ to Java to Python have had some sensible way to do this for over 20 years now.

If you’re reaching for structuredClone, what you really want is native immutable Record and Tuple syntax, and the companion “deep path properties” syntax which allows for efficient and ergonomic immutable updates:

- https://github.com/tc39/proposal-record-tuple

It will be called "record" in JavaScript which will swing the popularity back the other way I guess (currently a language proposal)

I suspect considering the strong desire to maintain consistency with JavaScript, we will eventually see something that when the Record proposal passes through tc39

I hope the Record and Tuple proposal makes it through

I mean, I'd love some real immutable/persistent data structures in JS by default, or even some Immer-like syntax sugar. Something like the record/tuple proposal would be awesome.

This will become very useful once Records and Tuples are a thing, because it allows you to store object references in a record/tuple (which by definition can only contain primitives).

Record and tuple is at stage 2

Also, js has an ongoing immutable value data types proposal.