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

[Ian Price]

Mark H Weaver <address@hidden> writes:

> Hello all,
>
> 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.
For many of these forms it isn't as obvious what the value should
be. For +,*,and,or you can use the identity element for these relations
and that is perfectly nice and obvious, (let () ...), you can figure out
by imagining ((lambda () ...)) which also seems obvious to me. begin,
cond, and case-lambda are less obvious. I guess (unspecified,
unspecified, a function that always produces a "wrong number of
arguments" error).

Also, if you're doing it for begin, do you think this should apply to
all implicit begins? If I saw, for example, a lambda with definitions,
but no expressions, I'd think the writer had made an error, rather than
this being intentional.

> Imagine if we didn't support (*) and (+).  Then you couldn't simply
> write (apply + xs) to add a list of numbers; instead you'd have to write
> (if (null? xs) 0 (apply + xs)).  In other words, they simplify
> higher-order programming by freeing the user from handling degenerate
> cases specially.
In general, I agree, but it is important IMO to consider it on a
case-by-case basis, and not just provide an arbitrary semantics for
no-argument version.  If you do that, then you aren't simplifying at
all, but merely trading one set of complications for another.

-- 
Ian Price

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"