This page is part of the web mail archives of SRFI 89 from before July 7th, 2015. The new archives for SRFI 89 contain all messages, not just those from before July 7th, 2015.
On 4/12/06, Eli Barzilay <firstname.lastname@example.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