Or am I wrong in assuming this is a functional language?
Carp – A statically typed Lisp, without a GC, for real-time applications
31–40 of 139 posts
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#32I was thinking of building my own LISP-like language, but seeing so many pop up on here I don't think I'll bother.
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#33There is also interesting CL implementation that is based on the LLVM framework - Clasp[1]. It can be natively compiled and designed for performance. [1] https://github.com/clasp-developers/clasp
For one, it's created and written by a Chemistry PhD researcher (Christian Schafmeister), not someone with a traditional CS background.
For another, it's one of the few languages that has ever attempted to interface with C++ at the template level - you can instantiate C++ template classes from CL, and catch C++ exceptions etc.
For yet another, he does compacting garbage collection for the C++ objects used in the CL implementation, with pointer patching and everything else.
There's a nice Google Tech Talk about it [0], that goes into both why he did this, and how he implemented this.
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#34Can somebody please explain or give me some links how FP is supposed to work without a GC? For example Rust has different types of function pointers (Fn, FnMut, FnOnce), to guarantee the possibility of lifetime analysis (so it is arguable to consider it a functional programming language). On the other hand the most common FP languages (OCaml, Haskell) all come with a GC. Or am I wrong in assuming this is a functional…
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#35Can somebody please explain or give me some links how FP is supposed to work without a GC? For example Rust has different types of function pointers (Fn, FnMut, FnOnce), to guarantee the possibility of lifetime analysis (so it is arguable to consider it a functional programming language). On the other hand the most common FP languages (OCaml, Haskell) all come with a GC. Or am I wrong in assuming this is a functional…
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#36Can somebody please explain or give me some links how FP is supposed to work without a GC? For example Rust has different types of function pointers (Fn, FnMut, FnOnce), to guarantee the possibility of lifetime analysis (so it is arguable to consider it a functional programming language). On the other hand the most common FP languages (OCaml, Haskell) all come with a GC. Or am I wrong in assuming this is a functional…
I think the question is: how does Lisp function without garbage collecting cons cells?
For one, I'm not sure they even rely on cons cells like "real" Lisp. Clojure doesn't either. They cite ML as inspiration.
Carp language guide states object lifetimes are statically inferred [1] which my guess is they allocate on stack (or malloc/free by scope) and detect use-after-free at compile time.
Another, more theoretical approach is using linear types which require all values to be "consumed" [2]
1: https://github.com/carp-lang/Carp/blob/master/docs/LanguageG...
2: https://www.cs.utexas.edu/users/hunt/research/hash-cons/hash...
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#37Can somebody please explain or give me some links how FP is supposed to work without a GC? For example Rust has different types of function pointers (Fn, FnMut, FnOnce), to guarantee the possibility of lifetime analysis (so it is arguable to consider it a functional programming language). On the other hand the most common FP languages (OCaml, Haskell) all come with a GC. Or am I wrong in assuming this is a functional…
"TN-tools in Nokia were automatically compiled into C-code to be run in VAX-computers. Compiled C-code did not have garbage collector, there was separate reclaim-command for discarding used data. If you managed to run your program without ever hearing the BEEP caused by garbage collector, your program was ready for VAXing."
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#38Can somebody please explain or give me some links how FP is supposed to work without a GC? For example Rust has different types of function pointers (Fn, FnMut, FnOnce), to guarantee the possibility of lifetime analysis (so it is arguable to consider it a functional programming language). On the other hand the most common FP languages (OCaml, Haskell) all come with a GC. Or am I wrong in assuming this is a functional…
Lisp is not necessarily functional. There's a lot of mutation in Common Lisp even if the community favors a functional style. I think the question is: how does Lisp function without garbage collecting cons cells? For one, I'm not sure they even rely on cons cells like "real" Lisp. Clojure doesn't either. They cite ML as inspiration. Carp language guide states object lifetimes are statically inferred [1] which my gues…
[0] https://www.reddit.com/r/haskell/comments/d5d13i/is_it_possi...
[1] https://github.com/carp-lang/Carp/blob/master/docs/Memory.md
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#39There is also interesting CL implementation that is based on the LLVM framework - Clasp[1]. It can be natively compiled and designed for performance. [1] https://github.com/clasp-developers/clasp
However, if you are primarily e.g. calling computational chemistry libraries written in C++, Clasp is the way to go. It's the only non-C++ language implementation I know of with actually usable C++ support.
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#40> (the Int x) I like the cute syntax for type annotations.
so e.g. (the fixnum (+ x 1)) would assert that (+ x 1) produces a fixnum.