This project looks really good. I would love to have a clojure inspired lisp that's fast and doesn't require the JVM.
You might try Avian or Multi-OS Engine for embedding a JVM within your program.
Carp, a compiled Lisp with type inference and a borrow checker
51–60 of 112 posts
Re: Carp, a compiled Lisp with type inference and a borrow checker
#52I really want to like Carp but I somehow feel that the Rusty memory model does not fit the Lisp philosophy... all the borrowing story comes from a basis mutability. I wish for something more Clojurish based on immutable data. Then one can exploit the power of inferred type linearity/affinity to transparently build safe "transients" and other cool stuff. Maybe some day I should write such Lisp myself on top of my C++…
> does not fit the Lisp philosophy... all the borrowing story comes from a basis mutability
I found this to be a confusing statement until I realized you were talking about Clojure. Common Lisp condones mutation, and a borrowing model could be helpful for optimizing memory allocations.
Re: Carp, a compiled Lisp with type inference and a borrow checker
#53[deleted]
Re: Carp, a compiled Lisp with type inference and a borrow checker
#54The borrow checker is the reason to use Rust, in spite of its annoyances (clunky syntax, limited type inference, non-interactive programming, long compilation times, etc.), so it's always nice to see someone trying to provide the upsides of Rust without the downsides. That being said, your website is disappointingly terse regarding how Carp recovers the advantages of Rust in the context of a Lisp derivative. What mak…
Correct me if I'm wrong, but you can't be sure if programmers used a static analysis tool ? Maybe they used it just enough to make sure it compiles ? And if all you get is a binary, you can't even run those tools yourself. That's my problem with the argument: "The language has issues, but you can run static analysis tools" and "it takes some self-discipline". If you take over someone's code, you're back to square one.
Rust, on the other hand, could be called Trust. Borrow checker is for everyone.
Re: Carp, a compiled Lisp with type inference and a borrow checker
#55The borrow checker is the reason to use Rust, in spite of its annoyances (clunky syntax, limited type inference, non-interactive programming, long compilation times, etc.), so it's always nice to see someone trying to provide the upsides of Rust without the downsides. That being said, your website is disappointingly terse regarding how Carp recovers the advantages of Rust in the context of a Lisp derivative. What mak…
Correct me if I'm wrong, but you can't be sure if programmers used a static analysis tool ? Maybe they used it just enough to make sure it compiles ? And if all you get is a binary, you can't even run those tools yourself. That's my problem with the argument: "The language has issues, but you can run static analysis tools" and "it takes some self-discipline". If you take over someone's code, you're back to square one…
> Correct me if I'm wrong, but you can't be sure if programmers used a static analysis tool?
I could be sure that they used a static analysis tool, for example, if I watched them use it. But that alone is not enough: the static analysis tool has to be sound, and most static analysis tools for C and C++ deliberately aim for less than soundness.
Re: Carp, a compiled Lisp with type inference and a borrow checker
#56As a Perl programmer, that name confuses me slightly.
## confusing indeed
... || croak "Wrong language!";
Re: Carp, a compiled Lisp with type inference and a borrow checker
#57Earlier quoted context omitted.
So Carp could compile to that subset of C++. But C++11 isn't _just_ that. It is all of C++11. C++ would even more successful if it was easy to make a proper subset of it.
That's what the GSL was supposed to be https://github.com/Microsoft/GSL It seemed really cool. All compile time checks. I have no idea why it didn't take off
Sure it did.
Some of the new C++17 library updates come from there, and both clang and VC++ implement those static checks.
Re: Carp, a compiled Lisp with type inference and a borrow checker
#58Others might be interested in Henry Baker's Lively Linear Lisp [0] HN Discussion. https://news.ycombinator.com/item?id=14248419 [1] http://home.pipeline.com/~hbaker1/LinearLisp.html
Loved that article, made me realize a lot of things about ... lots of things.
Re: Carp, a compiled Lisp with type inference and a borrow checker
#59It seemed they don't distinguish between mutable and immutable references (?). Does Carp not handle the issue of shared mutability, eg. iterator invalidation, like Rust?
Correct, not at the moment. Overall the type system is less expressive but also less dependent on annotations. Differentiating between immutable and mutable refs is probably coming though, it’s a useful distinction for sure.
Is there a documentation about the type system somewhere?
Re: Carp, a compiled Lisp with type inference and a borrow checker
#60Earlier quoted context omitted.
The ”IO_” part is the namespace, so no clashes!
It's not enough :-) Ask the OCaml folks, they're going through this pain right now because their stdlib modules are called `Array`, `List`, and so on. They're planning to put them all under `Stdlib`, so e.g. `Stdlib.Array` and so on, but it's going to be a big effort with a lot of pain. The main problem will arise when users create their own libraries; suppose some people create a `Option` libraries and then later yo…
OK, I see what you mean now. Thanks for the feedback, I'll make sure to think about this more before stabilising the modules.