(preceding message, re-formatted)
Suppose one went for broke and made a variable binding form that was
1) Maximally permissive
and
2) Notationally minimal
Without saying whether this is \advisable, we might agree it would be
an interesting exercise.
It might look like this:
\All arguments are potentially keywords; and since you can't bind a
value to anything but a symbol, anything in the argument list that is
not a symbol is interpreted as the default value of the preceding
symbol. So if you wrote
(dfnsk demo1 [x y 1 z u ~x] ..)
it could be called either by
(demo1 1 2 3 4)
or something like
(demo1 :z 3 :x 2)
(If you left the arguments incomplete and unkeyworded it would apply
what you put preferentially to the first arguments in the list
without
a default value. Thus (demo1 1) would specify x and (demo1 1 2) would
specify x and z.)
There needs to be another way of specifying defaults, because you
may want to apply the same defaults to many different values. So at
the end of the list, after any &rest arguments, you could put any
number of triplet vectors like [0 5 nil] or [p w 10]; where the last
element is the default, and the first two are the range for the
default to be applied to, specified either as a position or a variable
name.
When you mix keyword arguments and positional, there could be two
potential interpretations. Consider
(dfnsk demo2 [p q r s t u v w x y z [p z 0]] ...)
If you called it like
(demo2 :u 1 2 4 7)
you could mean either 1) skip ahead in the list to u and fill the
rest of the arguments from there or 2) 'consume' u from the list and
then continue to call the list as ordered with a gap at u. So you
would need an additional notation
such as
(demo2 :skip :u 1 2 4 7)
but I'm not sure how to do that without potential name conflicts.
Finally, you would have a set of predicates that tell you 1) how
many arguments have been supplied and 2) whether a given argument has
been supplied (as Constantine has done). You could make your defaults
if expressions or cond expressions using these predicates (and
whatever else you might want to pend on). You could say, "if x has
not been supplied, make y 2, etc." This could be an alternative (and
I guess more general) way of notating variable arity argument lists.
. I'm not trying to start an argument over whether this would be
too complicated or tricky to use in practice (though this is a good
argument to have too); my immediate question is, can it be any more
general or minimal than this?
Maybe there is some really neat way of encoding arbitrary
preference rules and priorities in an argument list. It's not
occurring to me though.
In any case, the 'complication' is mostly an artifact of the way we
program. If we move a little away from a pure program text and
nothing-but while programming (as IDE's effectively do), we get all
sorts of feedback and help on argument lists, so that it becomes in
part like filling out a form when that helps; and hopefully this
feedback ends up being not too intrusive or distracting. That,
however, is a question for the \en\clojure list.....
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
