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

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

[Mark H Weaver]

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.

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.

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

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?  The
only way I can think of is to generate a dummy definition with a gensym
name.  That's very ugly.  Why force users into such complications
needlessly?

     Mark

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

[Alex Shinn]

On Fri, Jan 6, 2012 at 9:49 AM, Mark H Weaver <mhw@netris.org> 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.  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.

Note the "definition context" begin in R7RS does allow zero
arguments because expanding into zero definitions is a
common case.

-- 
Alex

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

[Mark H Weaver]

Alex Shinn <alexshinn@gmail.com> writes:

> On Fri, Jan 6, 2012 at 9:49 AM, Mark H Weaver <mhw@netris.org> 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

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

[Alex Shinn]

On Fri, Jan 6, 2012 at 2:03 PM, Mark H Weaver <mhw@netris.org> wrote:
> Alex Shinn <alexshinn@gmail.com> writes:
>
>> On Fri, Jan 6, 2012 at 9:49 AM, Mark H Weaver <mhw@netris.org> 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
scheme-reports@scheme-reports.org.  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

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

[Mark H Weaver]

Alex Shinn <alexshinn@gmail.com> writes:
> 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).

Not all expressions are evaluated for their return values.  Some are
evaluated solely for their effects, and of course these are the only
expressions where (cond) or (begin) makes sense.

For example, consider a convenience macro to define a structure type.
It expands to a sequence of definitions, one of which is the
constructor.  In the structure specification, each field may provide an
optional `valid?' predicate.  One of the jobs of the constructor is to
make sure that its arguments are valid.

One reasonable way to do this is to include a `cond' in the expansion of
the constructor which contains one clause for each field that provides
the optional `valid?' predicate.  This `cond' would be evaluated solely
for its effect, namely to raise an error if any predicate fails.

However, the structure specification may not have included any field
predicates, in which case the macro would most naturally generate
(cond).

Alternatively, instead of putting all the argument checks into one
`cond', we could instead produce a sequence of `cond's with one clause
each, or perhaps a sequence of `if's.  In this case, the macro would
naturally generate (begin) if no field predicates were provided.

Of course, it is not hard to work around these seemingly pointless
prohibitions, just as it would not be hard to write

  (if (null? xs) 0 (apply + xs))

instead of

  (apply + xs)

but I don't understand why we should have to.  What's the compelling
argument on the other side that justifies these annoyances?

    Thanks,
      Mark

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

[David Kastrup]

Mark H Weaver <mhw@netris.org> 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

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

[David Kastrup]

Alex Shinn <alexshinn@gmail.com> writes:

> On Fri, Jan 6, 2012 at 9:49 AM, Mark H Weaver <mhw@netris.org> 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.

So what?

> 2. the fact that these may be indicators or broken macros.

So may (+).

-- 
David Kastrup

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

[Alex Shinn]

On Fri, Jan 6, 2012 at 5:03 PM, Mark H Weaver <mhw@netris.org> wrote:
>
> For example, consider a convenience macro to define a structure type.
> It expands to a sequence of definitions, one of which is the
> constructor.  In the structure specification, each field may provide an
> optional `valid?' predicate.  One of the jobs of the constructor is to
> make sure that its arguments are valid.
>
> One reasonable way to do this is to include a `cond' in the expansion of
> the constructor which contains one clause for each field that provides
> the optional `valid?' predicate.  This `cond' would be evaluated solely
> for its effect, namely to raise an error if any predicate fails.
>
> However, the structure specification may not have included any field
> predicates, in which case the macro would most naturally generate
> (cond).

Please take this to the scheme-reports list if you really
want the standard changed.

However, you would need actual macro examples to
convince me.  I can't see how you could arrive at the
scenario you're describing.  Assuming you've filtered
out the fields that have predicates into pred-fields,
then you would expand into something like:

  (define (constructor fields ...)
    (begin
      (expand-validate-field pred-fields) ...
      <normal-body>))

where each expand-validate-field would be something
like

  (unless predicate (error "field predicate failed"))

and possibly this would be inlined above instead of
a separate macro.  Alternately, if you don't want
individual error messages but a single error then
you expand into

  (define (constructor fields ...)
    (unless (and (expand-predicate pred-fields) ...)
       (error "some predicates failed"))
    <normal-body>)

where again there's no problem because the empty
(and) is valid.

