Carp: A statically typed Lisp, without a GC, for real-time applications
github.com
github.com
I wonder if Carp could fair well with a more academic, heavy-processing sector....
Could you expand on this? I'm not sure I understand your comment.
This is fine, but a lot of academic work (bioinformatics, video processing, advanced statistical analysis, etc...) can be very computationally heavy, leading to a lot of academics and post-docs writing some ad-hoc C++ in order to squeeze out better performance.
What I was suggesting is that, since Carp might have better performance characteristics for more CPU bound tasks than something like, say, Racket, it might satisfying the niche of academic-friendly languages.
I've never been a fan of lisps, but that has more to do with the common lack of strong typing discipline, than that it was a syntax issue. Currently I'm using Haskell a lot.
But this lisp is a breath of fresh air to my type-loving brain.
Maybe I've overlooked them, but what about higher kinded types and reflecting purity at type level? Are they not-in-and-never-will-be-by-design, or maybe-if-someone-implements, or on-the-road-map?
1: http://www.shenlanguage.org/
2: http://www.shenlanguage.org/learn-shen/index.html#9%20Types
It's very ground-breaking work imho that is unfortunately very poorly known/cited, having been presented mainly to the computer music community, but it represents a real-time garbage-collected Scheme.
It does not manner how you name your tokens or how you choose to destruct your data structures. It's still lisp.
Isn't that also the norm in Common Lisp? You can do any convoluted thing you want, of course, but in my own code, I retrieve elements by key using e.g. 'getf' or 'gethash'. (I do agree that there are many naming warts.)
Like car and cdr? Check the Carp manual for some surprise arbitrary naming.
That being said, I tend to use destructuring in common-lisp, and if you are taking an element from a collection by using c*r then you are probably doing it wrong.
Optima has more complete support for destructuring, but this works just fine in CL with out any libraries:
(let ((some-plist '(:foo 1 :bar 2)))
(destructuring-bind (&key foo &allow-other-keys) some-plist
foo))It is permissible to place an s-expression pattern in place of a symbol in the (sym init) form of an element of the bvlspec. The symbols in the pattern will become bound to the matching elements of the initialization (see DESETQ). This kind of pattern-matched assignment is called destructuring.
(let (((a b) '(1 2)))
(cons b a))
=> (2 . 1)
Then they'd be happy with Lisp from 40 years ago. Common Lisp (which was not the first to have either feature) has DESTRUCTURING-BIND (as well as some other constructs like extended lambda lists and within LOOP) where you can use destructuring, and it has generic sequence functions that work on more than lists like MAP, REMOVE-IF-NOT, REDUCE, etc, as well as lookup functions for getting things out of key-value maps (list-based or not) by key, or from sequences by index. Explicitly cdring down lists is mostly only done in introductory textbooks.
It feels like a lot of Clojure advocacy is written in terms of this "Lisp before Clojure" strawman of some minimalist Scheme subset. Lisp has had arrays, dictionaries, records, etc (with literal syntax and proper accessors), as well as destructuring and generic sequence functions, for almost half a century (more than half a century for some of that). Whether or not you prefer Clojure's syntax for those things, Lisp had those things long before Clojure existed.
#line <num> "filename"
#line <num>
You might wind up generating a lot of these, but they're really easy to generate as long as you preserve that information all the way through compilation (which I'd assume you'd have to do for LLVM IR regardless).
Yes, you would need to keep track of the source locations for each node in the AST. There is a nice example in the LLVM Kaleidoscope tutorial here: https://llvm.org/docs/tutorial/LangImpl09.html
What's wrong with "def"?