Category talk:Racket

From Rosetta Code

racket IS scheme

Racket is a language from the Scheme family. lest we give every scheme language a separate category they should all be categorized under Scheme

this page should be renamed from Category:Racket to Racket, but i am not doing that now because i am not sure how that affects all the racket solutions. they may need to be moved to scheme first.--eMBee 07:54, 9 November 2011 (UTC)

There is some ambiguity about this. At which point does something become a separate language vs an implementation of the same language? Can the makers of an implementation simply decide that it is a new language? From what I hear, there are some incompatibilities between Racket and Scheme. Wikipedia currently calls Racket a programming language: which it does not do for other implementations of Scheme. Many questions on StackOverflow simply say "Racket" without mentioning "Scheme". -- 09:44, 9 November 2011 (UTC)
Scheme is defined here in form of reports. the latest of which is R6RS. Racket implements R6RS.
as for your question i think for rosettacode the answer may be different than for other places. i think it is beneficial to have all scheme dialects in one place for easier comparison.--eMBee 10:15, 9 November 2011 (UTC)
Racket's documentation, at Dialects of Racket and Scheme, claims that Racket and R6RS are different dialects: "beware that the syntactic forms and functions of R6RS differ from Racket."
it also says that racket is based on the scheme branch of lisp, meaning that racket is a dialect of scheme. the same claim is made by other scheme implementations.--eMBee 06:19, 10 November 2011 (UTC)
[1] has more details about the relationship between racket and scheme.--eMBee 06:38, 10 November 2011 (UTC)
Among the contributors to Rosetta Code, the authors of Racket and Scheme examples should decide whether Racket is Scheme, or Racket is a separate language. A page like 24 game should not have a Racket section and also, at the same time, have "PLT Scheme" in its Scheme section.
Rosetta Code removed "Category:Bash" and "Category:Korn Shell", because those are implementations of Category:UNIX Shell, not separate languages. I am currently emptying "Category:Zsh" for the same reason. This is good because I can write one program at Primality by trial division#UNIX Shell to work with Bash, Korn Shell and Z Shell. However, I also created Category:C Shell as a separate category. I still want to group C Shell with UNIX Shell, so I always put a subsection ==={{header|C Shell}}=== under section =={{header|UNIX Shell}}==. --Kernigh 04:54, 10 November 2011 (UTC)
i like that approach. it would certainly work for racket if people think that racket needs its own language entry (i am not convinced of that yet). ideally i'd go even further and group all lisp implementations that way, but that may not be practical with the current structure in rosettacode. (and it would be a lot of work for little gain)
one thing that also speaks against the racket category is that it is only recently renamed from plt-scheme. i doubt anyone would even consider plt-scheme to not be scheme. but if plt-scheme is scheme, then racket must be as well. (unless they changed the language and racket is incompatible to plt-scheme)--eMBee 06:19, 10 November 2011 (UTC)

Racket goes well beyond what other Scheme implementations offer. The difference itself is much bigger than the whole spec of a large language like common lisp. Furthermore, while it is a descendant of "Scheme", it diverged considerably -- to a point where moving code back and forth from Racket to other Schemes requires *porting*. (Note that this does not contradict having R6RS implemented -- it is just a language among many that are implemented in Racket, but in fact it is not used for any of the functionality that comes with Racket.) To make things more concrete, I went over some of the pages in the Category:Racket page -- that addresses the more important question of what would people get from having the racket solution be listed as "Scheme". From the 18 solutions, I counted exactly one (Accumulator factory) which would work in all Schemes, and another (Dot product) that might work on some since it relies on features that are not guaranteed by the standard (and by many implementations). The rest are all pieces of code that have no hope to ever work in any other scheme.

