jank VS language

There's an effort afoot to bring this to the Clojure world, with the lovely name jank: https://jank-lang.org

I also liked that reference since I had not heard of Jank before. It is a work in progress so I just added a calendar entry for 9 months from now to check it out. https://jank-lang.org/

There will be a lot of room for this, once I build out more of the features. In particular, there will be a lot of Clojure libraries which need to gain jank support. Clojure doesn't require "porting", so to speak, since it has a special .cljc file which can use reader conditionals to check the host that it's in (clj, cljs, cljr, jank, etc). So anywhere those libs are using Java interop, we'd need to wrap it to use native interop instead.

On the compiler and tooling itself, I have some open issues here: https://github.com/jank-lang/jank/issues

The vast majority of it is heavy C++ work, though. Outside of that, the biggest gains will come from time spent on packaging, distribution, and testing on various platforms.

And if none of that sounds interesting or applicable, don't worry. Just be sure to join the Slack channel and hang out with us. :)

On the top of using C++ for scripting, and related to the discussion of CERN's ROOT/Cling, I am developing a Clojure dialect on C++/LLVM called jank: https://jank-lang.org/

jank is a true Clojure, meaning you get interactive, REPL-based development and a whole stdlib of persistent, immutable data structures and functions to transform them. But it's also C++, so you can write inline C++ within your jank source, and interpolate jank values within that. You can link with existing native code using LLVM and you can embed jank into your existing native projects to use for scripting.

jank is pre-alpha, right now, and I've only been showing it to Clojure devs so far, but there's a huge audience of C++ devs which may be interested in introducing Clojure to their native code.

jank (https://jank-lang.org/) is a Clojure dialect on LLVM with C++ interop. In this talk, Jeaye will cover jank's use cases, some challenges around building a native Clojure dialect, and some insights about Clojure itself found only by spelunking deep into the Clojure compiler.

I wonder if Jank [1] could be such a Lisp? I haven't played around with it, but I really like the idea and would love to see it get more traction.

[1]: https://jank-lang.org/

This isn't usable yet, but in active development by the author, and looks promising: https://jank-lang.org/

Jank looks pretty legit: https://jank-lang.org/

I noticed that I can enable inline-class as an experiment to play with Extension Types. You need to also add sdk: ^3.3.0-0 to your pubspec.yaml.

Current syntax is not all that bad if you are going to do OO and add various helper methods on `Message` and its subclasses, but if you just want to define your data and no behavior / helpers - then it is exceedingly verbose.

[1]: https://github.com/dart-lang/language/issues/3021

Reference

A future version of Dart will probably support macros which should make this all a bit easier to use, similar to how Swift 5.9 works which makes already fantastic use of its new macro capabilities by integrating mobx (or solidjs) like reactivity into SwiftUI by a harmlessly looking @Obervable annotation.

Coming from a Dart context here where that team is also looking at adding Macros to the language. It was really interesting to compare and contrast some of the approaches https://github.com/dart-lang/language/blob/main/working/macr...

Yes, that needs a bit of boilerplate for the constructor declaration and the extra build method, but I personally don't mind and with implicit constructors this will become much easier. Also, you get a performant UI as Flutter knows to not redraw widgets that didn't change.

I know that it would be nice not to use the generator at all, but we have to wait until static metaprogramming is implemented in dart. https://github.com/dart-lang/language/issues/1482

I implemented a prototype version of the algorithm in that paper when exploring exhaustiveness checking for pattern matching in Dart.

I found it pretty easy to understand, but also really easy to get it to generate huge combinatorially large spaces. Some careful memoization and deduplication helped, but even so I never got the performance to a state I considered acceptable.

Instead, I went with Luc Maranget's classic approach and figured out a way to adapt it to a language with subtyping (with a ton of work from Johnni Winther to figure out all of the hard complex cases around generics):

https://github.com/dart-lang/language/blob/main/accepted/fut...

The performance (in the prototype!) was dramatically better. You can always make pattern matching go combinatorial, but I haven't seen any real-world switches get particularly slow with our approach yet, and we have some fairly large tests of matching on tuples of enums.