[Top][All Lists]
[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
srfi-89.scm
Description: Binary data
srfi-89.test
Description: Binary data
- pass at srfi-89 implementation,
Julian Graham <=