I think the only reason to use cond would be the
aesthetics of _not_ having any side-effecting expressions,
i.e. you could expand into

  (define (constructor fields ...)
    (cond
      ((expand-predicate pred-fields) (error "invalid field")) ...
      (else <normal-body>)))

where the normal body is the "else" clause
of the cond when no errors occurred, but in
this case the cond is never empty (and always
returns a value or errors).

But I repeat, take this to the list, and polish up
your arguments because you have to convince
the whole group.

> Of course, it is not hard to work around these seemingly pointless
> prohibitions, just as it would not be hard to write
>
>  (if (null? xs) 0 (apply + xs))
>
> instead of
>
>  (apply + xs)
>
> but I don't understand why we should have to.  What's the compelling
> argument on the other side that justifies these annoyances?

This analogy is meaningless, but for the record
you should be using fold or reduce here.

-- 
Alex

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

[David Kastrup]

Alex Shinn <alexshinn@gmail.com> writes:

> On Fri, Jan 6, 2012 at 5:03 PM, Mark H Weaver <mhw@netris.org> wrote:
>
>> Of course, it is not hard to work around these seemingly pointless
>> prohibitions, just as it would not be hard to write
>>
>>  (if (null? xs) 0 (apply + xs))
>>
>> instead of
>>
>>  (apply + xs)
>>
>> but I don't understand why we should have to.  What's the compelling
>> argument on the other side that justifies these annoyances?
>
> This analogy is meaningless, but for the record
> you should be using fold or reduce here.

I don't think it is the task of a language to enforce arbitrary
aesthetic criteria.  He "should be using"?  And one invents arbitrary
syntax rules in order to enforce what he "should be using" rather than
what he could be using if the language worked in a predictable and
logically consistent manner on 0-element cases?

I am perfectly fine with (+) being 0.  That's totally consistent.  I am
not sure whether (-) being an error is a good idea, but since (- 1) is
not even a logical extension backwards from the series ... (- 1 1 1)
(- 1 1), it probably would not make much sense to define the 0-argument
case when the 1-argument case is already an exception.

I was not all too popular with the teachers in school since I tended to
do my proofs from induction starting not with the case of 1-element sums
and products, but rather preferring to start with the 0-element cases
since they tended to be lots simpler.

It boils down to a question of style, and 0-based reasoning tends to be
considered "thinking out of the box" when in reality it is thinking
about a different concept of box.

And I don't think that a computer language should make that hard.  It is
still logical.  If you don't want to go there, that's your own
decision.  But it is cheap to enforce that style on others by
arbitrarily restricting the language.

-- 
David Kastrup

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

[Alex Shinn]

On Fri, Jan 6, 2012 at 9:26 PM, David Kastrup <dak@gnu.org> wrote:
> Alex Shinn <alexshinn@gmail.com> writes:
>>
>> This analogy is meaningless, but for the record
>> you should be using fold or reduce here.
>
> I don't think it is the task of a language to enforce arbitrary
> aesthetic criteria.  He "should be using"?

This has nothing to do with style, but performance
and scalability.  "apply" will blow up in most implementations
depending on the length of the list.

And I never said there was anything wrong with (+)
returning 0, please don't put words in my mouth.

-- 
Alex

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

[David Kastrup]

Alex Shinn <alexshinn@gmail.com> writes:

> On Fri, Jan 6, 2012 at 9:26 PM, David Kastrup <dak@gnu.org> wrote:
>> Alex Shinn <alexshinn@gmail.com> writes:
>>>
>>> This analogy is meaningless, but for the record
>>> you should be using fold or reduce here.
>>
>> I don't think it is the task of a language to enforce arbitrary
>> aesthetic criteria.  He "should be using"?
>
> This has nothing to do with style, but performance
> and scalability.  "apply" will blow up in most implementations
> depending on the length of the list.

