Email list hosting service & mailing list manager

A liitle note on the side felix (23 Jun 2004 23:44 UTC)
Re: A liitle note on the side Bradd W. Szonye (24 Jun 2004 00:14 UTC)
Re: A liitle note on the side Alex Shinn (24 Jun 2004 03:10 UTC)
Re: A liitle note on the side Bradd W. Szonye (24 Jun 2004 03:55 UTC)
Re: A liitle note on the side Jens Axel Søgaard (24 Jun 2004 05:04 UTC)
Re: A liitle note on the side Bradd W. Szonye (24 Jun 2004 05:07 UTC)
Re: A liitle note on the side Felix Winkelmann (24 Jun 2004 05:19 UTC)
Re: A liitle note on the side campbell@xxxxxx (24 Jun 2004 16:56 UTC)
Re: A liitle note on the side Bradd W. Szonye (24 Jun 2004 18:47 UTC)
Re: A liitle note on the side campbell@xxxxxx (24 Jun 2004 04:19 UTC)
Re: A liitle note on the side Alex Shinn (24 Jun 2004 05:07 UTC)
Re: A liitle note on the side campbell@xxxxxx (24 Jun 2004 01:40 UTC)

Re: A liitle note on the side Bradd W. Szonye 24 Jun 2004 18:47 UTC

xxxxxx@autodrip.bloodandcoffee.net wrote:
> If 'the typing argument' isn't the main issue, _what_is_?

That's my question too.

It doesn't standardize existing practice; the name, syntax, and
semantics are different from similar features in existing Schemes. It
ignores the standard feature identifiers introduced by SRFI-0 and
SRFI-7, so it isn't even compatible systems that provide those.

Furthermore, I think it's unlikely that Scheme vendors will support
SRFI-55 well enough to make it common practice in the future. Contrary
to Felix's claims, it takes more than a simple macro to implement this
even in Schemes that could support it. For example, there is no simple
way to load SRFI-1 in PLT Scheme; the language imposes special
requirements because SRFI-1 overrides standard Scheme procedures. They
differ depending on whether you want to load SRFI-1 at top-level or in
module scope.

This SRFI is gratuitously incompatible with previous specifications, and
it's much harder to implement than the author has claimed. It duplicates
features that Scheme implementations already provides, but with an
incompatible syntax and, in some cases, very difficult semantics. I see
it as no improvement over existing practice, and in some cases a
significant step backwards.
--
Bradd W. Szonye
http://www.szonye.com/bradd