Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!ML.AI.MIT.EDU!ALAN
From: ALAN@ML.AI.MIT.EDU (Alan Bawden)
Newsgroups: comp.lang.scheme
Subject: "unspecified" and SET!
Message-ID: <10160.890620.ALAN@ML.AI.MIT.EDU>
Date: 20 Jun 89 22:15:21 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 60


    Date: 19 Jun 89 23:24:37 GMT
    From: Dorai Sitaram <titan!dorai@rice.edu>
      How do you deal with the other "commands" of Scheme? (E.g., READ,
      SET-CAR!, PRINTF.) Easier than SET!. SIGMA-like counterparts need
      _not_ be made for these, as that would lead to a plethora of special
      forms (as opposed to 'procedures'). All of these "command"
      procedures now take an additional argument for "the body" (thunk
      actually) whose value is returned. 

So we would write

  (NEWLINE (CURRENT-OUTPUT-PORT)
    (LAMBDA ()
      (WRITE X (CURRENT-OUTPUT-PORT)
	(LAMBDA () X))))

to newline, and then output and return the current value of X.  (Or perhaps
the continuations are passed as the first argument -- it doesn't matter in
the current discussion.)

Now it would seem to me that the most uniform way to include assignment in
this scheme, is to have SET! take a continuation as well.  So

  (SET! X (+ X 1)
    (LAMBDA () X))

would increment the value of X and return the new value.

SET! is still a keyword, so this isn't -exactly- parallel with the
side-effecting procedures.  But I'll bet that once people start writing
programs using this scheme, the thing that will impress them the most is
that whenever they perform a side-effect they have to create an explicit
continuation to wait for the side-effect to happen.  And I'll bet they will
be most comfortable if they have to make exactly the same kind of
continuation for SET!.

I'm currently working on a language where users really -must- control
sequencing by explicitly using thunks, so I'm very interested in linguistic
constructs that support this style.  Actually, in my case its worse than in
plain Scheme, because users must also exert control over when variables are
-read- as well as written.  Thus users have to write something like

  (LOOK! X
    (LAMBDA (VALUE)
      (SET! X (+ 1 VALUE)
	(LAMBDA ()
	  <whatever>
	  ))))

to increment the value of X, because if they wrote

    (SET! X (+ 1 X)
      (LAMBDA ()
	<whatever>
	))

the occurrence of X in (+ 1 X) might be taken to refer to the value of X
-after- the SET! happens (so that the value of X would become the fixed
point of (lambda (n) (+ 1 n))!).