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

[Peter Bex]

On Mon, Aug 25, 2014 at 10:31:44AM +0400, Oleg Kolosov wrote:
> I have a few questions:
> 
> 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 think if we finally split up core into multiple modules (and make them
into "proper" modules, using the module form), this may be less of a
problem.  However, we must take care that the modules loaded by default
at toplevel do not expose any non-R5RS names.  Otherwise, we're back at
square one.  (toplevel scripts that USE or IMPORT some CHICKEN names
are expected to know what they're importing, so if they override one of
the builtin names, we may assume that's probably intentional)

So, I'm in favor of this idea, but we have to be *very* careful to not
break existing and future R5RS/non-modular applications.

> Regarding continuations I think that call/cc is an advanced feature
> people brag about when advocating Scheme but not so useful in practise.

Heresy! :)

> 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 (the CPS
internal representation probably needs to be changed), which I think is
unnecessary, and whether it gives any benefits seems to be questionable
at best.  Besides, today's consensus seems that call/cc is too
general/problematic and delimited continuations are the way to go.  I
really dislike going with whatever idea is fashionable at the moment,
that would keep us busy forever.  Any changes we do in this should
provide real, tangible, immediate benefits.

In short, it's too much work for no benefit, and we already have enough
on our plate for CHICKEN 5 and perhaps even CHICKEN 6.

> 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).

> And looking at newer proposals I find it
> disappointing that Scheme community, given it's rich computer science
> heritage, haven't produced anything better than condition properties.

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

> I still want to research the topic a bit more, and studying other
> implementations, maybe someone could help me with some links or examples
> of interesting solutions of the problem?

I don't know of any.

> Regarding egg versioning, let's make CHICKEN itself a dependency too,
> with the default (if not declared) to <= 4. This way the egg authors can
> clearly declare which releases they support.

I'd have to think about that.  Perhaps this could be another way to
simplify fetching of eggs: henrietta-cache chould just fetch all the eggs
that have ever existed.  Then only henrietta itself would need to be
changed.  However, the disadvantage is that this makes it harder to
easily list which eggs are available for any given (major) CHICKEN
version.  By simply separating the master egg list by version it is
trivial to check this.

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