Do you think that we should remove the passage

     `concatenate' is the same as `(apply append LIST-OF-LISTS)'.  It
     exists because some Scheme implementations have a limit on the
     number of arguments a function takes, which the `apply' might
     exceed.  In Guile there is no such limit.

from the manual in order not to seduce people into using Guile?

Why should be try to educate people into using a programming style that
delivers suboptimal results with Guile?

Where is the point into keeping Guile in every regard at least as bad as
its worst competitor?

-- 
David Kastrup

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

[Alex Shinn]

On Fri, Jan 6, 2012 at 9:50 PM, David Kastrup <dak@gnu.org> wrote:
> Alex Shinn <alexshinn@gmail.com> writes:
>
>> On Fri, Jan 6, 2012 at 9:26 PM, David Kastrup <dak@gnu.org> wrote:
>>> Alex Shinn <alexshinn@gmail.com> writes:
>>>>
>>>> This analogy is meaningless, but for the record
>>>> you should be using fold or reduce here.
>>>
>>> I don't think it is the task of a language to enforce arbitrary
>>> aesthetic criteria.  He "should be using"?
>>
>> This has nothing to do with style, but performance
>> and scalability.  "apply" will blow up in most implementations
>> depending on the length of the list.
>
> Do you think that we should remove the passage
>
>     `concatenate' is the same as `(apply append LIST-OF-LISTS)'.  It
>     exists because some Scheme implementations have a limit on the
>     number of arguments a function takes, which the `apply' might
>     exceed.  In Guile there is no such limit.
>
> from the manual in order not to seduce people into using Guile?

I think it should be removed because it's no longer true:

scheme@(guile-user)> (apply + (iota 1000000))
standard input:1:0: In procedure #<procedure 102329220 at standard
input:2:0 ()>:
standard input:1:0: Throw to key `vm-error' with args `(vm-run "VM:
Stack overflow" ())'.

-- 
Alex

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

[David Kastrup]

Alex Shinn <alexshinn@gmail.com> writes:

> On Fri, Jan 6, 2012 at 9:50 PM, David Kastrup <dak@gnu.org> wrote:
>> Alex Shinn <alexshinn@gmail.com> writes:
>>
>>> On Fri, Jan 6, 2012 at 9:26 PM, David Kastrup <dak@gnu.org> wrote:
>>>> Alex Shinn <alexshinn@gmail.com> writes:
>>>>>
>>>>> This analogy is meaningless, but for the record
>>>>> you should be using fold or reduce here.
>>>>
>>>> I don't think it is the task of a language to enforce arbitrary
>>>> aesthetic criteria.  He "should be using"?
>>>
>>> This has nothing to do with style, but performance
>>> and scalability.  "apply" will blow up in most implementations
>>> depending on the length of the list.
>>
>> Do you think that we should remove the passage
>>
>>     `concatenate' is the same as `(apply append LIST-OF-LISTS)'.  It
>>     exists because some Scheme implementations have a limit on the
>>     number of arguments a function takes, which the `apply' might
>>     exceed.  In Guile there is no such limit.
>>
>> from the manual in order not to seduce people into using Guile?
>
> I think it should be removed because it's no longer true:
>
> scheme@(guile-user)> (apply + (iota 1000000))
> standard input:1:0: In procedure #<procedure 102329220 at standard
> input:2:0 ()>:
> standard input:1:0: Throw to key `vm-error' with args `(vm-run "VM:
> Stack overflow" ())'.

A "Stack overflow" does not look like a limit in the number of function
arguments but rather a general computation limit.

-- 
David Kastrup

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

[Andy Wingo]

On Fri 06 Jan 2012 07:50, David Kastrup <dak@gnu.org> writes:

