Hacker News Reader

Comment by AnkleInsurance | Hacker News Reader

Scheme was my first love, before we even knew what r6rs would look like.

I feel like r7rs-small rights the wrongs that r6 dumped on us. Scheme has always been a very fragmented community especially in the technical sense, there's a lot of scheme features that don't carry over to another implementation. However, I think most scheme subcommunities appreciate the spiritual benefits of immutable data structures, hygiene in macros, lambda calc, continuations once you grok them, streams, etc.

Clojure has filled the hole for a while but I suspect a scheme implementation with as sophisticated a packaging and build system as clojure/lein could be in the works somewhere ;)

View on HN

I wonder, would it be better to have something like an LLVM frontend for Clojure, rather than another new Scheme? Or, would we still have a long startup time, regardless of the platform? I know Clojure's startup time isn't to be blamed on the JVM, but since Clojurescript does not suffer from that issue, I'm not really sure where the problem is.

Looks like that's actually a work in progress: https://github.com/drmeister/clasp

chafmeister talks on youtube are worth a view, half for the lisp part, half for the biochem one.

Clojure doesn't have hygenic macros/continuations. Scheme people highly value these features.

Clojure's macros can be made hygienic using `gensym`. Is this not enough? Is it desirable to Schemers for it to be impossible to generate user-accessible symbols within a macro?

What if symbols in macros were hygienic by default, but we had a `pubsym` escape hatch, allowing us to specify the exact symbol name. Would that allay safety concerns, or does that make something else difficult/impossible?

Hygiene is a nicety that indeed can be emulated by unhygienic macros.

First class continuations however are less easy, and just as big a part of scheme. Callcc is a cult, nearly, and for good reason. With it, almost all local control patterns can be easily implemented so you can have things like fibers, coroutines, etc basically for free. It gets harder when you want asynchrony and parallelism, Andy Wingo has a great blog about guile internals and delimited continuation implementation, CML stuff, etc. If you're interested in higher-level scheme implementation, that's a good starting point.

Clojure has advanced control flow mechanisms and more sophisticated parallelism features than most scheme implementations, but this relies a lot on the underlying host platform. Callcc is made possible at the fundamental level of how scheme works. Pmaps in clojure work because the jvm is incredible and js engines are getting there too. LLVM is not the magic bullet for excellent language design, sometimes.

Gensym is not enough. There are two kinds of hygiene: avoiding capture by the macro of identifiers used in expressions supplied by the user, and avoiding capture by the user of identifiers supplied by the macro. See http://community.schemewiki.org/?hygiene-versus-gensym and, I guess, https://en.wikipedia.org/wiki/Hygienic_macro#The_hygiene_pro... . (There are surely better presentations of the idea out there, but I can't seem to find them right this minute.)

Not all Scheme people. Scheme is my favorite language, and I don't highly value call-with-current-continuation (and I claim to understand it well).

I would love clojure as a native platform but I have very little hope that it will happen.

Clojure a greatest strength was being able to use all the mature Java libraries. The jvm is an incredibly sophisticated platform, regardless of how shitty Java is. Clojure script benefits from the same concept by being able to run on node, use npm libraries, run on lighter devices in a quicker start-up than regular clojure, etc.

Common lisp and clojure have quite a few differences, though common lisp is certainly on clojures tail with regards to adoptability in enterprise. Scheme is a simpler, truer to principle language than CL.

Presumably, a native Clojure would be able to tap into the C/C++ ecosystem through similar FFI mechanisms. Granted, that code would be no more portable than the intersection of the platforms supported by each library, but that's already the situation with classic native code.

Yes, but that's a fundamental difference, don't you think? Java interop works on almost every device, same with js. I'm the context of just portability, tapping into Java code is more useful than tapping into c++ code.

I get where you're coming from, but there's a long list of reasons why it hasn't ever been done very well, not the least of which being that it just wouldn't be as useful as people think. There's a million languages that can talk to c/c++. Guile can do it, ruby can do it, Julia can do it, there's already some lisp cousins/friends that have that ability.

I'm not super familiar with clasp, but I'd bet anything that its missing some major features compared to sbcl.

Reply on news.ycombinator.com