NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/scheme/2133

Internet Message Format | 1992-09-01 | 3.3 KB

Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!data.nas.nasa.gov!taligent!apple!voder!woodstock!news
From: [e-mail] (Scot Dyer)
Newsgroups: comp.lang.scheme
Subject: Re: wots going on here!?
Message-ID: <[e-mail]>
Date: 1 Sep 92 16:02:56 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Scot Dyer)
Organization: NCR/ShareBase Corporation
Lines: 66
Nntp-Posting-Host: eagle

[e-mail] (Brian Harvey) writes:
[e-mail] writes:
%%>There is a large tension in a system
%%>aimed both at experienced users and stark novices between being overly
%%>verbose and "nice" and being useful.
[...]

I have to agree here, but I think there's a larger underlying problem.

[e-mail] (Brian Harvey) writes:
%%The behavior I want would be *less* verbose:
%%        > (+ 2 a)
%%        Unbound variable: a
%%        >
%%Short and sweet.  It should be possible for an advanced user to ask
%%for pause-on-error behavior in which Scheme would attempt to preserve
%%the environment in which the error occurred, but you should have to
%%ask for it.

This can be a problem if the 'error' wasn't really an error, but should have
been a warning, because control is taken from the program.  One could
conceivably take this as far as CLOS restarts, and provide a complex procedure
for handling exceptions, involving lots of non-local control structures.

I happen to think there's a better way to do exception handling, which isn't
taken up by most languages*.  Imagine if an error were a value, a printable
value like everything else in Scheme [except environments, of course :-)], so
that you'd have something that'd work like:

    (define (car some-list)
           (if (null? some-list)
              (error "car of null")
          (lower-level-car some-list)))

Where (error "car of null") would produce an error vector, containing the
complaint.  Beyond this, correct behavior is simple.  Each error contains
_irritants_, like a string to explain the error, and it should be an error
say to try to add to an error value, ergo:

    #(error "+ on error value" #(error "car of null list"))
    ;;; other printing names may be more sensible...

So that a failing program then provides a detailed 'back-trace.'

THE BENEFIT:
    (if (error? (car l))
        ...
        ...)

[e-mail] (Brian Harvey) writes:
%%(This is how Logo does things.  Errors give a message
%%and return to toplevel, unless you have asked in advance for pause
%%on error.  In that case you get a special prompt and (because of good
%%old dynamic scope -- but that's another argument) *all* of the possibly
%%relevant variables are immediately accessible in the usual way without
%%you having to know anything about environments.)

This sounds like a nice environment to work in, but I think seeing the actual
_error_ might be more instructive, powerful, flexible, etc.  It also happens
to be more _functional_, but by that I mean no more than that it is extremely
clean.

    -- Scot
-------------------------------------------------------------------------------
* Error values are probably not much in use since a staticly typed language
  wouldn't be able to deal with them very well...