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: <4011@kalliope.rice.edu>
Date: 25 Jun 89 22:17:45 GMT
References: <3902@kalliope.rice.edu> <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU> <2281@ubc-cs.UUCP>
Sender: usenet@rice.edu
Reply-To: dorai@titan.rice.edu (Dorai Sitaram)
Organization: Rice University, Houston
Lines: 28

In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
>Going to the trouble to develop a calculus of unspecified values
>strikes me as almost as silly as some of the things I did when I was
>involved in writing an Algol 68 compiler.

If this is in response to my posting(s) entitled "unspecified and
set!"  (and I'm not sure it is -- Vincent doesn't say), I request
permission to shriek, "No! This is not what I meant!" ;-)

I was drawing attention to side-effecting constructs in the literature
(that they appeared in a calculus-definition is of secondary
importance) that give all the "power" of current Schemes WITHOUT
having to mess with (returning) unspecified values at all. I do, of
course, concur with Vincent that having an unspecified object like
#!unspecified is close to being the all-time great oxymoron of our
troubled times (though he might not use the selfsame words ;-]).

Second, the comparison that Vincent draws between "(#!)unspecified"
and "bottom" is not correct. "Bottom" stands for divergence
(non-termination) and occasionally, errors; "(#!)unspecified" is a
stopgap value concocted to stand for a meaningless value returned in a
TERMINATING computation.

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