Re: Why not support (begin), (cond), (case-lambda), etc?

[Alex Shinn]

On Fri, Jan 6, 2012 at 2:03 PM, Mark H Weaver <address@hidden> wrote:
> Alex Shinn <address@hidden> writes:
>
>> On Fri, Jan 6, 2012 at 9:49 AM, Mark H Weaver <address@hidden> wrote:
>>>
>>> I'd like to argue in favor of supporting (begin), (cond), (case-lambda)
>>> and other such degenerate forms, for the same reason that we support
>>> (*), (+), and (let () ...).
>>>
>>> First of all: Is there any compelling reason not to support them?
>>> I can't think of one.  Can you?  If so, please do tell.
>>
>> 1. portability - these extensions may not work on other
>> implementations.
>
> Well, how about mandating support for these degenerate forms in R7RS? :)
> I'm quite serious.  I would argue the point on WG1 if I was allowed to
> post there.

You're allowed and encouraged to post to
address@hidden  We take all
comments seriously.

>> 2. the fact that these may be indicators
>> or broken macros.  Suppose in general p% of macro
>> expansions into cond are bugs.  Since (cond) is a degenerate
>> form, it's reasonable to suppose that q > p% of expansions
>> into (cond) are bugs.  If q is larger enough than p, then it's
>> not worth the convenience it saves in some cases.  Not
>> that I have any idea what p and q are for these forms.
>
> You could make the same argument against (and), (or), (+), (*), and
> perhaps others.  If you were designing Scheme from scratch, would you
> prohibit these forms?

Whether I were designing from scratch or updating an
existing standard, I would avoid sweeping generalizations
and consider each form or procedure on a case-by-case basis.
A foolish consistency is the hobgoblin of little minds :P

> It seems highly unlikely to me that flagging errors on (cond) will
> significantly reduce the amount of effort needed to debug macros.  I've
> debugged many macros, and I can't remember a single time when flagging
> (cond) as an error would have saved me any effort.  Can you?

Seeing as how (cond) is currently non-standard, it's the
other way around - you have to provide evidence that it's
useful in macros.  Since by definition you're expanding
a macro whose return value is undefined, I think this is
likely a corner case (and possible evidence that the macro
was poorly thought out to begin with if it may sometimes
be defined and sometimes undefined).

Again, I haven't really thought about these cases, and they
weren't brought up for discussion.  Post your argument to
the public list and we can consider it for the next draft.

-- 
Alex