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

101–110 of 139 posts

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

#101

Post by jstimpfle »

xxs wrote: post #99
jstimpfle wrote: post #98

Earlier quoted context omitted.

Preemption can happen even outside of system calls of course, but I guess my takeaway has been to just avoid calling into the system where a lot of things can happen that I don't really understand or control. That, plus setting my threads to high-priority and possibly pinning them to the right cores.

>That, plus setting my threads to high-priority and possibly pinning them to the right cores. What language was that - [normally] Java does not respect priorities at all for instance. Running with higher priority may require root as well.

Language was C, running as root on some Linux 3.x on some ARM/FPGA development board. By setting threads to high-priority I mean something like pthread_setschedparams(... SCHED_FIFO ...).

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

#102

Post by RobertKerans »

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…

& Rust is surely a highly imperative language that has absorbed functional idioms (where appropriate), rather than something that falls under the banner of "functional language"?

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

#103

Post by soegaard »

HPsquared wrote: post #88
stan_rogers wrote: post #69

Earlier quoted context omitted.

The letter combination "fi" seems to have been deleted throughout your quote, there. Perhaps it was a ligature in the original.

I was thinking it lacks a foreign function interface (FFI)

I believe it has one today.

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

#104

Post by white-flame »

brabel wrote: post #51
baq wrote: post #18

Earlier quoted context omitted.

AOT doesn't necessarily mean GC-less, right?

Maybe they actually mean VM-less, which would probably imply GC-less because if you have a GC, you pretty much have a VM doing the GC (unless it's simple ref-count). For embedded, you need VM-less, I think, as VMs tend to be too heavy.

VMs imply a non-native bytecode execution. Garbage collection doesn't require any of that.

It's just normal library code usually called by the allocator, and well-specified memory object/pointer layouts.

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

#105

Post by pjmlp »

aidenn0 wrote: post #97
pjmlp wrote: post #82

Earlier quoted context omitted.

C++/CLI comes to mind, as means to merge .NET and C++ worlds together.

Oh gosh, I forgot about that. Is that Windows only though? I remember MSVC had managed/unmanaged C++ and allowed calling between the two.

Sadly yes.

And although they don't have much love for it, they still keep it relatively up to date.

It was one of the .NET Core 3.1 main milestones.

However I would say for the purpose of binding .NET and C++, probably it doesn't need to understand everything anyway.

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

#106

Post by JoelMcCracken »

jbjohns wrote: post #76
silon42 wrote: post #61

Earlier quoted context omitted.

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…

I mean generally tying the knot is a useful technique, but I think these scenarios all require/exploit non-strict, which is in itself not really immutable in the sense most people use it.

But yes, such code is often useful so that e.g. a parent xml node can refer to its childen nodes while also children nodes can refer to their parents.

Anyway, I'm not sure about this, but I think you can't have circular data structures in the context of strict evaluation (or can you? maybe by defering execution via anonymous functions? I wonder....)

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

#107

Post by dwohnitmok »

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.

The big thorn is closures, which show up all over the place in FP. You either need to limit closures vs ordinary functions (as e.g. Rust does), have manual memory annotations (such as e.g. what Swift does) or you basically need a GC. The former two choices are annoying if you really take advantage of functions as first-class citizens.

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

#108

Post by andi999 »

pjc50 wrote: post #63
andi999 wrote: post #60

Earlier quoted context omitted.

So how is memory fragmentation avoided?

That's a question for the underlying allocator, surely? (Quite often the answer is "it isn't")

Not just for the allocator. I always thought a main point of a garbage collector was heap compactification (shuffling things around so there is more space), but maybe I am wrong.

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

#109

Post by gavinray »

simiones wrote: post #33
xvilka wrote: 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 collecti…

Dr Schafmeister is occasionally present on the LLVM Discord. The CLASP project is something else. That hour-long talk he gives on Youtube about it blew my mind.

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

#110

Post by a0-prw »

HPsquared wrote: post #88
stan_rogers wrote: post #69

Earlier quoted context omitted.

The letter combination "fi" seems to have been deleted throughout your quote, there. Perhaps it was a ligature in the original.

I was thinking it lacks a foreign function interface (FFI)

I just thought it was so effficient, it left out the effs ;)
Post reply on HN