Scheme vs Common Lisp(community.schemewiki.org)
community.schemewiki.org
Scheme vs Common Lisp
http://community.schemewiki.org/?scheme-vs-common-lisp
4 comments
>The section on numeric types is a long-winded and bizarrely negative-sounding way to say that Scheme wins. "In a good implementation, numerics (capabilities and correctness) are better than most CLs; on average, they are worse." Ok... why would you use a bad implementation?
Because no Scheme is great at everything. All of them are bad implementations in some sense, and all of them are good implementations in some sense (if you only count ones that have users other than their implementor, not somebody's practice project). If you could somehow take the union of great features in every Scheme, that would be nice, but that's not the case.
In the case of numerics, Gambit is said to be the best Scheme, but it has it's own disadvantages - there's virtually no third-party code available for it, for one thing. Alternatively, you could use Chicken or PLT, which have quite a bit of third-party code and helpful communities, but last time I checked (this may be out of date), numeric performance was not so great.
Because no Scheme is great at everything. All of them are bad implementations in some sense, and all of them are good implementations in some sense (if you only count ones that have users other than their implementor, not somebody's practice project). If you could somehow take the union of great features in every Scheme, that would be nice, but that's not the case.
In the case of numerics, Gambit is said to be the best Scheme, but it has it's own disadvantages - there's virtually no third-party code available for it, for one thing. Alternatively, you could use Chicken or PLT, which have quite a bit of third-party code and helpful communities, but last time I checked (this may be out of date), numeric performance was not so great.
On the whole macro debate, whatever one thinks the default behavior should be with respect to variable capture, the syntax-case macro system in scheme works on a representation of program code which is at a higher resolution than what lisp macros works on.
The macro can find out for instance, if an identifier used in its input is a free-variable, or if two identifiers share the same binding. Hence, it is possible to write a relatively short program to define defmacro in terms of define-syntax & syntax-case, but not the other way round. (a pretty short implementation & most of it is error checking - http://svn.plt-scheme.org/plt/trunk/collects/mzlib/defmacro....)
This also strikes me as a inconsistency in arc(albeit easily correctable), as it goes against the rule of not imposing restrictions on the user, by default. Even, if the default macro interface is something simple, the user should be able to write macros which work with syntax at a higher resolution if needed.
Also, if you use the most popular distribution, PLT scheme, you have all of reader macros, native hash tables, keyword arguments, a package repository. There is a really nice module system, along with other neat stuff like contracts, lazy modules, frp & of course the continuation based web-server. For OOP, there is Swindle, an analog of CLOS(not having used it, i don't know if it's just as good).
After R6Rs, there is a common module system and standard libraries for hash-tables even in the scheme spec.
The main flaw, it seems, is the relative lack of libraries as compared to other mainstream languages. In particular, what i miss is something like wxPython for scheme.
EDIT : turns out i spoke too soon, defmacro does have an environment object(http://www.lispworks.com/documentation/HyperSpec/Body/03_aad...) as a parameter, so it has some access to lexical info of its input form. To implement define-syntax, one would also need some way to output a syntax object and not just a s-expr. Couldn't find any defmacro implementation of define-syntax on the net.
The macro can find out for instance, if an identifier used in its input is a free-variable, or if two identifiers share the same binding. Hence, it is possible to write a relatively short program to define defmacro in terms of define-syntax & syntax-case, but not the other way round. (a pretty short implementation & most of it is error checking - http://svn.plt-scheme.org/plt/trunk/collects/mzlib/defmacro....)
This also strikes me as a inconsistency in arc(albeit easily correctable), as it goes against the rule of not imposing restrictions on the user, by default. Even, if the default macro interface is something simple, the user should be able to write macros which work with syntax at a higher resolution if needed.
Also, if you use the most popular distribution, PLT scheme, you have all of reader macros, native hash tables, keyword arguments, a package repository. There is a really nice module system, along with other neat stuff like contracts, lazy modules, frp & of course the continuation based web-server. For OOP, there is Swindle, an analog of CLOS(not having used it, i don't know if it's just as good).
After R6Rs, there is a common module system and standard libraries for hash-tables even in the scheme spec.
The main flaw, it seems, is the relative lack of libraries as compared to other mainstream languages. In particular, what i miss is something like wxPython for scheme.
EDIT : turns out i spoke too soon, defmacro does have an environment object(http://www.lispworks.com/documentation/HyperSpec/Body/03_aad...) as a parameter, so it has some access to lexical info of its input form. To implement define-syntax, one would also need some way to output a syntax object and not just a s-expr. Couldn't find any defmacro implementation of define-syntax on the net.
I'd like to see this updated for R6RS. There are several deficiencies of Scheme (like a module system) addressed in the new standard.
This gets posted here every few weeks...
Macros: All the main Scheme implementations offer Common Lisp style macros, so in Scheme you can use either style. (Good thing, because I like the Common Lisp style.)
The section on numeric types is a long-winded and bizarrely negative-sounding way to say that Scheme wins. "In a good implementation, numerics (capabilities and correctness) are better than most CLs; on average, they are worse." Ok... why would you use a bad implementation?
As for Common Lisp having a well-defined module system consistent across implementations... that was not my experience. I was very irritated by that stuff when going through Peter Seibel's "Practical Common Lisp" book, as the book used different terminology than the implementation of CL I had.
I guess it's still true that Common Lisp has better libraries, but Scheme has sure been doing well there lately.
This is not to say that I don't like Common Lisp. In fact there are a lot of things about it that I wish I had in Scheme.