I don't know what this refers to, but it doesn't ring a bell. The most I might have said is that the community in general is not too interested; but personally, this kind of dynamic interaction is something that I very much appreciate. In fact, when I implemented xrepl (which is now the default when you start racket) being able to modify code inside modules was one of the main goals. The only reason I didn't do something like that for Emacs is that my own use of CL/Scheme variants in Emacs was always very simple, but I actively encouraged people to do something similar for Emacs -- and Geiser/Racket-mode are two serious Emacs packages that actually do that kind of interactive use.
I asked you guys about image-saving because I was considering using Racket to build a new version of bard, and I thought I might like to both use image-saving during development and piggyback on a Racket implementation of it for use in bard's runtime. As I recall, you guys wanted to know what I found compelling about image-saving, but you didn't find it as compelling as I did.
I still might build a bard on Racket, but if so, I'll most likely build my own VM and implement my own image-saving solution for it.
Assuming, of course, that there are enough hours in the day, and enough years in a life.
You could have used the scribble reader (the @-expression syntax, not to be confused with the full documentation system). But you'd also then find that there is a more robust way to get what you implement with a simple definition:
Yes! This is why I chose to use #@ instead of @, to avoid conflict with at-exp reader. As noted below by moron4hire, the @-exp reader is the better solution for this problem. I concentrated on providing an example of how to extend the reader, not on making an example of a useful or needed extension. I should have probably written this on top of the post...
From http://racket-lang.org/new-name.html -- "Racket is a Scheme". The name change was about very different things than "basic scheme routines", and it would be hard to find any basic scheme implementation without any.
You should be careful here, and not lump together "many Schemes" and "Racket" (or other specific Scheme implementations). The thing is that Scheme standards have traditionally avoided tying the language with a macro system that requires some specific representation for syntax -- giving you only the simple rewrite rules system means that you don't actually need to know that representation.
In Racket, OTOH, there are definitely syntax objects with enough functionality to write code that handles them, and I suspect that you know that. The question is whether this should be considered "homoiconic" or not, but this is a kind of a subjective issue, since at an extreme, I can say that all languages that have strings are homoiconic. Perhaps you need more from the language to make it so, maybe eval, or maybe actually require it to have compile-time procedural macros? In any case, Racket will have all of the features that CL does, so it is arguably at least "as homoiconic" as CL is. But in fact, it has more than just s-expressions: these syntax objects are basically sexprs + a bunch of stuff like source location and lexical context, so in fact they represent more than what lists in CL do. Should I then conclude that Racket is more homoiconic than CL? And this is not a tongue-in-cheek argument: in fact, many CL implementations are aware of the limits of sexprs as good representation for code, and add things like source location via a backdoor, like a hash table that maps pair objects to additional properties. Racket does that in its basic syntax representation so IMO it's fine to indeed consider it more homoiconic. And I also say that for the addition of lexical context information -- that's something that is not only included in the Racket syntax object, it's something that you just cannot get in CL, so if homoiconicity is being able to have a high-level representation of code (unlike raw strings), then this is another point where Racket wins the pissing context.
Finally, it's not that all "many Schemes" are limited as described above -- there are many of them that have their own macro systems with similar syntax values, and that includes Schemes that follow R6RS since that dictates syntax-case which comes with them. It just happens that Racket is has been traditionally running at the front lines, so it's more advanced.
It's not really necessary to second you, but I'd like to add that "code as data" is more real in Racket than is CL since code is not just the AST, it's also (as you point out) location and more importantly, context. In this setting Racket' syntax objects are more "code as data" than "code as sexp" as it is in CL will ever be.
Right. Perhaps a better way to summarize this is that:
* Lisp made the first giant step of having code representable as data for meta-programming, and chose sexprs to do so
* Common Lisp came later, and made the important step of requiring this representation, which means that in every CL implementation you're required to have the code as data aspect
* But the flip side of this is that CL hard-wires just sexprs, it forbids an extended type, which means that you can't get anything more than sexprs (without resorting to "extra properties" hash table tricks)
* Meanwhile, Scheme (R5 and others that have only `syntax-rules') took a step back by specifying only rewrite rules which can be implemented in any way an implementation chooses
* But some Scheme implementations did use sexprs, but since they need to encode more information (lexical context) they extended them into syntax values (note that some Scheme low-level macro systems try to present users with a simplified interface where user code sees just the sexprs)
* Later on, Racket took further steps and enriched its syntax values with "more stuff"
* R6RS got closer to this too, by adopting the syntax-case system (but some people had issues with "wrapping" symbols, since you can't do that with the hash table trick)
* And finally, R7RS (the "small" version) is going to take a step back into the R5RS days. (And in the "big" language it looks like they'll adopt one of these systems that try to keep the sexpr illusion.)
All of this sounds like you're one of these people who see parens and run away screaming "LISP!". Yes, the default Racket syntax uses S-expressions, but concluding that it's in some way lumped with Emacs Lisp is extremely wrong. And yes, Racket has syntax that can be tweaked using macros -- but it's a far stretch to go from this to that being the thing that drives all Racket coding. After all, OCaml now has CamlP4 as something that is an integral part of the language -- does that mean that meta-programming is now the thing that drives OCaml coding???
Another point: yes, Racket programmers know and use tail-calls, but that has nothing to do with "the looping constructs provided in the library" since those are implemented in terms of the same facility. The existence of these loops is therefore not making the language any less functional than the fact that you can implement a while loop in Haskell. The bottom line is that Racket is as functional a language as the interpretation of the term was before Haskell kidnapped it and turned it into some religious point.
(BTW, if you want to bash lisps, do yourself a favor and drop the all-caps "LISP" -- it immediately demonstrates the kind of limited knowledge you have on it.)
I strongly disagree. The vast majority of Racket code I've looked at would be far easier to translate into, say, Common Lisp than Haskell (or Erlang, which is probably a more illustrative example since it has dynamic typing). Emacs Lisp is pretty different because it doesn't have lexical scoping and it's only really used in the Emacs runtime environment (although it resembles Common Lisp syntactically), but programs written in Racket, Common Lisp, and Clojure (and other LISP dialects that support lexical scoping and macros) tend to be way more similar to each other than are programs written in Racket and languages we traditionally think of as functional. If you're still not convinced, I'm sure a bit of digging online would reveal way more crossover between Racket and other LISP dialects by the same developers than you get with Haskell or ML developers crossing over to Racket.
As for your parenthetical add-on, I'm not bashing LISPs at all. I think Racket is a beautiful language, in part precisely because it has the power of a LISP dialect. As for your second point, using the capitalized form is the only unambiguous word that refers to the family because many developers in the Common Lisp community use Lisp to mean CL. The reddit style "do yourself a favor" and ill-formed judgments about people's "limited knowledge" are way less constructive than asking "why did you use that spelling." Please keep discussions on HN objective and civil.
Um, when I write code in Typed Racket (and I have a whole course using it), the code tends to be much more similar to ML than to conventional Lisps. When I write code in Lazy Racket, it is somewhat like a dynamically typed version of Haskell, and unsurprisingly not too similar to other Lisps. Same goes for a whole bunch of stuff. Another random example: there's a whole library of functional data structures that is based on Okasaki's book.
In fact, if you want to focus on macros as some kind of a driving force for code -- then it that exact aspect (a) macros in Racket can be very different than macros in other Lisps; (b) more than that, there are many kinds of macros in Racket that you cannot write in those Lisps. As for digging on-line for crossover code from other Lisps that finds its way into Racket: you'll obviously find a lot of Scheme code, but practically nothing from other Lisps. The bottom line is that the syntactic "lots of parens" similarity is an extremely shallow one.
Bottom line: Racket is roughly at the same level of a "functional programming language" as ML etc, certainly more than Python and Ruby where side-effects are embraced much quicker. Like you said, "even have equivalents of map..." -- whereas in Racket these kind of functional/non-destructive operations are expected. (For example, the Racket GC is tuned to perform well when allocating lots of short-term objects, something that is a direct result of FP being the most dominant style.)
And yes, I know that you're not bashing Lisp -- you're just quick to lump all Lisps on the same pile, and reach the obviously bogus conclusion that first-class syntax is the thing that drives code. (That's a point that is subjectively obvious to me, as someone who has been in this part of the PL world for more than two decades.) "LISP" is, BTW, just an outdated spelling, period. It's true that in CL circles "Lisp" is taken as implicitly meaning "Common Lisp", but in the same circles "LISP" is taken implicitly as "an outdated spelling for Lisp, therefore Common Lisp" unless you're one of the old farts whose making a reference to LISP 1.5 or something as ancient.
Racket now includes a new facility -- "features" -- which are essentially a lightweight OS-level thread. There's also another -- "places" -- which is a more separated heavy threads (closer to a new process), but that one is not enabled by default.
