Carp-A Language for the 21st Century - Veit Heller

[@thalesofthewell]

PLEASE provide better error messages than clojure

[@weaknsmall]

I showcase error messages at around 9:00 minutes in. I think they are usually okay, although we want to take a page from the Elm playbook and rewrite most of the error messages to make them a little friendlier (while still being as informative of course)! Anyway, good error messages are definitely a priority!

[@curlywurlycraig]

Thanks for this. I've been working on a typed lisp for compiling directly to webassembly, and came across this language. Good presentation that conveys the language well! I wonder if it is possible to statically type ASTs themselves, enabling typed cons, eval etc that you touched on as hard problems. Could be worth looking into

[@MsHofmannsJut]

Not too relevant, but I loved to use a table in Scheme S7 (which has applicative syntax for all collections) to store my function definitions and namespace them that way so that instead of `(type.function arg)` I had `((type 'function) arg)`. Just felt so sweet. I'd still do it that way if I were me doing it.

[@DenisG631]

Omg it's written in Haskell?! Now you got my attention :D

[@darkengine5931]

Is this more of an imperative language? From what I can gather, the central data structures aren't immutable or persistent.

[@weaknsmall]

The data structures are internally mutable, but externally immutable (enforced by the borrow checker). They are not persistent. Variables are not immutable, however, and re-assignment is allowed. Carp often feels somewhat imperative compared to other Lisps, more like writing Rust. This is because often imperative solutions are more desirable in its context, du to the current absence of tail-call optimization (which we’re working on, but isn’t high enough priority). Does that make sense?

[@darkengine5931]

​@@weaknsmall Makes sense and looks very nice to me. The language seems to hit a lot of wishlist features I've been looking for like compiled instead of interpreted, statically-typed, and ease of interop with C. The one thing I'm wondering about after looking through the github examples and docs is if there might be some official support for using the language in an embedded rather than extended context (ex: from a host application that is implemented in C++). In my case, we've been cycling through embedded languages a lot over the past years... from a proprietary scripting language to Python and Lua and JS. They tend to be ill-suited for wide use in our case primarily because of the lack of performance we get from them being interpreted, dynamically-typed, as well as more or less painful to interop with C. In our case, so much of our daily kind of code loops through every single vertex/edge/polygon of a mesh (which could span in the millions), or every single pixel/texel of an image/texture, every single particle of a particle system, every single voxel of a voxel grid, etc... lots and lots of critical, loopy code. And we've found through measurements that we can't really use these embedded scripting languages much for production code except to prototype things or to write very simple high-level scripts that don't do any intense loops of their own. I've been searching for a replacement and Carp looks quite nice in that regard. The replacement doesn't necessarily have to be as aggressively optimized as top-notch C or C++ compilers, but just something that isn't going to be like 100+ times slower to do a number-crunching loop over inputs spanning millions of elements in a contiguous array, e.g. Even something which executes 10-20 times slower would still be a lot more usable to us in a broader range of contexts than, say, CPython or even LuaJIT.

[@weaknsmall]

@@darkengine5931 I think I understand what you’re looking for, and I’ve had similar experiences; especially embedding Lua is a breeze and very fun until you need to hit speed requirements. Embedding in a host application is not an explicit goal of Carp, sadly. The compiler is written in Haskell, and there are no bindings for it to interoperate with C/C++. It should be possible, but at that point you’d be calling from C++ into Haskell to compile a third language, which seems like a maintenance burden at the very least. One thing that works quite well is having Carp co-exist with C and C++, in the form of shared libraries and such. No matter which of the two emits the shared library and which one is actually the “main application”, both sides work quite well (the name mangling is also minimal and quite understandable, such that you should know which symbols to look for). Of course, this takes away the extensibility of embedding, since you still have to compile an artifact to link to ahead of time, so it might not be for you. Sorry that I couldn’t give you a more positive answer, but I hope that gave you a bit of an understanding of what to expect!

[@darkengine5931]

@@weaknsmall Cheers and thanks for the detailed info!

[@kexuyo]

Why is static type so popular these days? I would definitely try it if it was dynamic.

[@Shroomander]

there are already loads of dynamicly typed LISPs, plus helps w/ optimization

[@derekfrost8991]

Static typing should be optional like in bigloo scheme.

[@dialecticalmonist3405]

Because errors are less popular.

[@uipo1122]

Because people want to write programs that are bigger than 500 SLOC and still work after a slight refactor. You can't do that in a dynamic language.

[@classone2010]

for god sake. why would you use clojure like syntax. otherwise those features are fantastic

[@weaknsmall]

Personally I don’t think syntax is particularly important, but YMMV. My personal preference is for smaller languages syntax-wise (i.e. Lisp or Go rather than Rust and C++), but that’s just me. For what it’s worth, though, a drop-in replacement for the parser shouldn’t be too hard-of course, replacing all the keywords with more idiomatic keywords is a bit of work. What syntax would you prefer?

[@FateIsDetermined]

@@weaknsmall I would prefer Elm (Haskell) syntax and to compile to Rust. Great language anyway.

[@weaknsmall]

I think ML syntax is great for a bunch of things (currying and eta reductions, for instance), but not so super for others, most importantly macros, which Carp cares about. The “everything is a list”-style syntax of Lisp just lends itself incredibly well to macros. That said, I hear F# has both great macros and an ML-like syntax, so maybe that would be worth looking into (which i haven’t)!

[@dimaughsilvestris5941]

@@weaknsmall if anything, I would prefer Scheme syntax, which is not too far from Clojure. For some reason, using (defn tick [state] (+ state 10)) instead of (defn (tick state) (+ state 10)) itches me badly, like a lost opportunity for greater elegance. But that's nitpicking, this is a wonderful project and I hope to contribute to it at a higher-level when it reaches v1.0.

[@FeelingShred]

"Works with Java/JS" Booooo hooooo! Sorry, couldn't help it... xDDD

[@AvioInsane]

"Quick quethtion..." My god how does a grown adult in 2021 have a lisp. Embarassing.

[@ChristineLemmerWebber]

First of all, no reason to be a jerk. I also have a lisp, and it's not easy to overcome such things. And hey, the video itself is about a lispy language, so all lispiness in terms of enunciation is de-facto not only acceptable, it's welcome. ;)

[@pinniporker]

@@ChristineLemmerWebber think it perfectly fits the topic about a lisp programming language. To say s close your teeth and touch the teeth with your tongue then breathe out.