[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optional arguments at the beginning
This page is part of the web mail archives of SRFI 67 from before July 7th, 2015. The new archives for SRFI 67 contain all messages, not just those from before July 7th, 2015.
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
It's true for me. Before CASE-LAMBDA, having optional
was clumsy and inefficient at best. With CASE-LAMBDA
to using variable arity has significantly lowered
definitions are clear, and I can pretend it costs
Maybe you already made it to the next level
Since we are having the same discussion for SRFI 68
it might be worthwhile finding out what is most sensible
to do, at best with convincing arguments. (The one
above is a little cheap.) It will always be a matter
taste, but it would be good for Scheme programming
if we knew the benefits and costs.
So here are the arguments I heard until now (+: pro
+ a lot fewer procedure names to remember
+ notationally concise when options are not present
- potential for confusion, especially in higher-order
(because proc. pops out of nowhere without
- easily overused (too many options) because CASE-LAMBDA
makes the definition of variable arity convenient
- potentially less efficient (in case arglist gets
- often easily covered by section (CUT/CUTE) which
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
> - You use overloading to implement the curried version.
> I think that's a bad idea, partly for the reason described
> and partly for the existence of SRFI 26, which makes it clear
> there's currying going on with little notational overhead.
> 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
(<? integer-compare x y) everywhere, or are there