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

[Oleg Kolosov]

On 08/25/14 15:30, Peter Bex wrote:
> On Mon, Aug 25, 2014 at 10:31:44AM +0400, Oleg Kolosov wrote:
>> Is there a way to get rid of ##sys# prefix everywhere? It might be
>> matter of preference, but it makes the sources harder to read.
> 
> It was originally used as a "guaranteed" separate namespace.  R5RS
> doesn't allow # to appear in an identifier and has no way of "escaping"
> them, so portable programs cannot ever clash with the core names.
> When CHICKEN grew a module system, this was kept around for backwards
> compatibility but also because "library" is by default loaded at
> toplevel.  This means that a set!  or define on any name exported by
> library would override the given internal definition.
> 

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

>> 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. Sorry, I wasn't clear enough. Do not sweep those
under the rug too far, but expand the documentation and try to put the
API to good use (or let the users try). Considering how small the
CHICKEN implementation is. I'm fine with the eggification as long as
benefit of direct support by the core is not lost. For example how
exactly it interacts with the dynamic environment (winds), threads?
There a lot of material on the topic but it usually contains computer
science. After some fiddling with the primitives described in Feeley's
paper it looks like after some explanation it should be a lot easier to
understand for people coming from mainstream languages compared to the
single ultimate control flow operator - call/cc.

>> Mentioning exceptions, I find whole SRFI-12 quite useless - it's just
>> too clunky to use.
> 
> I really like the SRFI-12 system.  It's simple.  The API for constructing
> conditions is a little clunky, but I think that can be easily improved
> with a simpler way to construct them (I've been planning on doing this
> for over a year now, so I guess I should post a patch to do that soon).
> 
> What's wrong with condition properties?  One alternative to that is the
> R6RS exception system, which is overly complex and requires inheritance.
> It's like they had Java envy when writing it:
> http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-8.html#node_idx_382

Please consider something like:

(with-exception-handler
  (match-lambda
    ('some-error (print "error"))
    ((and (? (cut memq 'file <>)) err) (print "file " err))
    ((and ($ some-type) (= some-type-first err)) (print err)))
  (lambda ()
    (signal 'some-error) ; primitive error
    (signal '(exn file whatever)) ; "composite" error
    (signal (make-some-type '(exn net i/o whatever) more information))))

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.

Condition properties (like location, arguments, etc.) look useful at
first sight, but I could not think of any use for them besides printing.
I think the implementation could find a way to provide this information
without burdening the user.

-- 
Regards, Oleg