[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A better future

This page is part of the web mail archives of SRFI 17 from before July 7th, 2015. The new archives for SRFI 17 contain all messages, not just those from before July 7th, 2015.



David, 

  2 - After much grovelling over the formal semantics in R5RS, I can say
      that bindings are *not* mutated by anything in that denotational
      specification, locations are. However, denotational specifications
      have the disadvantage that they over-specify the semantics of the
      language in question and strongly suggest a particular
      implementation. Hence R5RS has second-class locations in it's
      formal spec, which I would like to see become first-class. A good
      first-class location SRFI could be a testbed for an RnRS with the
      feature.

There are several other things in a denotational semantics that are what
you would call "second class": environments, stores, etc. The Scheme syntax
has second-class citizens: parameter lists and let/rec/* definitions, which
cannot be the target of macro elaborations. I don't have time to explain
why this is the case and argue should stay so. Scheme is *not* about making
*everything* first-class. 

For my dissertation (mid 80s), I developed a semantics, extending the plain
old lambda(value) calculus, that models call/cc, set-struct-field!, etc. 
I teach it here, as early as in the freshman course. Here are the two
relevant samples: 

------------------------------------------------------------------------
1. Interpreting set! 

(define-struct sss (aaa bbb))               (define-struct sss (aaa bbb)) 
					                                            
(define some-sss (make-sss 5 'hello)) ==>   (define some-sss (make-sss 5 'hello))
					                                            
(define a-variable a-value)		    (define a-variable another-value) 
					                                            
... 					    ...                                     
					                                            
E[(set! a-variable another-value)]          E[(void)]

------------------------------------------------------------------------

2. Interpreting set-struct-field! 

(define-struct sss (aaa bbb))               (define-struct sss (aaa bbb)) 
					                                            
(define some-sss (make-sss 5 'hello)) ==>   (define some-sss (make-sss 5 'world))
					                                            
(define a-variable a-value)		    (define a-variable a-value) 
					                                            
... 					    ...                                     
					                                            
E[(set-sss-bbb! some-sss 'world)]           E[(void)]

------------------------------------------------------------------------

[DrScheme's stepper will explain the behavior of programs with such
transformation rules.]

The rules show what we mean when we say "set! modifies variable-value
bindings" and "set-struct-field! modifes the value but not the binding. 
The value before and after the set-struct-field! are eq? and we can even
write this eq? procedure: 

(define (eq-sss? a b)
  (let* ([a-aaa (sss-aaa a)]
	 [b-aaa (sss-aaa b)]
	 [_ (set-sss-aaa! a 0)]
	 [_ (set-sss-aaa! b 1)]
	 [result (= (sss-aaa a) (sss-aaa b))]
	 [_ (set-sss-aaa! a a-aaa)]
	 [_ (set-sss-aaa! b b-aaa)])
    result))

-- Matthias