No, I'd rather not, but I have to take this in bite-size pieces. I'm
still a bit of a noob at writing macros. I want to make it so that
the user does not have to do anything aside from deal with the
argument lists directly, so that means writing different macros for
defn, letfn, defmethod, etc.
On Nov 20, 8:33 am, nchubrich wrote:
> I guess this is getting to be a pretty epic macro! I figured it was
> worth inviting boos and/or cheers and suggestions before setting out...
Far be it from me to discourage making function invocation semantics
more flexible! Just one thing: you've been cal
I should also add something I alluded to in another discussion (under
'positions'); this is the idea of making \any parameter into a rest
parameter. For instance, if you had
(defnsk add [addend augend] ...)
you could call it like (add :addend 1 2 3 :augend 1 2) or (add [1 2 3]
[1 2 3 4]).
Must
I don't see why you couldn't simply check to make sure that there are
no arguments without either default or supplied values. As I wrote
above, "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 valu
On Nov 17, 11:33 pm, nchubrich wrote:
> can it be any more
> general or minimal than this?
Seems to me that your suggestion effectively makes every positional
argument optional. You did note that the scheme calls for supplied-
predicates, but this pushes responsibility for checking required
argum
(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
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 y
On Nov 16, 4:28 pm, Chouser wrote:
> 'let' is also careful to always have the user provide the symbol
> being bound as a symbol. That is you say {:keys [a b c]} not
> {:keys [:a :b :c]}. What do you think of having let-kw take
> symbols instead of keywords for the names being bound?
I think tha
On Mon, Nov 16, 2009 at 12:32 PM, Constantine Vetoshev
wrote:
>
> 2. I tried it with the more let-like form, but I don't like the number
> of opening braces required. For a full kw-spec, the form would end up
> (let-kw [[[:kw default supplied?]] kw-args] ...). Clojure tends to err
> on the side of
1. Looks like everyone prefers the let-kw name. Sounds good to me.
2. I tried it with the more let-like form, but I don't like the number
of opening braces required. For a full kw-spec, the form would end up
(let-kw [[[:kw default supplied?]] kw-args] ...). Clojure tends to err
on the side of fewe
On Nov 16, 8:24 pm, Laurent PETIT wrote:
> Really cool !
Yeah, neat :)
> or (let-kw) for short ?
I like that name better
> This deserves to be placed in contrib, in my opinion.
Yes please!
Nice macro Constantine :)
--
You received this message because you are subscribed to the Google
Gr
Hi,
On Nov 16, 10:24 am, Laurent PETIT wrote:
> This deserves to be placed in contrib, in my opinion.
In fact it could be used to drive defnk. So defnk could be retained as
a convenience (and for backward compatibility) expanding to (defn ...
(fn-keyword ...)).
+1 to some different name, thoug
Really cool !
Some ideas which may (or may not ?) enhance it even further :
Since it creates new local bindings, maybe make it look more like
other binding forms :
instead of (fn-keyword [kw spec] init-kw-val body) :
(let-keywords [ [kw spec] init-kw-val ] body )
?
or (let-kw) for short ?
Ind
Looks like Google Groups posting software forced line wraps at less
than 80 columns, breaking the code. Lovely. Here's the fn-keywords
macro reformatted for 72 column wrapping.
(defmacro fn-keywords
"Adds flexible keyword handling to any form which has a
parameter list: fn, defn, defmethod, l
A couple of days ago, I finally had enough of manually extracting
function keyword arguments. defnk is cool and all, but it does nothing
for fn, letfn, defmethod, or any other form with a parameter list. Map
destructuring is also cool, but providing defaults requires writing
each symbol twice, once
15 matches
Mail list logo
