Mike Sperber wrote:
> Sebastian Egner <xxxxxx@philips.com> 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.