R7RS Considered Unifier of Previous Standards (2015) [pdf](andykeep.com)
andykeep.com
R7RS Considered Unifier of Previous Standards (2015) [pdf]
http://andykeep.com/SchemeWorkshop2015/papers/sfpw1-2015-clinger.pdf
22 comments
What's the general state of the Scheme community? I'm getting the impression that after the backlash against R6RS and R7RS most people moved on to Racket, Clojure, or Common Lisp.
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 ;)
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 ;)
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
Looks like that's actually a work in progress: https://github.com/drmeister/clasp
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.
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.
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.
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?
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?
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.)
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.
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.
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).
chafmeister talks on youtube are worth a view, half for the lisp part, half for the biochem one.
Isn't Racket Scheme? They have an R6RS language for Racket (http://docs.racket-lang.org/r6rs/Using_R6RS_with_DrRacket.ht...).
I don't see how that's "moving on" if it's still Scheme.
I don't see how that's "moving on" if it's still Scheme.
Racket is a Scheme descendent, but it isn't exactly Scheme.
https://racket-lang.org/new-name.html
A lot of modern languages seem to eschew what they are derived from; Pharo isn't Smalltalk either, SWI-Prolog now defaults to a standards-incompatible mode, etc.
https://racket-lang.org/new-name.html
A lot of modern languages seem to eschew what they are derived from; Pharo isn't Smalltalk either, SWI-Prolog now defaults to a standards-incompatible mode, etc.
I would say it is a consequence of their origins fading away on the mainstream or being stuck in some university classes.
So they have to search for new grounds, instead of being stuck into a design that no longer has the attention of the industry.
So they have to search for new grounds, instead of being stuck into a design that no longer has the attention of the industry.
Having a language defined by a standard is good if you can't have portable compilers/interpreters. Once your compiler is available on all the platforms you use, the utility seems to fall off a cliff.
I agree regarding standards, my point is that the existing standards got stuck into a point that does appeal to the masses any longer.
Another example is Pascal, the original standard was too little for what people were actually using it for.
Most of the extensions were then standardized as Extended Pascal, but no one cared because a selling point was being Turbo Pascal compatible.
Another example is Pascal, the original standard was too little for what people were actually using it for.
Most of the extensions were then standardized as Extended Pascal, but no one cared because a selling point was being Turbo Pascal compatible.
Racket is a scheme in one sense but not spiritually. It's a unified learning environment. The editor works hand in hand with the language engine, which you can mold however you like, there's a sophisticated package system, etc. It's practically an insult to describe racket as "a scheme implementation". It's not wrong, but it's a massive understatement.
No, Racket is a separate language, though it grew out of a Scheme implementation (PLT Scheme) and still includes its predecessor.
I thought that PLT Scheme had actually diverged from Scheme (though it included an R5RS implementation) long before they decided to change to Racket the name based on that fact.