Am 06.01.2017 um 20:49 schrieb John Cowan:

In hindsight, I wish we had standardized on case-define instead.
The trouble with

(define foo

(case-lambda

((x) <some-complex-computation>)

((x y) (do-something! y) (foo x))))

is that do-something! might reassign foo, and consequently you can't

optimize by jumping straight into the single-argument case. (Or can you?)

As long as we disallow call/cc on the top-level or if this definition is a local one, the Scheme implementation can track whether foo is ever set!-ed. So in most reasonable cases, foo will be well-known at the call site.

I agree that non-top-level cond-expand is a wart, and I think that

non-top-level include is potentially a wart too, except that I hope

nobody thinks include is processed hygienically. These things

Does it make any sense to ask whether "include" is hygienic or not? "Include" takes strings as arguments, and strings are never renamed due to macro expansion. Or are there unorthodox interpretations of "include" I am not aware of.

Contrary to others, I actually see some value in using "include" not at the top-level. Take a parser, for example:

(define (parse ...)
(define state ...)
(define (parse-number ...))
(define (parse-int ...)
(define (parse-stmt ...))
...
...
...
(parse-program ...))

If the parse-procedure has many internal defines, this suffers from the body of the parse-procedure being easily overlooked and having a long part of the code indented. There are several cures:

1) Move each internal procedure to the top-level and give each as much extra parameters (e.g. state) as there was shared state amongst the internal procedures. Disadvantage: This means that the state (and other parameters) have to be explicitly passed around.

2) Move each internal procedure to the top-level and use parameterize and parameters do hold the common state. Disadvantage: Parameters may be less performant than procedure arguments passed around.

3) Use "include":

(define (parse ...)
(include "parsers.scm")
(parse-program ...))

--

Marc