Category talk:Racket: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 21:
: 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? --[[User:EMBee|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: http://racket-lang.org/new-name.html .)
:: 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.
Anonymous user