What are the most common misconceptions about the Scheme programming language? What are some of the most enduring Scheme myths?
most enduring scheme myth
>>1-san is a 男の娘
>>2
Please explain your comment. Thank you.
>>3 >>1-san was formallyimperatively brought up as a male daughter in moner country if that makes sense without the formalimperative semantics
thats what the biped 7d snek scheme elder told me
One common misconception about Scheme is that it is a small and simple programming language. That is a myth. Schemers are somehow obsessed over the number of pages in their language standards. With R7RS-large in the pipeline, Scheme is on track to become one of the largest programming languages to have ever existed. Even R7RS-small is very large. The standard looks small only because Schemers like to specify their de-facto standard libraries outside the standard, thereby making the standard itself look deceptively small. For practical programming purposes, SRFIs and other implementation-specific extensions are essential. When all the language specifications, SRFIs, and implementation-specific extensions are combined, the result is a very large language.
Scheme is not small and simple. Most Schemers are not able to implement call/cc and the full macro system. At most, they will be able to implement a subset of Scheme. This explains why there are so many incomplete and non-standard-compliant Scheme implementations. It is easy to implement the first 80% of Scheme, but difficult to implement the other 20% (which consists of a 100% standards-compliant hygienic macro system).
One common misconception about Scheme is that it is a big and complex programming language. That is a myth.
Scheme is small and simple.
From all the "X an acceptable lisp" articles I've seen, plus all the enlightenment testimony, I do wonder if the biggest misconception is that it is that the Lisp family is uniquely positioned to open your third programmers eye (or whatever) compared to Forth/Factor, APL/J/K/Q, Smalltalk, etc.
>>5
Continuations should be delimited if not replaced with coroutines. Hygenic macros are insufficiently expressive, and are overly dependent on syntax, they should be replaced with partially evaluated fexprs. The latter suggestion might be more complex however, especially to implement efficiently, I haven't really looked into implementation.
>>8
Given Scheme's focus on simplicity and minimalism, I don't understand why Scheme has hygienic macros instead of Common-Lisp-style defmacro. defmacro is able to provide the foundation for building a hygienic macro system, should users prefer hygienic macros.
>>9
That sounds fine to me, in R4RS the macro systems is actually an optional language extension, and there is an optional low-level macro system specified as well. It still has undelimited continuations however, and portability issues. Minimalism isn't my only interest in a programming language, but I think it would be nice to have a hyper-Scheme of this sort in the toolbox.
>>10
Why was the low-level macro system removed in R5RS? Didn't the removal of low-level macros reduce the flexibility of Scheme?
>>11
I suspect they wanted to standardize the macro-system for portability. In general Scheme standardizers prefer to have one way to express any given idea. As for why hygene was selected, this is probably just because scope is considered very important by the standardizers, and unhygenic macros can violate this. R6RS's syntax-case is equivalent to low-level macros iirc, so flexibility was reduced in R5RS, and R7RS but not R6RS.
from reading some an old thread in comp.lang.scheme, it seems like after R4RS, there were a bunch of papers published on macros in scheme- it was a really active time for research in that topic. By the time of R5RS there was already, aside from the R4RS low-level system, syntactic closures, explicit renaming-so maybe it was just a matter of having several low-level systems developed and no consensus on which one to use.