🚀 go-pugleaf

In article <5400@balrog.ctron.com> smith@ctron.com (Larry Smith) writes:
   In article <BEVAN.92Sep29181450@tiger.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephen J Bevan) writes:

   [ reaching EOF in a file _is_ an exception ]

Not necessarily.  It depends on what your view of the file is.  If the
file is being viewed as a sequence of bytes with a terminator, then I
see nothing exceptional about reaching the end, certainly no more
exceptional than I would if I were traversing a linked list and
finally reached the NIL pointer.  Do you consider reaching the NIL
pointer as an exception?  If you don't want to deal with the end of
the file, then abstract it away and provide the required interface.
Of course you'll have to deal with the EOF in the implementation of
the interface, but then you only have to do it once :-)


   But the _extent_ of a loop is really just minutia, and in order to
   code it you need to know the size of the array.  With exceptions,
   you just start looping and trust the runtime system to kick you out
   when you are done. ... But it still looks like a win to me.

I'd prefer language support for iteration over an array/collection.
If done correctly this would allow the writer to define whether the
order of iteration was important or not e.g. "for index in array"
would be unordered (making naive parallelism/vectorisation simple)
whereas "for index in ordered array" would force lower-bound ->
upper-bound ordering.  The syntax is not important here, you can chose
whatever suits and also expand it to be more flexible.  Alternately
you can look at the Alphard papers (20 years old) in which all this
stuff was first covered and which still looks more modern that most of
today's languages.  As to exceptions being a win in this case, I would
think that better iteration control is a bigger win as it includes all
the benefits of exceptions in this case and also has the possibility
of others if done correctly.


   >       IMHO exceptions can be replaced by either making a function
   >take/return additional arguments or by dynamically binding a function
   >to be called in the event of an "exception".

   That requires additional code.

Only marginally more code than having the exception code in the same
routine and when you include whatever syntax is used for wrapping up
the TRY/CATCH call there is probably no difference.


   Yes, it can work (and I've used it
   many times in C++ and other languages - especially Modula2), but
   you must still define your exception handler as another routine,
   which requires that it have a new name (namespace pollution is
   becoming more of a concern every year).

If the "exception" is visible outside the package/module exactly the
same namespace problems occur (unless of course you put exceptions in
a different name space, do you advocate that?).  If the exceptions are
local to the package/module there is no problem as the namespace
polution is marginal.


   Further-more, you can't nest environments without explicitly coding
   some sort of handler stack.

Ok, here's one of my not so mainstream ideas on exceptions: if you
code is punting the _same_ exception up through multiple levels your
code sucks.  If you trap an error you should deal with it or pass it
it on as another exception (the latter being done when abstraction
boundaries are being crossed).  If you really want nested environments
in the sense you mean above I'd rather have them as a general feature
in the language than as a little hack only available to "exceptions".
That is, add the capability to do "fluid-let" that is available in a
number of Scheme systems.


   [ calling a separate function means you _must_ return to the call
     site and therefore return an out of bound value from the routine
     that generated the exception ]

Well a more elegant solution to me is to add continuations to the
language as they trivially solve the above problem and also have many
more uses besides (they supersede coroutines for a start).

The reason I don't like exceptions as they have been presented in the
above is that in each case I think the problem is better dealt with
another (more general) feature which has wider benefits and/or
provides the capability of exceptions.

In summary if you language has the ability to dynamically bind a
procedure and has continuations, "exceptions" are just another
procedure.

bevan