Path: utzoo!attcan!uunet!cs.utexas.edu!usc!apple!snorkelwacker!bloom-beacon!ZURICH.AI.MIT.EDU!markf
From: markf@ZURICH.AI.MIT.EDU
Newsgroups: comp.lang.scheme
Subject: Re: Internal Definitions
Message-ID: <9006291433.AA10350@zurich.ai.mit.edu>
Date: 29 Jun 90 14:33:12 GMT
References: <904.268b61d9@waikato.ac.nz>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: markf@zurich.ai.mit.edu
Organization: The Internet
Lines: 56

>> (let ((a 1))
>>   (define (f x)
>>     (define b (+ a x))
>>     (define a 5)
>>     (+ a b))
>>   (f 10))

>> As I see the Scheme description given in R^nRS, expressions in the body of f
>> should be evaluated in sequence and therefore the above should return 16.
>> 
>> Who agrees/disagrees?

I disagree. Internal definitions are not like other expressions in the
body of let expressions (or procedures, or begin blocks, etc.). The
section in the reports on internal defines explains that the above
expression is equivalent to the following letrec:

(let ((a 1))
  (define (f x)
    (letrec ((b (+ a x))
	     (a 5))
      (+ a b)))
  (f 10))

The section on letrec says that it must be possible to evaluate each
initialization expression (e.g. "(+ a x)" and "5" in the above)
without referring to the value of any of the variables bound by the
letrec. 

The above expression is in error since there is a reference to the
variable "a" in the initialization expression for the variable "b".

Note that the r3.99 (and the r4rs to come) explicitly mentions the
restriction with respect to internal defines. In r3rs the restriction
is implicit.

>> Also in the DEC Scheme->C implementation the above expression returns
>> the rather confusing value of 15. I assume this is caused by a having
>> the value of 0 when the definition of b is evaluated. I think this is
>> a bug!
>> 
>> Who agrees/disagrees?

Naturally, I disagree again. Since the expression is in error, and the
report does not say that this error must be signalled, Scheme->C is
free to do anything it wants with the expression.

-Mark


Mark Friedman
MIT Artificial Intelligence Lab
545 Technology Sq.
Cambridge, Ma. 02139

markf@zurich.ai.mit.edu