Re: Optional arguments at the beginning

[Sebastian Egner <sebastian.egner@xxxxxxxxxxx>]

Mike Sperber wrote:
> Sebastian Egner <sebastian.egner@xxxxxxxxxxx> writes:
> 
> > Yes, there is little precedent---probably due to the late
> > introduction of SRFI-16 (case-lambda).
> 
> No, I don't believe that's the case. CASE-LAMBDA is nice, but that
> doesn't mean it has to be used everywhere and in any manner
> applicable.

It's true for me. Before CASE-LAMBDA, having optional
arguments
was clumsy and inefficient at best. With CASE-LAMBDA
my barrier
to using variable arity has significantly lowered
because
definitions are clear, and I can pretend it costs
nothing.
  Maybe you already made it to the next level
("options suck").

Since we are having the same discussion for SRFI 68
as well,
it might be worthwhile finding out what is most sensible
to do, at best with convincing arguments. (The one
you gave
above is a little cheap.) It will always be a matter
of
taste, but it would be good for Scheme programming
at large
if we knew the benefits and costs.

So here are the arguments I heard until now (+: pro
option):
+ a lot fewer procedure names to remember
+ notationally concise when options are not present
- potential for confusion, especially in higher-order
style
  (because proc. pops out of nowhere without
name)
- easily overused (too many options) because CASE-LAMBDA
  makes the definition of variable arity convenient
- potentially less efficient (in case arglist gets
allocated)
- often easily covered by section (CUT/CUTE) which
is a
  general orthogonal mechanism

Any more? Any concrete experiences to report?

Will CUT/CUTE make it into R6RS?

> I'm sorry, I should have referred to the rationale.
 You argue that
> the specific overloading you chose favors the optional argument at
the
> beginning:
> 
> - You use overloading to implement the curried version.
> 
>   I think that's a bad idea, partly for the reason described
above,
>   and partly for the existence of SRFI 26, which makes it clear
that
>   there's currying going on with little notational overhead.
 (But who
>   am I talking to? :-) )
> 
> - You ditch the overloading, your rationale goes out the door.

Let's be concrete: How would you set it up the interface?
Would your design still qualify as a replacement for
< = char<?
etc. of R5RS? Are you really willing to pay the price
of writing 
(<? integer-compare x y) everywhere, or are there
other solutions?

Sebastian.