passerine VS empirical-lang

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

I'm interested in languages experimenting with integrating tables/dataframes and the relational model as native parts of the language

With how much of the code I've written that's been around representing entities and doing CRUD on collections of them it seems a bit wild not to have native "Table" types.

There's an HN user who has a neat language called "Empirical" based on this, and there's an active research language called "Flix" that has this as well. APL/K and other array langs feature a similar concept as I understand it.

https://www.empirical-soft.com/

https://flix.dev/

The most used in finance is a few functions in pandas, like merge_asof(). It's pretty industry standard now.

https://pandas.pydata.org/docs/reference/api/pandas.merge_as...

The biggest open-source thing I've ever written is Empirical, a language for time-series analysis.

https://www.empirical-soft.com

I'm also top 1% on Stack Overflow. A lot of companies have found me through there.

https://stackoverflow.com/users/478288/chrisaycock

I started Empirical with the goal of "q like Haskell". The end result went in a radically different direction, but the guiding light has always been to have a statically typed language where tables and queries are a first-class operation.

The source code is publicly available under AGPL with the Commons Clause:

https://github.com/empirical-soft/empirical-lang

Some of the OP's observations are why I wrote Empirical [1].

- I wanted static types that felt dynamic, which meant being able to infer types from a file as long as the file path can be determined at compile time.

- I wanted Dataframes to be a first-class container since the high-level of abstraction leads to great performance when doing analytics.

Therefore, I created a language with statically typed Dataframes. Empirical can infer a CSV's type at compile time, namely because performs compile-time function evaluation automatically. The result is a language that runs easily in a REPL but can be used for long-running scripts without worrying about common programming errors.

[1] https://www.empirical-soft.com

I wanted to hit the runtime repeatedly with as little overhead as possible. So VVM has no type look-up, multiple operands per instruction, and a cache-efficient IR. The sum() operand for the above example is invoked directly in a loop almost as fast as hand-written C++.

VVM has its own assembly language [2]. I have blog post that explains some of the design choices [3].

[1] https://github.com/empirical-soft/empirical-lang/tree/master...

[2] https://github.com/empirical-soft/empirical-lang/tree/master...

[3] https://www.empirical-soft.com/2020/09/03/a-tour-of-the-vect...