> Do you think that we should remove the passage
>
>      `concatenate' is the same as `(apply append LIST-OF-LISTS)'.  It
>      exists because some Scheme implementations have a limit on the
>      number of arguments a function takes, which the `apply' might
>      exceed.  In Guile there is no such limit.
>
> from the manual in order not to seduce people into using Guile?

We should remove it, because it is currently incorrect.  (Apply splats
the lists on the stack, and thus you might run out of stack.  Growing
and shrinking the stack on over/underflow is something that needs
doing.)

> Why should be try to educate people into using a programming style that
> delivers suboptimal results with Guile?
>
> Where is the point into keeping Guile in every regard at least as bad as
> its worst competitor?

Be nice, please.  Alex was just trying to help.

Andy
-- 
http://wingolog.org/

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

[David Kastrup]

Andy Wingo <wingo@pobox.com> writes:

> On Fri 06 Jan 2012 07:50, David Kastrup <dak@gnu.org> writes:
>
>> Do you think that we should remove the passage
>>
>>      `concatenate' is the same as `(apply append LIST-OF-LISTS)'.  It
>>      exists because some Scheme implementations have a limit on the
>>      number of arguments a function takes, which the `apply' might
>>      exceed.  In Guile there is no such limit.
>>
>> from the manual in order not to seduce people into using Guile?
>
> We should remove it, because it is currently incorrect.  (Apply splats
> the lists on the stack, and thus you might run out of stack.  Growing
> and shrinking the stack on over/underflow is something that needs
> doing.)
>
>> Why should be try to educate people into using a programming style that
>> delivers suboptimal results with Guile?
>>
>> Where is the point into keeping Guile in every regard at least as bad as
>> its worst competitor?
>
> Be nice, please.  Alex was just trying to help.

I was not actually trying to be non-nice here.  But the point Alex was
making is that we should not encourage any usage of Scheme that might
work only with Guile, and that we should not let Guile support any
practice that might fail elsewhere.

And I don't get the rationale for that.  Why should we strive hard to
make Guile worse than necessary, just to make it easier for people to
stop using it for their applications?

-- 
David Kastrup

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

[Mark H Weaver]

David Kastrup <dak@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> 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)).

I agree.

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

True, and indeed still an ugliness, even if one with fewer extra
characters.  I myself work hard to make my programs as simple as elegant
as possible.

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

Actually, you are wrong here.  "e ..." can be empty.  If you want to
prohibit the empty list, you need to write something like "e0 e ..."
instead.

However, "e ..." _does_ require a proper list, i.e. without a dotted
tail at the end.  For example "(define (proc arg ...) e0 e ...)" will
_not_ match (define (map f . xs) <blah>).  To match cases like that, you
need to instead make your pattern "(define (proc . args) e0 e ...)".

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

No, that doesn't work.  (values) is an expression, not a definition, and
thus (values) terminates definition context.  (Within a local block,
local definitions cannot follow an expression).

  scheme@(guile-user)> (let () (begin (values)) (define x 3) x)
  While compiling expression:
  ERROR: Syntax error:
  unknown location: definition in expression context in subform x of 3

     Mark

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

[Ian Price]

Mark H Weaver <mhw@netris.org> 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"

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

[David Kastrup]

Mark H Weaver <mhw@netris.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> 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,
>
> Actually, you are wrong here.  "e ..." can be empty.  If you want to
> prohibit the empty list, you need to write something like "e0 e ..."
> instead.

Glad to hear it.  I am pretty sure I have seen a number of examples that
covered the empty case extra but maybe part of the reason could have
been the necessity to _grab_ the first element.

-- 
David Kastrup

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

[Mark H Weaver]

Alex Shinn <alexshinn@gmail.com> writes:

>> Of course, it is not hard to work around these seemingly pointless
>> prohibitions, just as it would not be hard to write
>>
>>  (if (null? xs) 0 (apply + xs))
>>
>> instead of
>>
>>  (apply + xs)
>>
>> but I don't understand why we should have to.  What's the compelling
>> argument on the other side that justifies these annoyances?
>
> This analogy is meaningless, but for the record
> you should be using fold or reduce here.

Yes, I'm aware that using `fold' or `reduce' is more robust for large
lists.  You could just as easily correct anyone who uses alists in a
simple example and say "for the record you should be using a balanced
tree instead."

Or perhaps you're advocating (reduce + 0 xs) over (apply + xs) as a
matter of style.  If so, I happen to agree with you, but that's not the
point.  The point is, (apply + xs) is a sensible thing for someone to do
if xs is not huge, and it's good that Scheme treats this degenerate case
properly.

Similarly, if we are generating a sequence of expressions to be
evaluated for effects only, then an empty sequence has a perfectly
logical and obvious meaning.

     Thanks,
       Mark

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

[Andy Wingo]

Hi David,

On Fri 06 Jan 2012 17:19, David Kastrup <dak@gnu.org> writes:

> But the point Alex was making is that we should not encourage any
> usage of Scheme that might work only with Guile

My understanding of Alex's point was that portability has advantages.  I
certainly benefit from using Alex's code, for example, although Alex
mostly uses other Scheme implementations.

Differing from the Scheme standard is totally OK, but it discourages
code sharing among Scheme systems.  A trade-off, that's all.

> Why should we strive hard to make Guile worse than necessary

Nobody is arguing this :)

Regards,

Andy
-- 
http://wingolog.org/

Who moderates the scheme-reports list?

[Mark H Weaver]

Alex Shinn <alexshinn@gmail.com> writes:
> On Fri, Jan 6, 2012 at 2:03 PM, Mark H Weaver <mhw@netris.org> wrote:
>> 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
> scheme-reports@scheme-reports.org.  We take all
> comments seriously.

