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 high performance applications

github.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#41

Post by blastrat »

imtringued wrote: post #29
cbebdhhd wrote: post #17

Earlier quoted context omitted.

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?

unless you're thinking of something that I'm not thinking of? RPN only solves this when the operators are known and used exclusively in operator context and can be relied on as implied close-parens

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#42

Post by eudox »

PDoyle wrote: post #40
rurban wrote: post #33

Earlier quoted context omitted.

Very simple. The compiler, written in lisp (with a GC) just generates C code, which is compiled and executed. Without any GC, it tracks the vars.

No, not simple. Analyzing an arbitrary lisp program to determine the lifetimes of all allocated structures reduces to the halting problem, so it's undecidable. You must either restrict the input program or tolerate some leaks.

>arbitrary lisp program

Well, Carp is a dialect of Lisp so it's free to impose whatever semantics it wants. It's not a dynamically-typed language (where it would indeed be impossible to statically manage memory).

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#43

Post by eriksvedang »

eudox wrote: post #42
PDoyle wrote: post #40

Earlier quoted context omitted.

No, not simple. Analyzing an arbitrary lisp program to determine the lifetimes of all allocated structures reduces to the halting problem, so it's undecidable. You must either restrict the input program or tolerate some leaks.

>arbitrary lisp program Well, Carp is a dialect of Lisp so it's free to impose whatever semantics it wants. It's not a dynamically-typed language (where it would indeed be impossible to statically manage memory).

Yes, only the statically compiled code is GC free.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#44

Post by madgar »

larsbrinkhoff wrote: post #35
tom_mellior wrote: post #32

Earlier quoted context omitted.

> In contrast, the compiler generates GC-free code. Yes, but the question was how it does that. Does it reject code where it cannot reliably detect lifetimes? Or does it generate code that just does not deallocate (i.e., that leaks) objects whose lifetime the compiler can't determine? Both of these are "GC-free"...

The compiler does lifetime analysis, and there is a "reference borrowing" concept like in Rust.

So it rejects code for which it can't prove lifetimes. Why not just say so? There's an uncomfortable degree of beating around the bush in this thread.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#45

Post by eriksvedang »

_pmf_ wrote: post #11

To the author: please, please, please port (or reuse) LuaJIT's C-header parser for FFI; it's the best FFI interface specification method if seen among JNI, Python, V8 and even C# (because you can just use the C header, with support for typedefs, unions and packing). It really looks like a great language!

Interesting, thanks a lot for the tip!

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#46

Post by eriksvedang »

akavel wrote: post #22
eriksvedang wrote: post #14

Earlier 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

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? Al…

No tail recursion at the moment but it's something I'd be interested in adding later.

I'm being very conservative with adding different type constructs but sure, Rust & Go certainly gets a lot of things right in that department and I'll consider their solutions for the future development of Carp.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#47

Post by akavel »

madgar wrote: post #44
larsbrinkhoff wrote: post #35

Earlier quoted context omitted.

The compiler does lifetime analysis, and there is a "reference borrowing" concept like in Rust.

So it rejects code for which it can't prove lifetimes. Why not just say so? There's an uncomfortable degree of beating around the bush in this thread.

Curious if semantics of this subdomain of "allowed/legal" programs will be easy to understand, or will it be "try and see on case-by-case basis if your code compiles". Still, this way or the other, probably user will have to gradually learn and build intuition, as with learning any other aspect of any programming language.

Also: will be/is the lifetime-checking done in the same way in the interpreter, even though it uses GC? Otherwise, those are in effect two, I think significantly different dialects of the language.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#48

Post by nickpsecurity »

acron0 wrote: post #19

This 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).

PreScheme was designed to replace C in general. It's just been sitting there with no love or further development.

https://en.wikipedia.org/wiki/PreScheme

I imagine some techniques behind Chicken Scheme in area of optimization might help it too.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#49

Post by nickpsecurity »

eriksvedang wrote: post #46
akavel wrote: post #22

Earlier quoted context omitted.

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? Al…

No tail recursion at the moment but it's something I'd be interested in adding later. I'm being very conservative with adding different type constructs but sure, Rust & Go certainly gets a lot of things right in that department and I'll consider their solutions for the future development of Carp.

Neat to see a contender to replace what should've had plenty of adoption in this area:

https://en.wikipedia.org/wiki/PreScheme

I still don't see a clear answer to junkie's question despite a huge thread. Let's be specific: "Where no GC is used, how exactly do you handle the issue of memory safety? Is it no safety like C, a specific analysis like Rust, or something different entirely?"

Far as concurrency, you probably know about Rust's scheme. The ones that came before it that you might want to consider were Ada Ravenscar and Eiffel's SCOOP.

https://en.wikipedia.org/wiki/Ravenscar_profile

http://www.sigada.org/ada_letters/jun2004/ravenscar_article....

https://en.wikipedia.org/wiki/SCOOP_(software)

http://cme.ethz.ch/publications/

SCOOP might be the more interesting of the two for you. It was deployed in real-world apps in Eiffel first. Then, a team ported it to Java. It had a performance penalty. One of the many works in publications... don't remember which... did something ("slices?") that knocked out almost all that overhead. Another model-checked it to eliminate a few errors in SCOOP model. I see one on message-passing. So much badass work and results on SCOOP model I've been annoyed that it was ignored by mainstream for so long.

So, hope those help in your thinking on tackling concurrency. Personally glad I looked it up for you as I found this very, interesting project for safe use of GPU's:

http://se.inf.ethz.ch/people/poskitt/publications/Kolesniche...

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#50

Post by eudox »

madgar wrote: post #44
larsbrinkhoff wrote: post #35

Earlier quoted context omitted.

The compiler does lifetime analysis, and there is a "reference borrowing" concept like in Rust.

So it rejects code for which it can't prove lifetimes. Why not just say so? There's an uncomfortable degree of beating around the bush in this thread.

That's not quite how I'd put it. The documentation is pretty scarce, but if it's anything like Rust, you have to be explicit about ownership and somewhat explicit about lifetimes.

That is, it's not just "rewrite your program until the prover succeeds".

Post reply on HN