thank you, that is very helpful. by no hope do you mean the code in present form (without changes) or do you mean that even small changes would not be enough to make it work in other schemes? in other words, accepting that the solutions are different from standard scheme, how different are they really? --eMBee 15:05, 26 November 2011 (UTC)
There are things like hash tables that have a specific interface in Racket, which is different from what you'd find in other implementations, if you'd find it (hash tables are included in R6RS, but the upcoming R7RS standard changes the interface again, which means that currently there is no real standard for hash tables in whatever you'd call "Scheme"). Then there are the very popular "for" and related forms, which are specific to Racket; there are similar iteration forms for some other implementations, but they usually have completely different syntax and often different semantics as well. Yet another feature that is used in one piece of code is the "match" that is used for pattern matching -- there is one popular package that Racket had used for ages -- some implementations adopted it, but Racket has long ago switched to a different syntax for patterns that AFAIK no other implementation uses. Then there are a whole bunch of features that are even more Racket-specific: keyword arguments for functions like "sort", relying on unlimited number of arguments passed via "apply", libraries like net/url that fetch HTTP content, using any unicode identifier, the contract system, relying on "char->integer" and "integer->char" that use ASCII values (not in the standard), using the GUI libraries (which are very different from the very few implementations that have them, and most other implementations don't come with any built-in gui) and libraries for generating PNG files, internal definitions in many places like result branches of "cond" (which is a relatively recent extension to the language), and string output ports. And these are only the things that I see in the current set of programs -- you can see that the usual racket toolset is huge, and therefore it is likely that more racket-specific features will be used in future submissions. So labeling all of these as "Scheme" is not going to be helpful for people who expect them to run in other implementations, and it will contribute to the common confusion where people expect Racket to be like other Schemes. This is actually part of the reason for changing the name from "PLT Scheme" to "Racket", a change that was desirable for people in the project as well as for people from other implementations (who would complain about PLT Scheme making its own standard). (See the detailed explanation here: .)
Oh, and BTW, all of this has lead to the usual stuff that follows from such a name change: for example, github and ohloh now consider Racket to be a separate language, and this is likely to be a trend that will continue.

Racket is not (in any meaningful sense) just a 'Scheme dialect'

Racket is a 'dialect of scheme' in the same sense that C++ is a 'dialect of C'.

C++ is indeed a C dialect in some pedagogic sense: they have broadly similar syntax and a matching universe of concepts, and if you know one, the other will seem broadly familiar, depending on which direction you're going in; also, C is clearly in C++'s lineage. However to insist that 'C++ is a C dialect' for this reason is clearly extremely unhelpful, and is wrong in the practical sense that if you tagged a StackOverflow C++ question as 'C', that tag would be rather testily changed for you.

Racket is a Scheme dialect in this same pedagogic sense, but only in that sense. It's clearly in the Scheme half of the Lisp world (and C++ is more like C than it is like Fortran), and important parts of its evaluation model and syntax come from RnRS. However its set of base types is significantly larger than any RnRS language, its macro system (and indeed its whole syntax-hacking layer) is massively extended from any RnRS, it's 'batteries included' in a way that no-one would expect a bare Scheme to be, and so on. If you tagged a StackOverflow Racket question just 'scheme', I suspect that 'racket' would be added for you, and contrariwise.

In any case the whole Lisp world, over the last 50 years, has been pretty free-and-easy with the question of what counts as a separate language and what doesn't, and in general hasn't obsessed about interoperable implementations: people expect different Scheme implementations to be more or less incompatible with each other, and that doesn't bother anyone in the way it would if a C implementation (say) added implementation-specific extensions. Also, the RnRS languages aren't really languages in the sense that you'd be expected to do real work in them: instead they're part-theoretical descriptions of an absolute bare minimum of functionality which an implementation must provide for it to be a scheme (think of C without the redundant 'for'). What that means is that this question cannot be answered definitively, but only in the practical sense of StackOverflow tags, above, and in the sense that a Rosetta example tagged 'racket' could plausibly look very different from an RnRS example, enough that a Chicken user (say) might not want to bother looking at it other than out of idle curiosity. Norman Gray 00:09, 21 February 2013 (UTC)