Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Peter Bex]

On Tue, Aug 26, 2014 at 10:29:23AM +0400, Oleg Kolosov wrote:
> On 08/25/14 15:30, Peter Bex wrote:
> > On Mon, Aug 25, 2014 at 10:31:44AM +0400, Oleg Kolosov wrote:

[explanation about ##sys# prefix]

> I suspected that it is related to name clashes, now I see how exactly,
> thanks for the detailed explanation!

You're welcome.  We agree that removing the prefix is a good goal, but
it might not be 100% achievable.

> >> So a "better API" is just TL;DR for most. Isn't the new API makes life
> >> easier for implementors too? And benefit greatly from direct support
> >> from performance standpoint.
> > 
> > I think this would require a complete overhaul of the compiler ...
> 
> No-no. No need to change anything internally. I was thinking about the
> documentation issue.

Ah, I didn't understand that.  If we make it part of an egg it gets its
own dedicated wiki page.  That could have as long an explanation as you
want.

> Sorry my lame use of match, there should be a better way, but it gives
> the idea: if user already can throw whatever he pleases, why bother with
> conditions at all? For interoperability the standard could provide a
> list of recommended symbols (the things to match) and the intended usage
> patterns, like CHICKEN do: (exn arity), (exn type), (exn syntax) etc.
> Better yet - provide specialized match operator for decomposing
> implementation specific error type and let the user spell out only
> symbols, like:
> 
> (match '(exn i/o net)
>   ((or (! file) (! net)) (print "open error"))
> 
> No need for predicates, accessors, composite constructors, etc. and
> condition-case (guard) starting to look redundant.

Your matchable example assumes the code raising the condition is written
by the same people who wrote the code which is handling it (or at least
they read the docs).  If conditions belong to a particular type, generic
code can catch them and at least inspect the components it knows about.
You're right that the ability to raise arbitrary objects might cause
trouble for code dealing with conditions, and that's a bit of a mistake.

> Condition properties (like location, arguments, etc.) look useful at
> first sight, but I could not think of any use for them besides printing.

They're extremely useful when you go beyond the usual simple errors.
For example, the http-client egg provides the HTTP status code in a
condition property.  The postgresql egg provides the entire information
you can obtain from the server in condition properties, like error class,
error status, primary and detail message, "hint" for the user, position
of the cursor where the error was triggered, source file and line where
the error was reported, table and column name etc.

Most of the stuff you'll find in a condition object is information for
the user, to aid debugging, so of course it's mostly useful for printing!
However, there are situations where you'd like to log more information
or statistics about errors, and then it's useful to have machine-readable
properties.  If CHICKEN ever gets a debugger, it would be able to do
more with the conditions, like jumping to the source location stored in
the exn component.

I really like the fact that the Scheme tradition is about arbitrarily
composable conditions: you can combine an i/o error with a file error,
giving (exn i/o file), but you can do the same if there's for example
a hardware error with an attached printer, giving (exn i/o printer).
If the i/o type contained specific details (which it currently doesn't),
both types would carry the same properties, so a condition-case of
(exn i/o) would be able to catch both exceptions and display the common
properties, regardless of the other types it has.

This is strictly more powerful than a typical one-dimensional class
hierarchy you'll find in most OO languages, where an exception class
must inherit from one (and only one) other exception.  The example I gave
would be possible if you have (exn) -> (exn i/o) -> (exn i/o print),
however, this precludes non-i/o type of print errors like
(exn queue print) or (exn permission print), where the "print" component
carries the same properties as the print component from (exn i/o print).
R6RS, in typical feature-piling fashion, allows both a composite list of
conditions, which also belong to a hierarchy, because why not?

The biggest problem with the SRFI-12 conditions is that the properties
are a matter of convention: there is no guarantee that the "exn"
condition really contains any of the usual properties (and in fact, most
or all of them are optional). 

> I think the implementation could find a way to provide this information
> without burdening the user.

Don't hand-wave this away.  A replacement API should be well thought-out,
and deal with all the use cases of the current system.

Cheers,
Peter
-- 
http://www.more-magic.net