Questions from:
Barnes,
Edwards,
Fletcher,
Guha,
Kuo,
Nyombayire,
Schmitz,
Shireman,
Smith
Contents:
On page 32 of the article, the procedures force and delay are shown. Could you
explain how these procedures operate?
I am unclear as to what the force and delay functions do and when you would use them.
Why did the designers of Scheme decide to include three different equivalence predicates?
On page 18 the eqv? operation would return #t for (eqv? 'a 'a) but the value
for (eqv? "a" "a") is unspecified. What are the considerations that would
cause the Scheme developers to make this distinction?
Why would they choose to have the most discriminating equality function be called eq? and the least discriminating be called equal? That seems like a great way to confuse a lot of people early on.
This may have been explained at some point without me catching it, but why make the numerical equality predicate `=', instead of `=?'? This is inconsistent with the rest of the predicates in the language, and confuses C programmers.
If a programmer who hasn't read the specs uses `eqv?' on two identical constant expressions in his code and his compiler returns true, when he switches to a different compiler (that returns false on the `eqv?' of two constants), he's going to have a devil of a time finding the bug. Notice that the same would hold true for a female programmer.
Wait a minute, who's going to use `eqv?' on two constants, anyway? There's no reason for it! I have a hunch that the answer to my question is that the Scheme spec only leaves the behavior of functions unspecified in situations that should never come up in good code, anyway. That way, they help the language designers out by giving them some latitude, and only hurt the people who deserve it.
What benefit is there to not specifying a function given a certain input? (such as on p18 for (eqv? ...)) I know it allows the implementor some room to do what he or she wants, but if you are defining a language, why not make the extra step to fully specifying?
It seems to me that the R5SR gives compiler designers a whole lot of latitude in how they implement various procedures. Wouldn't this significantly reduce the portability of scheme code?
"These procedures implement number-theoretic (integer) division. n2 should be non-zero." What does this mean, from a technical standpoint? Does this sentence force the compiler maker to do anything?
I'd like to point out that PLT Scheme v208 differs from R5RS in that:
(define (g) '(constant-list))
(set-car! (g) 3) ==> error
on page 26 of R5RS. However, it is not an error in PLT Scheme and after executing the above code:
This seems really wierd as does the preceding example in R5RS (define (f) ...). It seems to violate modularity of programs. For example (valid in R5RS and PLT Scheme):
(define (make-box v)
(lambda ()
(let ((v v))
v)))
(define x (make-box 45))
(define y (make-box (list 1 2 3 4 5))
(set! (x) 'modified) ==> error
(set-car! (y) 'modified) ==> unspecified
(y) ==> (modified 2 3 4 5)
This strikes me as an implementation-related design decision. However, I don't see what the issue is. Could you clarify?
In the scheme report (page 25), I was confused about the boolean data type where
(boolean? #f) ==> #t
(boolean? 0) ==> #f
(boolean? '()) ==> #f
Is this arbitrary? or there is an advantage of having '() and 0 define as false.
Remember that the report requires each thing to have exactly one type. The only Boolean's are #f and #t. The type of 0 is number and the type of null is, well, null.
"If an inexact argument has no reasonably close exact equivalent ..." (page
24). What would prevent an inexact number from having an exact equivalent?
Couldn't one simply assume that the argument itself is exact?
I need a better definition of the difference between remainder and modulo.
I'm still having problems with continuations.
Yeah, we'll deal with it.
I don't understand call-with-values and values.
Hmmm ... those we teach in 151. Essentially, they're syntactic
sugar to permit a procedure to return more than one value.
;
Check with Bobby