Programming Languages (CS302 2005S)

Questions on R5RS, Sections 1-5

Questions from: Barnes, Edwards, Fletcher, Guha, Kuo, Nyombayire, Schmitz, Shireman, Smith


Force and Delay

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.

Equality Testing

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:

(g) ==> (3)

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))

(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?

Short Answers

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.

Disclaimer: I usually create these pages on the fly, which means that I rarely proofread them and they may contain bad grammar and incorrect details. It also means that I tend to update them regularly (see the history for more details). Feel free to contact me with any suggestions for changes.

This document was generated by Siteweaver on Wed Mar 2 11:39:34 2005.
The source to the document was last modified on Thu Feb 10 20:50:47 2005.
This document may be found at

You may wish to validate this document's HTML ; Valid CSS! ; Check with Bobby

Samuel A. Rebelsky,