guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

pass at srfi-89 implementation


From: Julian Graham
Subject: pass at srfi-89 implementation
Date: Fri, 2 May 2008 23:37:02 -0400

Hi everyone,

So I've taken a stab at implementing SRFI-89, using Guile's existing
(ice-9 optargs) module -- my thinking was that the two were similar
enough to make it worthwhile to have optargs do most of the heavy
lifting.  What I've done is add some pre-parsing of the formals list
before it's passed to (ice-9 optargs)'s lambda* and some accommodation
of incompatible behavior.  Specifically:

* The (ice-9 optargs) module requires that the #optionals section, if
present, come before the #keywords section, whereas SRFI-89 allows its
corresponding sections to be in either order.

* (ice-9 optargs) requires that non-optional positional formals be
specified before any optional positional or keyword formals.

* (ice-9 optargs) (and, apparently, Common Lisp) adds all the keyword
arguments to the rest argument at call time.

* SRFI-89 doesn't allow duplicate keyword arguments in a function call.

* SRFI-89 keyword definitions allow the value of a keyword argument to
be bound to a variable with a different name than the keyword; (ice-9
optargs) does not.

I think that's everything -- except for one last quirk of (ice-9
optargs) that I discovered last night and am having trouble working
around.  It looks like when you've defined a function that takes
traditional/required as well as keyword arguments, you need to pass
all of the required arguments before passing any of the keyword ones.
For example:

(define* (g a #:key (b #f) #:rest r) (list a b r))

(g 1 #:b 2 3) => (1 2 (3))

...but

(g #:b 2 1 3) => (#:b #f (2 1 3))

The docs sort of hint at why this is implemented the way it is, but I
think it eliminates a lot of the flexibility that keyword arguments
buy you in the first place.  What I want to know is whether this seems
to you like a shortcoming in (ice-9 optargs) that ought to be fixed,
or whether I should just ditch my implementation and go with the
vanilla SRFI-89 implementation included with the specification.

I've attached the draft I've been working on in case anyone wants to
have a look.


Regards,
Julian

Attachment: srfi-89.scm
Description: Binary data

Attachment: srfi-89.test
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]