On 4/12/06, Eli Barzilay <xxxxxx@barzilay.org> wrote:
> On Apr 12, felix winkelmann wrote:
> >
> > I must say that even though I use keyword args regularly, I don't
> > think they are the be-all and end-all solution for everything.
> > Keywords are one possible way to handle complex argument sets, it's
> > relatively easy to implement and scales (sort of) with regard to
> > maintenance.
>
> That same description applies to plenty of other srfis that are far
> from a "be-all and end-all solution".  (That's what RnRS is for...
> hopefully...)
>

Sure. I'm not talking about other SRFIs. I'm talking about this one.

> Let me give an example -- in PLT there is a library called SlideShow
> for generating presentations.  It currently has these functions for
> constructing slides:
>[...]
> You can see how all of this can be folded into a single function.  One
> popular argument is: "So what?  These functions construct different
> kinds of things, so it's only proper that they have different names.".
>

I don't claim that it isn't useful in certain situations, yet you can always
simulate keyword arguments (if you really need them) by passing
symbols/value pairs (instead of keyword/value pairs).

>
> So purists don't like it.  I don't care.  As a semi-purist (at times
> when I choose to be one) I can dislike it too, but for getting stuff
> done it's damn useful.

Sure, I wasn't saying anything different.

>
> > Again, I use this stuff: I like quick hacks and I have to think less
> > about API-design when using keyword args. But It's still ugly and
> > ad-hoc, and no SRFI material for me (everything IMHO, naturally).
>
> As Joe Marshall said at some point -- it's a complex hack, and not too
> good-looking, but it's still very practical.  (But I don't know what
> you're trying to say above -- you argue for the thing, then conclude
> that it's not srfi material.  I can think of several srfis that are
> less useful thant this one.)

I don't argue for it - I'm merely saying that I use it. I can use something
that borders on a hack (because it helps sometimes) and still be of the
opinion that there are better ways. I can think of several SRFIs that are
less useful, too, that doesn't mean I prefer them.
Whether you use roll-your-own keywords by taking symbol/value pairs,
or whether you wrap up arguments in a data-structure - there _are_ ways
to handle the problem of complex argument lists, and that don't require
you to fix every call-site (please avoid redundant arguments in which
situation what is to be preferred - I'm sure you get the gist of what
I'm saying).
I wouldn't even bother with this SRFI, if it weren't for the reason that keyword
args now will generate yet another heap of follow-up SRFIs and sneak
into the SRFI-76 discussion, which is in my opinion a waste of energy.
It's just to easy to put a keyword-enabled interface onto everything.
Will be see keywordized SRFI-1/13/14 soon? (Don't bother - that was
just rethorical)

cheers,
felix