[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why not support (begin), (cond), (case-lambda), etc?
From: |
Mark H Weaver |
Subject: |
Re: Why not support (begin), (cond), (case-lambda), etc? |
Date: |
Fri, 06 Jan 2012 00:03:17 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
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.
> 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?
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?
On the other hand, it's not hard to think of realistic examples of
macros that could benefit by not having to specifically avoid these
degenerate forms in their expansions.
Furthermore, it seems to me quite contrary to the philosophy of Scheme
to make unusual cases into errors in order to facilitate debugging.
That's what Racket's beginner languages are for.
> Note the "definition context" begin in R7RS does allow zero
> arguments because expanding into zero definitions is a
> common case.
I'm very pleased to learn this. (begin) in definition context is the
case that I felt most strongly about.
Thanks,
Mark
- Why not support (begin), (cond), (case-lambda), etc?, Mark H Weaver, 2012/01/05
- Re: Why not support (begin), (cond), (case-lambda), etc?, Alex Shinn, 2012/01/05
- Re: Why not support (begin), (cond), (case-lambda), etc?,
Mark H Weaver <=
- Re: Why not support (begin), (cond), (case-lambda), etc?, Alex Shinn, 2012/01/06
- Re: Why not support (begin), (cond), (case-lambda), etc?, Mark H Weaver, 2012/01/06
- Re: Why not support (begin), (cond), (case-lambda), etc?, Alex Shinn, 2012/01/06
- Re: Why not support (begin), (cond), (case-lambda), etc?, David Kastrup, 2012/01/06
- Re: Why not support (begin), (cond), (case-lambda), etc?, Alex Shinn, 2012/01/06
- Re: Why not support (begin), (cond), (case-lambda), etc?, David Kastrup, 2012/01/06
- Re: Why not support (begin), (cond), (case-lambda), etc?, Alex Shinn, 2012/01/06
- Re: Why not support (begin), (cond), (case-lambda), etc?, David Kastrup, 2012/01/06
- Re: Why not support (begin), (cond), (case-lambda), etc?, Andy Wingo, 2012/01/06
- Re: Why not support (begin), (cond), (case-lambda), etc?, David Kastrup, 2012/01/06
- Prev by Date:
Re: Why not support (begin), (cond), (case-lambda), etc?
- Next by Date:
Re: Why not support (begin), (cond), (case-lambda), etc?
- Previous by thread:
Re: Why not support (begin), (cond), (case-lambda), etc?
- Next by thread:
Re: Why not support (begin), (cond), (case-lambda), etc?
- Index(es):