I have sent three messages to the scheme-reports list, and none of them
have gone through.  Oleg Kiselyov's messages met the same fate.  Who is
the moderator?

     Mark

Re: Who moderates the scheme-reports list?

[Alex Shinn]

On Tue, May 1, 2012 at 11:10 PM, Mark H Weaver <mhw@netris.org> wrote:
> Alex Shinn <alexshinn@gmail.com> writes:
>> On Fri, Jan 6, 2012 at 2:03 PM, Mark H Weaver <mhw@netris.org> wrote:
>>> 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
>> scheme-reports@scheme-reports.org.  We take all
>> comments seriously.
>
> I have sent three messages to the scheme-reports list, and none of them
> have gone through.  Oleg Kiselyov's messages met the same fate.  Who is
> the moderator?

The moderator is mostly inactive.  Is subscribing
really such a problem for people?  You can just
filter away the messages into a separate folder
(or /dev/null).

-- 
Alex

Re: Who moderates the scheme-reports list?

[Mark H Weaver]

Alex Shinn <alexshinn@gmail.com> writes:
> The moderator is mostly inactive.  Is subscribing
> really such a problem for people?

If subscribers can post without moderation,
then I will be glad to subscribe.

    Thanks,
      Mark

Re: Who moderates the scheme-reports list?

[Alex Shinn]

On Sun, May 6, 2012 at 12:36 PM, Mark H Weaver <mhw@netris.org> wrote:
> Alex Shinn <alexshinn@gmail.com> writes:
>> The moderator is mostly inactive.  Is subscribing
>> really such a problem for people?
>
> If subscribers can post without moderation,
> then I will be glad to subscribe.

Yes, of course they can.  I think at least 95%
of mailing lists these days work the same way
to avoid spam.

-- 
Alex

Re: Who moderates the scheme-reports list?

[David Kastrup]

Alex Shinn <alexshinn@gmail.com> writes:

> On Sun, May 6, 2012 at 12:36 PM, Mark H Weaver <mhw@netris.org> wrote:
>> Alex Shinn <alexshinn@gmail.com> writes:
>>> The moderator is mostly inactive.  Is subscribing
>>> really such a problem for people?
>>
>> If subscribers can post without moderation,
>> then I will be glad to subscribe.
>
> Yes, of course they can.  I think at least 95%
> of mailing lists these days work the same way
> to avoid spam.

If postings will never get accepted anyway, they should be rejected
instead of being silently discarded.  An unannounced "mostly inactive
moderator" is rather impolite.

-- 
David Kastrup

Re: Who moderates the scheme-reports list?

[Ludovic Courtès]

Hi Alex,

My understanding is that these mailing lists require a Google account,
which I’m personally not interested in.

In the past, I subscribed these lists to Gmane [0], but unfortunately,
that doesn’t allow for posting.

Would it be possible to allow for non-subscriber posts?

Thanks,
Ludo’.

[0] http://gmane.org/find.php?list=scheme-reports

Re: Who moderates the scheme-reports list?

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:
> My understanding is that these mailing lists require a Google account,
> which I’m personally not interested in.

No, scheme-reports is a mailman list, and you can subscribe to it the
same way you'd subscribe to any GNU mailing list:

  http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

     Mark

Re: Who moderates the scheme-reports list?

[Alex Shinn]

On Tue, May 8, 2012 at 1:26 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi Alex,
>
> My understanding is that these mailing lists require a Google account,
> which I’m personally not interested in.
>
> In the past, I subscribed these lists to Gmane [0], but unfortunately,
> that doesn’t allow for posting.
>
> Would it be possible to allow for non-subscriber posts?

The internal WG discussion lists require Google
accounts, but you're not allowed to post to those
anyway, and can browse the archives without an
account.

As Mark says, the public scheme-reports@scheme-reports.org
list is a mailman list open to anyone.

Note I talked to the moderator and it seems
there's too much spam to reliably catch real
posts, so he's attempting to set it to automatically
reject non-member posts outright.

-- 
Alex

Re: Who moderates the scheme-reports list?

[Ludovic Courtès]

Hi,

Alex Shinn <alexshinn@gmail.com> skribis:

> As Mark says, the public scheme-reports@scheme-reports.org
> list is a mailman list open to anyone.

OK, I stand corrected.

Thanks,
Ludo’.