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

Carp, a compiled Lisp with type inference and a borrow checker

blog.veitheller.de

Post reply on HN
Print view View original

91–100 of 112 posts

Re: Carp, a compiled Lisp with type inference and a borrow checker

#91

Post by steinuil »

jstewartmobile wrote: post #85
bjoli wrote: post #61

Earlier quoted context omitted.

But without dynamic typing and Cheney on the MTA and with a completely different way of managing memory. And not a scheme.

Scheme is a lisp, and I'm pretty confident that two of the biggest selling points of lisp are dynamic typing and a strong distaste for (if not an outright prohibition of) mutation. Put it as a question because if you take those two things away, wouldn't it just be Rust with parenthesis?

The selling point of lisp is macros, and macros alone. Different dialects will have different characteristics: Common Lisp is dynamically typed and usually makes heavy use of mutation, others like Lux are purely functional and statically typed.

> wouldn't it just be Rust with parenthesis?

That's pretty much what it is.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#92

Post by metaobject »

shakna wrote: post #36
zitterbewegung wrote: post #17

Earlier quoted context omitted.

That’s one of its strengths though . A lisp with type inference and performance is quite rare. More lisps should be less lispy .

> A lisp with type inference and performance is quite rare. You mean apart from several Scheme implementations? Chez Scheme is blisteringly fast, and on-par with C for quite a few things. Gambit-C (Compiles to C), Chicken (based on the Cheney-on-the-MTA model) and Bigloo (designed to replace C++) also deserve a reference here.

Bigloo has a special place in my heart. I spent a few years building scheme bindings to various C graphics and networking libraries. I can't quite put my finger on it, but I found it very enjoyable. Getting C-like performance from scheme is just wonderful.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#93

Post by metaobject »

steinuil wrote: post #91
jstewartmobile wrote: post #85

Earlier quoted context omitted.

Scheme is a lisp, and I'm pretty confident that two of the biggest selling points of lisp are dynamic typing and a strong distaste for (if not an outright prohibition of) mutation. Put it as a question because if you take those two things away, wouldn't it just be Rust with parenthesis?

The selling point of lisp is macros, and macros alone. Different dialects will have different characteristics: Common Lisp is dynamically typed and usually makes heavy use of mutation, others like Lux are purely functional and statically typed. > wouldn't it just be Rust with parenthesis? That's pretty much what it is.

> The selling point of lisp is macros, and macros alone.

That's a fairly bold claim.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#94

Post by metaobject »

yawaramin wrote: post #38

Very excited about Carp. In general I like the simplicity of Lisp but ironically I'm not a fan of dynamic typing. Carp may be a real innovation. A bit surprised though that the Carp C runtime functions are not namespaced. With names like `IO_println` there's a risk of clashes. Unless the compiler is doing some tricks to hide names?

Perhaps it's my OCD, but a Lisp with uppercase namespaces, etc. just rubs me the wrong way.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#95

Post by mwatts15 »

vog wrote: post #71
eriksvedang wrote: post #60

Earlier quoted context omitted.

OK, I see what you mean now. Thanks for the feedback, I'll make sure to think about this more before stabilising the modules.

I wonder how this compares to the Python ecosystem, whose standard library is also quite large. (Anyone remembers their famous "batteries-included" mantra?) Python 2 didn't have a stdlib namespace, or "package" in Python speak. But when they created their clean-slate approach with Python 3, they also decided not to introduce a stdlib package. External Python packages just avoid the stdlib package names, and everythin…

As a Python programmer, I would consider code which shadows the names of built-ins to be poorly written although it's permissible in small scopes (e.g., a single block).

OTOH, for extending / wrapping there is a builtins module, which I think is what you suggest: https://docs.python.org/3/library/builtins.html#module-built...

Re: Carp, a compiled Lisp with type inference and a borrow checker

#96

Post by jstewartmobile »

steinuil wrote: post #91
jstewartmobile wrote: post #85

Earlier quoted context omitted.

Scheme is a lisp, and I'm pretty confident that two of the biggest selling points of lisp are dynamic typing and a strong distaste for (if not an outright prohibition of) mutation. Put it as a question because if you take those two things away, wouldn't it just be Rust with parenthesis?

The selling point of lisp is macros, and macros alone. Different dialects will have different characteristics: Common Lisp is dynamically typed and usually makes heavy use of mutation, others like Lux are purely functional and statically typed. > wouldn't it just be Rust with parenthesis? That's pretty much what it is.

Yes, but will macros retain their power in a statically typed environment?

Re: Carp, a compiled Lisp with type inference and a borrow checker

#97

Post by bjoli »

jstewartmobile wrote: post #96
steinuil wrote: post #91

Earlier quoted context omitted.

The selling point of lisp is macros, and macros alone. Different dialects will have different characteristics: Common Lisp is dynamically typed and usually makes heavy use of mutation, others like Lux are purely functional and statically typed. > wouldn't it just be Rust with parenthesis? That's pretty much what it is.

Yes, but will macros retain their power in a statically typed environment?

They work OK in typed racket, but you will have to help the type checker a bit for the more complex macros.

And they provide utility that the type system doesn't. The for style loops are extremely useful

Re: Carp, a compiled Lisp with type inference and a borrow checker

#98

Post by steveklabnik »

bogomipz wrote: post #80

I'm curious about the borrow checker, is this Rust invention or did a similar concept exist elsewhere in some other language(s)? Can anyone recommend any resources specifically on the idea of the borrow checker?

https://forge.rust-lang.org/bibliography.html has links to previous work we built upon.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#99

Post by kazinator »

progman wrote: post #63
nickpsecurity wrote: post #34

Earlier quoted context omitted.

One of the good LISP's back in the day was PreScheme that let it finally be a C alternative efficiency-wise. It was also used in first, verified LISP. Such a style might also be good for bootstrapping or just making more flexible ways to code C. https://en.m.wikipedia.org/wiki/PreScheme Looking at PreScheme, Carp doing a C alternative safe without a GC is a nice evolution of these LISP's. Next cool possibility: use a…

> Next cool possibility: use a Rust-like LISP Why do you want a Rust with Lisp syntax? I don't see the benefits of such a "Lisp" if you take the core benefits of metaprogramming at runtime away which depends on the equality of code and data. Safe software can also be written in other languages than Rust. Ada is still industry standard of safe programming today. Even Lisp can be used to write safe software since Lisp'…

> The Lisp version would just not be as performant as Ada's and Rust's.

What makes browsers perform badly is the execution of all that Javascript.

In Lisp, we can scan Javascript and go to machine code with far less work than doing the same thing in Ada.

The Ada browser might beat the Lisp one on the raw rendering of a big HTML-only page.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#100

Post by NiceGuy_Ty »

jstewartmobile wrote: post #96
steinuil wrote: post #91

Earlier quoted context omitted.

The selling point of lisp is macros, and macros alone. Different dialects will have different characteristics: Common Lisp is dynamically typed and usually makes heavy use of mutation, others like Lux are purely functional and statically typed. > wouldn't it just be Rust with parenthesis? That's pretty much what it is.

Yes, but will macros retain their power in a statically typed environment?

The only requirement to make macros work in a statically typed environment is to create a suitable type to represent the source code, and provide the operations to transform the said type. For instance, Rust has a macro system that's pretty nice to work with.

https://danielkeep.github.io/tlborm/book/README.html

Post reply on HN