Live data from Hacker News

Carp – A statically typed Lisp, without a GC, for real-time applications

github.com

31–40 of 139 posts

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#31
Can 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 language?

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#32
post #25

I was thinking of building my own LISP-like language, but seeing so many pop up on here I don't think I'll bother.

You probably should anyway - most of it is for learning and personal satisfaction. It's not like any of these projects are competing for actual marketshare in the programming language landscape.

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#33
post #7

There 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

CLASP is a really interesting project.

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.

[0] https://www.youtube.com/watch?v=8X69_42Mj-g

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#34

Can 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…

use value semantics for everything is one way

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#35

Can 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…

As long as you forbid or mark cycles (…or ignore the problem) lifetime analysis can be done statically. Which is better anyway. Automatic memory management doesn't need a GC.

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#36

Can 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 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

#37

Can 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…

Me knows:

"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."

https://timonoko.github.io/Nokolisp.htm

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#38
post #36

Can 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…

Thanks for the links. There's also this Reddit discussion [0] from 2 years ago (it mentions Carp btw.) and an explanation about how Carp manages memory [1].

[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

#39
post #7

There 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

Last I checked SBCL and CCL (both open source native compiled CL implementations) are quite a bit faster than 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.

I had to double-take because CL also has a THE also for declaring types, but it's a bit different; THE declares the type of an expression, not a variable (there is a separate type declaration for variables).

so e.g. (the fixnum (+ x 1)) would assert that (+ x 1) produces a fixnum.

Post reply on HN