This looks amazing and very close to a project I've been working on myself - a clojure-ish lisp-1 with Rust style memory management. Very cool work!
Carp: a statically typed lisp, without a GC, for high performance applications
21–30 of 71 posts
Re: Carp: a statically typed lisp, without a GC, for high performance applications
#22I understand this is marked as "a research project", so any answer here is possible and must be accepted; that said I'd really love to learn at least about plans with respect to the following questions: • Regarding FFI, is it possible to pass pointers to carp functions/closures as arguments to external dynamically loaded functions? are those features available in REPL? • What's the story/approach regarding structs in…
1. Yes, and yes! 2. No plans for inheritance at the moment, probably some kind of interfaces but that's not a top priority right now. Custom types are limited to structs, I will add union types soon 3. This has not been decided yet, I want to do more research before settling on any particular solution. It will be a high priority though, since I want to use it for the games I write Thanks, Erik
Thanks!
Re 1: are there any examples of this in the codebase? I haven't seen anything in the "examples/" subdir, did I overlook, or should I dive somewhere into the compiler/runtime codebase?
Also, some more questions still, if you wouldn't mind:
• Could you possibly answer junke's question? https://news.ycombinator.com/item?id=12041555 I didn't repeat it, as I hoped you'd see it too;
• Do you have tail-recursion? Also, to tell the truth, a list of "what we don't have yet" and also "what we don't plan to have" would help to confront my dreams with reality...
Regarding (2), personally I like Go's/Rust's approach, but I'm not an expert in the domain by any means, and I understand everybody has one's personal taste and view. Just couldn't resist, sorry :)
edit: Also I see you're the author of Else Heart.Break() - awesome, congrats!
Re: Carp: a statically typed lisp, without a GC, for high performance applications
#23Earlier quoted context omitted.
It is homoiconic, because the data structures used to describe code are also data structure provided by the language. However, brackets mean that you pass arguments as arrays instead of lists: there is little reason except aesthetics to have this distinction in source code. I prefer parenthesis everywhere, but some people really dislike that.
Yes, it's still homoiconic. I think vectors for argument lists is mainly a usability affordance. Which gives you aesthetics for free. (If you happen to find it more aesthetic.) > Common LISP and Scheme are not simple in this sense, in their use of parens because the use of parentheses in those languages is overloaded. Parens wrap calls. They wrap grouping. They wrap data structures. And that overloading is a form of…
Take C:
struct {
int x;
} ...;
int foo () {
return 0;
}
In Clojure, take [a b] out of context. Which element is evaluated, a, b, none or both? The fact that it is a vector does not help you, because it could be a binding, an argument list or a vector constructor.
Also, how something is stored inside the AST has nothing to do with its meaning at runtime. Argument lists could be passed using the stack, but you don't actually write a stack inside the source code. The fact that they are written as vectors or lists does not matter either, you still have to know the semantics. And semantics is almost never context-free.
Re: Carp: a statically typed lisp, without a GC, for high performance applications
#24Looks like just what I have been trying to find, since I am incapable of writing my own. I did start with 'Learn C * Build Your Own Lisp' book [1], and I will finish it for educational purposes; it is a great, short book to work through, and should help with grokking Carp.
The closest I have come to finding something similar for livecoding visuals and audio, or games is Extempore [2], which has xtlang, a Scheme, with manual memory management and types. The only two criticisms I have, and they are small, are the build and number of dependencies, and how to distribute standalone executeables. In all fairness there are binaries now available for all platforms, but standalones are still problematic.
I curse Fluxus [3] for starting me down this crazy road many years ago in search of the best creative coding environment. Shame it is not refreshed every so often, because the interface is brilliant.
I'll have to look over Carp this weekend more closely. I am intrigued how it is like Rust's semantics. And if it is manual memory management all the way, then I guess that is where it differs from Rust's safety features?
Now I don't have to try Clojure again! I don't like the JVM, and prefer going to C.
[1] http://www.buildyourownlisp.com/
Re: Carp: a statically typed lisp, without a GC, for high performance applications
#25For people interested in writing games with a Lisp dialect, you should have a look at Hypergiant library for Chicken Scheme. It compiles to C as well.
https://github.com/AlexCharlton/Hypergiant
Re: Carp: a statically typed lisp, without a GC, for high performance applications
#26I'm fishing for a pun in there but just can't catch a big one.
Re: Carp: a statically typed lisp, without a GC, for high performance applications
#27Is there an explanation of the memory allocation used? There seem to be a GC ( https://github.com/eriksvedang/Carp/blob/master/src/gc.c ), maybe used in the compiler only, coupled with lifetime analysis ( https://github.com/eriksvedang/Carp/blob/8665a7f9a19d9347cc0... ), which as far as I know is used once ( https://github.com/eriksvedang/Carp/blob/6107e619d4f632acace... ) in the compiler. This analysis seems tied to…
As far as I understand from listening to Erik talk about Carp, there is an interactive interpreter which does use GC. In contrast, the compiler generates GC-free code.
Re: Carp: a statically typed lisp, without a GC, for high performance applications
#28This is fantastic. AFAIK there are no Lisps our there that are designed with games in mind which is a huge shame because I often think how perfect it'd be for game dev (Arcadia and Nightmod spring to mind but imo they're shoehorns. Good ones, but still).
There's (or was) Game Oriented Assembly Lisp:
https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
Re: Carp: a statically typed lisp, without a GC, for high performance applications
#29Earlier quoted context omitted.
1. Yes, and yes! 2. No plans for inheritance at the moment, probably some kind of interfaces but that's not a top priority right now. Custom types are limited to structs, I will add union types soon 3. This has not been decided yet, I want to do more research before settling on any particular solution. It will be a high priority though, since I want to use it for the games I write Thanks, Erik
Could you pretty, pretty please allow for an option to have automatic parentheses insertion, similar to how javascript will insert semicolons, making them optional? This is almost exactly the language that I've been planning for the last six months, and if you would be so kind as to implement that one feature, it would save me a lot of reinventing the wheel. I was originally envisioning having the compiler being able…
If you don't want the parenthesis then why not use reverse polish notation?
Re: Carp: a statically typed lisp, without a GC, for high performance applications
#30Earlier quoted context omitted.
1. Yes, and yes! 2. No plans for inheritance at the moment, probably some kind of interfaces but that's not a top priority right now. Custom types are limited to structs, I will add union types soon 3. This has not been decided yet, I want to do more research before settling on any particular solution. It will be a high priority though, since I want to use it for the games I write Thanks, Erik
Could you pretty, pretty please allow for an option to have automatic parentheses insertion, similar to how javascript will insert semicolons, making them optional? This is almost exactly the language that I've been planning for the last six months, and if you would be so kind as to implement that one feature, it would save me a lot of reinventing the wheel. I was originally envisioning having the compiler being able…
Maybe you can use "Readable Lisp S-expressions".