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

[David Kastrup]

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 () ...).

Actually, I'd like to see (let ()) and (lambda ()) work too for similar
reasons (basically equivalent to (if #f #f)).

> 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.

Detecting errors when writing macros.  Not all that likely, but that's
the standard argument against supporting degenerates.  And since the
whole point is restricting the number of valid cases, it is the main
argument.  The other is that there may be cases where one has to bend
over backwards to support degenerates.

Note that in other situations, degenerate cases are supported
astonishingly well:

guile> '( . 4)
4

> 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)).

(apply + 0 xs) but it still is a distraction.

> In other words, they simplify higher-order programming by freeing the
> user from handling degenerate cases specially.

Unless they mean he has to handle them extra.  Or at least mean that the
user has to think about passing on degenerate cases cleanly.

> The same argument applies to (begin), (cond), and (case-lambda).  They
> simplify writing robust syntax transformers without having to handle
> degenerate cases specially.

Correct me if I am wrong (I actually have not really understood syntax
transformers), but the usual patterns of xxx ... can't be empty (that
is, the ... could be empty, but you still need something to match xxx in
order to have the ... identifiable).  That has always struck me as an
ugly limitation of the syntax: _I_ like being able to work with
degenerates.

> Apart from this general argument, I can think of one particularly
> compelling reason to support (begin).  Suppose you have a macro that
> generates a sequence of local definitions.  How do you return an empty
> sequence of definitions without terminating definition context?

(begin (values))

> The only way I can think of is to generate a dummy definition with a
> gensym name.  That's very ugly.

The above is not as ugly, but certainly more than ugly enough.

> Why force users into such complications needlessly?

I agree, but I am not in the situation to give a qualified assessment
about "needlessly": I don't know the implementation details.

-- 
David Kastrup