felix wrote:
>>> Yet, I find SRFI-7 suboptimal, for various reasons I have already
>>> given (less typing (yes!), more natural, more straightforward, more
>>> portable - across existing implementations).

Bradd wrote:
>> I refrained the first time around, but I really must object to this
>> "less typing" advantage. It's an extremely short-sighted reason to
>> support a proposal. If you want less typing, use macros or scripts to
>> do the typing for you. It's an extremely trivial advantage, and all
>> too often it turns into a net disadvantage in the long run.

> "less typing" is not the main reason ....

It was important enough for you to mention twice, and it's one of the
only things your proposal seems to offer over SRFI-7, so it looks like a
key point to me.

> what also applies is that it doesn't require another pair of parens
> (i.e. toplevel forms aren't toplevel anymore).

What? SRFI-7's PROGRAM form does not change top-level forms any more
than a top-level BEGIN does. You're blatantly misrepresenting SRFI-7
here.

> A very basic little issue, agreed, but why not make things easy?

Why not spell "create" as "creat"?

It looks to me like there's an even more basic issue: You don't
understand SRFI-7.

>> As for more natural, more straightforward, more portable: The first
>> two are aesthetic judgments, and obviously several people disagree
>> with your subjective opinion.

> How many syntactic issues are not aesthetic? SRFI-55 is a
> *user-interface*, of course it's intended to be more aestethically
> pleasing.
>
> Moreover, I'm absolutely convinced that several, if not the majority
> of Scheme users (yes, even newbies count), will find it more natural
> and convenient.

Produce them, then. What you believe is irrelevant.

>> The last makes no sense whatsoever; how is your proposal any more
>> portable than SRFI-7?

> Because most implementations already provide it (albeit under
> different names).

You're using a strange definition of "already provide it" there.

> SRFI-7 appears to be unpopular among Scheme implementations, so I
> consider it a failure.

And your solution is to provide a technically inferior version of the
same facility?
--
Bradd W. Szonye
http://www.szonye.com/bradd