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

71–80 of 112 posts

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

#71

Post by vog »

eriksvedang wrote: post #60
yawaramin wrote: post #44

Earlier quoted context omitted.

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.

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 everything seems fine.

So, is there something in the Python language that makes the missing?

Or is it just the Python community which doesn't care about (or plays down) this issue?

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

#72

Post by geokon »

pjmlp wrote: post #57
geokon wrote: post #46

Earlier quoted context omitted.

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.

I've only have a pretty basic understanding of how it works, but I thought the checks didn't rely on the compiler. They're special templates that fail when their conditions aren't met

And when I say it didn't take off - I mean that I haven't come across a single large project that has take up using the GSL. Hope I'm wrong - maybe I just haven't looked in the right place?

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

#73

Post by catnaroek »

hellerve wrote: post #68
catnaroek wrote: post #43

The 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…

While I do agree with the fact that one of the best features of Rust is the communication, I’d tend to find the comparison of the two a little unfair. Carp is very young and in an entirely different position than Rust. That being said, this is why I want to start to write more blog posts about Carp. I had to wade through the deep waters alone, with occasional help in the Gitter channel. Now I want to share that exper…

> Carp is very young and in an entirely different position than Rust.

If anything, Carp's is an advantageous position relative to Rust: You don't risk breaking many other people's code by fixing any type safety holes you find along the way. Which you will, not because you're stupid, but rather because type system design is applied formal logic, and formal logic is frigging hard for humans.

> While I do agree with the fact that one of the best features of Rust is the communication

It's not just that they communicate something, but rather what they communicate. Most language designers that have a user community do a reasonable job of explaining how new language features solve existing problems users face. However, they usually do a poor job of explaining how new language features interact with previously existing ones in all possible cases, and the main reason for this is that language designers have trouble anticipating these interactions to begin with. In other words, language designers don't understand their own designs! Matsakis' blog shows that the Rust's developers do a much better job than other language designers in this regard.

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

#74

Post by hashkb »

arximboldi wrote: post #64
kmill wrote: post #52

Earlier quoted context omitted.

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

You are right that a lot of Lisps consider themselves more procedural than functional and I was extrapolating Clojure there. (In my defense, the Scheme community is also very functional and immutable oriented)

I use set! whenever I feel the urge.

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

#75

Post by hellerve »

catnaroek wrote: post #73
hellerve wrote: post #68

Earlier quoted context omitted.

While I do agree with the fact that one of the best features of Rust is the communication, I’d tend to find the comparison of the two a little unfair. Carp is very young and in an entirely different position than Rust. That being said, this is why I want to start to write more blog posts about Carp. I had to wade through the deep waters alone, with occasional help in the Gitter channel. Now I want to share that exper…

> Carp is very young and in an entirely different position than Rust. If anything, Carp's is an advantageous position relative to Rust: You don't risk breaking many other people's code by fixing any type safety holes you find along the way. Which you will, not because you're stupid, but rather because type system design is applied formal logic, and formal logic is frigging hard for humans. > While I do agree with the…

I’m not sure what you’re trying to tell me here, so maybe this comment is going in the wrong direction entirely:

I think we are on the same side of the fence. Reasoning about your designs—and communicating your reasoning openly, not fearing scrutiny but rather embracing it—are important in any project.

But you compare an introductory article in which I try to explain a language to prospective users or other interested parties with the notes, musings, and writings of someone working on a compiler, aimed at an entirely different set of interested parties. Sure, in the end we’re all programmers and should all be interested in both, but trying to cover both at the same time will only result in mental overload.

I’m also in no position to talk about these things. I provide the occasional compiler bug fix, but I’m not the principal driving force behind the compiler. I build tools and libraries with Carp, and see whether it breaks in interesting ways, or try to come up with use cases that don’t yet exist. In other words, I’m just a user.

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

#76

Post by hellerve »

hellerve wrote: post #66
thomastjeffery wrote: post #19

Since this is about a pre-alpha language, it would be helpful for future web searchers to have a date in the title.

That’s probably true. I honestly didn’t expect this little blog post to gain that much attention, honestly.

Comments like these are the reason why I need an editor.

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

#77

Post by pjmlp »

geokon wrote: post #72
pjmlp wrote: post #57

Earlier quoted context omitted.

Sure it did. Some of the new C++17 library updates come from there, and both clang and VC++ implement those static checks.

I've only have a pretty basic understanding of how it works, but I thought the checks didn't rely on the compiler. They're special templates that fail when their conditions aren't met And when I say it didn't take off - I mean that I haven't come across a single large project that has take up using the GSL. Hope I'm wrong - maybe I just haven't looked in the right place?

No, GSL is a kind of stop-gap solution, until standard catches on.

For example std::string_view and ongoing design on std::array_view are based on gsl::span. The gsl::byte is also no longer needed on C++17 thanks to std::byte as yet another example.

The GSL asserts are there until code contracts[0] get into the standard.

The magical types like gsl::owner allow clang-tidy and VC++ checkers to apply a Rust-like memory tracking usage.

Kate Gregory did a presentation at CppCon 2017.

"10 Core Guidelines You Need to Start Using Now"

https://www.youtube.com/watch?v=XkDEzfpdcSg

As for not taking off, being initially a Microsoft proposal, it is surely used by Office and Windows teams, specially given they already use SDL (Security Definition Language) macros as well.

[0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p054...

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

#78

Post by duneroadrunner »

geokon wrote: post #46
sitkack wrote: post #39

Earlier 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

The problem is that, while in many ways an improvement over traditional coding practice, the subset of C++ associated with the Core Guidelines (GSL stands for "(Core) Guidelines Support Library") has turned out to be a dead-end when it comes to memory safety. In fact it formalizes the depenedency on intrinsically unsafe elements like native pointers, std::shared_ptr, etc. I mean, with "regular" C++ you're not actually obligated to use those intrinsically unsafe elements. With the Core Guidelines you are.

SaferCPlusPlus[1] is an alternative subset of C++ that doesn't have that same problem. It achieves memory safety by simply excluding the intrinsically unsafe elements and providing memory-safe alternatives.

> All compile time checks.

Not quite in reality. One small issue with the GSL, for example, is that its not_null pointer class does a run-time check on every pointer dereference[2]. SaferCPlusPlus can enforce "not null"ness at compile-time.

A bigger example, for instance, is the situation where you want to allow multiple threads to simultaneously modify different parts of an array. With SaferCPlusPlus, this is straightforward and safe [3]. With the GSL/Core Guidelines, less so.

I don't know how much these technical considerations factor into (or will factor into) popularity of adoption. I don't know how big the intersection is of the sets of developers who take code safety seriously and those who remain interested in C++.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[2] https://github.com/Microsoft/GSL/blob/1c95f9436eae69c9b93159...

[3] https://github.com/duneroadrunner/SaferCPlusPlus/blob/278b40...

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

#79

Post by baldfat »

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.

Racket which is moving to a Chez Scheme top and you can further go with typed Racket seems to fit that 'rare' category.
Post reply on HN