Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

71–80 of 139 posts

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

#71

Post by kortex »

brabel wrote: post #50
pjmlp wrote: post #42

Earlier quoted context omitted.

Millions of CS students build their own language for compiler classes every year. As learning exercise of everything that goes into making a compiler/interpreter is very worthwhile endevour. As means to make the next big thing, maybe not.

> Millions of CS students... Are there millions of CS students in the world?? I would guess a few hundred thousand, at most.

Probably. There's 20-30ish million software developers in the world [1]. People work for 30-50 years, suggesting at least a million freshman CS students a year. It's a rapidly growing field. Plus all the lifetime learners. It's not unreasonable to estimate at least 2M CS students worldwide write or work on a compiler each year. Maybe a tad high, but also it's an idiom.

https://www.daxx.com/blog/development-trends/number-software...

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

#72

Post by rcarmo »

Spent my lunch break investigating this a bit and it is quite nice, with the only caveat (for my use case) being that networking is handled by a third-party socket library that, alas, does not handle multicast sockets (don't ask...).

Otherwise, examples are interesting, and certainly seem to cover most gamedev scenarios (haven't found any audio or MIDI ones yet).

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

#73

Post by kortex »

mlang23 wrote: post #27

The name is strange. Reminds me of a product-naming story I heard years ago. Papenmeier from Germany was once planning to create a small notetaker with built-in braille display. They originally planned to name it "Braille Assistant", but the US distributors objected on the ground that they can already see users shortening the product name to "Braille Ass". I have a similar feeling with Carp, isn't the obvious transpo…

It'll be good company with git, GIMP, LISP, ploopy.co, etc.

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

#74

Post by robertlagrant »

kortex wrote: post #71
brabel wrote: post #50

Earlier quoted context omitted.

> Millions of CS students... Are there millions of CS students in the world?? I would guess a few hundred thousand, at most.

Probably. There's 20-30ish million software developers in the world [1]. People work for 30-50 years, suggesting at least a million freshman CS students a year. It's a rapidly growing field. Plus all the lifetime learners. It's not unreasonable to estimate at least 2M CS students worldwide write or work on a compiler each year. Maybe a tad high, but also it's an idiom. https://www.daxx.com/blog/development-trends/num…

I have no actual opinion here. Just stopping by to point out that not (nearly) all software developers started as CS students.

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

#75

Post by timdeve »

kortex wrote: post #70

What's the difference between `let` and `the`? Skimmed the language guide and docs but it wasn't clear. `the` seems to be the typical type inference variable declaration. I'm not really familiar with lisps so this might be a documentation oversight. Looks really neat overall.

`let` is for declaring variables while `the` is a noop at runtime and only give type information to the compiler.

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

#76

Post by jbjohns »

silon42 wrote: post #61
astrange wrote: post #35

Earlier quoted context omitted.

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.

It's really surprising that it's rare in functional languages. Immutability seems like it should guarantee no cycles (?), so reference counting could be used.

Why would immutability guarantee no cycles? Here is a line of valid haskell:

        star e = let (sp, a) = (Split a e, atom sp) in sp
EDIT: I guess I should probably explain it: star is a function that takes an expression "e" and returns the value "sp" which is "Split a e" where "a" is the results of calling the "atom" function on "sp". This is creating a representation of a regex star operator. Note that the tuple defined in the let definition is only to define a name for the two values of the tuple so that they can refer to each other.

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

#77

Post by tzs »

jstimpfle wrote: post #62
xxs wrote: post #44

Earlier quoted context omitted.

lock free does not guarantee all participants have a fair treatment, e.g. one thread can keep losing the CAS (CompareAndSwap / LoadLinked/StoreConditional / etc.) and effectively spinning or need to yield. releasing the CPU resources. A non-blocking write should just copy the data to the socket buffer, definitely not taking milliseconds. Allocate buffers in separate threads - ok, that's the crux of it - the memory is…

> A non-blocking write should just copy the data to the socket buffer, definitely not taking milliseconds. That's the theory, right? It could be I measured something wrong, but sometimes dozens of ms is what I got, and I concluded that non-blocking I/O avoids indeterminate blocking (such as reading from a TCP socket until the sender sent N bytes) but does it completely avoid taking in-kernel locks etc? Probably not.…

> It could be I measured something wrong, but sometimes dozens of ms is what I got, and I concluded that non-blocking I/O avoids indeterminate blocking (such as reading from a TCP socket until the sender sent N bytes) but does it completely avoid taking in-kernel locks etc?

Perhaps what you were seeing were occasions where the system decided during your system call that your processes' time slice had expired or some I/O that some higher priority process was waiting for completed and it gave the CPU to some other process?

When timing things on preemptive multitasking systems it is often best to make a lot of measurements and then look for clusters. The time of the smallest cluster should be the time the operation itself takes.

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

#78

Post by medo-bear »

mlang23 wrote: post #41
protomikron wrote: post #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…

Lisp is definitely not as functional as for instance Haskell is. Side-effect-freeness was never really a topic for Lispers.

You are right, Lisp is far more versatile. There is even a statically-typed language Coalton [1] embedded into Lisp.

[1] https://coalton-lang.github.io/20211010-introducing-coalton/

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

#79

Post by wyager »

silon42 wrote: post #61
astrange wrote: post #35

Earlier quoted context omitted.

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.

It's really surprising that it's rare in functional languages. Immutability seems like it should guarantee no cycles (?), so reference counting could be used.

There are two ways to get cycles in Haskell.

One is through “tying the knot”. E.g. to create an infinite list of 1,1,1,1,1,…

ones = 1 : ones

This will actually be compiled to a list cell with a pointer back to itself. You can construct more complicated self-referential data structures thanks to laziness.

The other way you could get a cycle is that it actually does have mutable data structures, although their use is restricted so they can’t have any observable mutable effect in pure code. But you have e.g. IORef which is basically a mutable pointer.

If you wanted no cycles you would need to eliminate some subset of laziness, knot-tying transformations, recursion, and any support for mutable data structures. But yes, I think it could be done.

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

#80

Post by mumblemumble »

protomikron wrote: post #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…

In general, most lisps are imperative, or support multiple paradigms including imperative.

First-class functions are a necessary feature of FP, but the mere presence of the feature does not make a language functional. Some counterexamples include Fortran and Smalltalk.

It's an easy misconception because most the well-known newer entries to the lisp family - Scheme, Racket, and Clojure - are all mostly functional, and because most of the major non-functional dialects of lisp died out 30 or 40 years ago.

Post reply on HN