Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!titan!dorai
From: dorai@titan.rice.edu (Dorai Sitaram)
Newsgroups: comp.lang.scheme
Subject: Re: "unspecified" and SET!
Message-ID: <3904@kalliope.rice.edu>
Date: 19 Jun 89 23:24:37 GMT
References: <3902@kalliope.rice.edu> <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU>
Sender: usenet@rice.edu
Reply-To: dorai@titan.rice.edu (Dorai Sitaram)
Organization: Rice University, Houston
Lines: 74

In response to my posting suggesting SIGMA and SIGMA-based SET! (a la
LAMBDA and LET) instead of traditional SET!, I received email which
basically states that SIGMA violates the orthogonality of Scheme
constructs, viz., SIGMA does "two" things: it "side-effects the
environment" _and_ "returns a value".

In other words, it is felt that any side-effecting construct should
just perform the job it was made for, viz., side-effecting, and not do
something else too, like returning values. SIGMA allegedly "fails" in
the latter detail.

But then, we should remember that our goal was to preserve the
syntactic uniformity of Scheme. Scheme is (and very deliberately too)
an expression-oriented language. In spite of our best efforts,
traditional SET! does return a value. Given that whichever primitive
side-effecting construct we pick will inevitably return a value, which
construct should we choose? I would prefer one where the returned
value is not only meaningful but _necessary_.

The value that SET! returns is totally arbitrary. What SIGMA returns
is crucial to its correctness. Recall that SIGMA does not perform a
side-effect immediately; it returns a closure, which needs to be
applied to value(s) before any side-effecting can take place.

(Incidentally, LAMBDA, the cornerstone of Scheme, also has "two"
purposes _if_ we take "returning a value" as a distinguishing property
in assessing the orthogonality of Scheme. LAMBDA introduces fresh
lexical variables _and_ returns a closure. I don't think anyone
seriously wants to reject LAMBDA for lack of orthogonality!)

--dorai

ps: Other questions:

* Why was SIGMA created? Felleisen & Friedman (POPL 1987) devised a
  calculus for a lambda-calculus-like language with assignments. SIGMA
  kind of falls out naturally. 

* Why is it "superior" to SET!? "Superior" is a tough word. However, I
  did mention the naturalness of parallel assignment in my orig.
  posting. Using SIGMA-capabilities as arguments to control-reifiers
  like call/cc is also delicious.

* There is also another reason why the SIGMA-model of assignment, viz.,
  (sigma (x ...) e ...) or (set! ([x a] ...) e ...), makes sense. In any
  program, one always performs some operation _after_ the
  side-effecting (of variable-bindings(see + below)) has been done. If
  the side-effecting were the last thing done in the program, there is
  no way it could be detected, hence no way it could be meaningful.
  Thus the application of a SIGMA-capability returns the value of the
  body of the SIGMA-expression, something (and such a something
  invariably exists) that is evaluated _after_ the side-effecting has
  taken place.

+{PRINTF is the only side-effect which can meaningfully be the last
  thing in a program.}

* [Alan Bawden's question about NEWLINE...]
  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. 

{* SIGMA of course is necessarily a special form (i.e., it cannot be
   substituted by a procedure as for READ, SET-CAR!, PRINTF above).
   The reason is variable names can't be passed as procedure arguments.}

--dorai
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------