Just linking this diskussion to an earlier one:
http://groups.google.com/group/clojure/browse_thread/thread/b38a2754fd5b8104/fcd7c578238622f5
--
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
On Thu, Jan 28, 2010 at 6:43 PM, Sean Devlin wrote:
> Check the apply-macro namespace in contrib
ah-hah! i really should have figured.
thanks.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups
Check the apply-macro namespace in contrib
Sean
On Jan 28, 4:54 pm, Raoul Duke wrote:
> hi,
>
> if "and" were a function then i could do (apply and [true false]) and
> get false, i think. is there some shorthand for doing that given that
> apply doesn't work with macros?
>
> thanks.
--
You rec
On Thu, Jan 28, 2010 at 5:28 PM, DanL wrote:
> http://en.wikipedia.org/wiki/Fexpr
yeah, funny that. as a long time LtU reader, those have been in the
back of my mind today. :-)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, s
On 29 Jan., 02:05, Mike Meyer wrote:
> IIRC, some Pre-CL lisps had four function definition facilities: You
> could either get all your arguments evaluated, or not; and you could
> get your arguments bound to variables, or just get the list of
> them. The former turned into macros, because that wa
On Thu, 28 Jan 2010 15:08:18 -0800
Raoul Duke wrote:
> > You can sometimes avoid the use of a macro by using alternative evaluation
> > strategies, whether that's provided by odd calling semantics, by pervasive
> > laziness (e.g., one can implement `if` in Haskell using a function), or by
> > man
> Be careful what you wish for!
from what i've experience with laziness, i quite agree -- so far, i do
not like implicit laziness, i mostly want it to be something that
requires ascii annotation. the opposite of ! in haskell.
but, uh, i guess it would suck if even "if" statements were eager and
o
yup. and i mean "i wish lisp had that ability, rather than forcing
everything that isn't strict-evaluation functional argument passing
into compile time macros."
of course, it only moves the newbie (like me with macros) "hey, these
things aren't all exactly the same?!" reaction somewhere else --
On Thu, Jan 28, 2010 at 3:08 PM, Raoul Duke wrote:
> yup. and i mean "i wish lisp had that ability, rather than forcing
> everything that isn't strict-evaluation functional argument passing
> into compile time macros."
of course, it only moves the newbie (like me with macros) "hey, these
things a
> You can sometimes avoid the use of a macro by using alternative evaluation
> strategies, whether that's provided by odd calling semantics, by pervasive
> laziness (e.g., one can implement `if` in Haskell using a function), or by
> manual thunking (or the use of `delay`). If that's what you mean,
A broader analysis of this: because macros work at compile-time,
not at
runtime, you need to know the number of arguments in advance. That
means
for the case of 'and', it seems like if one had other call-by-*
semantics available in the lisp, then one wouldn't have to use a
compile-time macro?
On Thu, Jan 28, 2010 at 2:10 PM, Richard Newman wrote:
>>> Doesn't extend to arbitrary number of arguments, though.
> A broader analysis of this: because macros work at compile-time, not at
> runtime, you need to know the number of arguments in advance. That means
for the case of 'and', it seems
Doesn't extend to arbitrary number of arguments, though.
that was sorta a deal-breaker. :)
A broader analysis of this: because macros work at compile-time, not
at runtime, you need to know the number of arguments in advance. That
means that any solution which requires a variable number of
hi,
On Thu, Jan 28, 2010 at 2:08 PM, DanL wrote:
> That I show you this doesn't necessarily mean that you should use it:
> (let [x [true true false true]]
> (eval `(and ~...@x)))
ah. yes, i believe i've recently read on this list that eval can
easily be the "now you have 2 problems" sort o
Hello!
On 28 Jan., 23:00, Raoul Duke wrote:
> > Doesn't extend to arbitrary number of arguments, though.
>
> that was sorta a deal-breaker. :)
That I show you this doesn't necessarily mean that you should use it:
(let [x [true true false true]]
(eval `(and ~...@x)))
--
You received thi
On Thu, Jan 28, 2010 at 1:59 PM, Richard Newman wrote:
>> is there a general shorthand rule for (apply macro [arg1 arg2])? given
>> your version i'm assuming "no" :-)
> (apply #(macro %1 %2) [arg1 arg2])
i did think of that, but then thought:
> Doesn't extend to arbitrary number of arguments, t
is there a general shorthand rule for (apply macro [arg1 arg2])? given
your version i'm assuming "no" :-)
(apply #(macro %1 %2) [arg1 arg2])
Doesn't extend to arbitrary number of arguments, though. every? does.
--
You received this message because you are subscribed to the Google
Groups "Cloju
On Thu, Jan 28, 2010 at 1:55 PM, Richard Newman wrote:
> (every? identity [true false])
thanks!
is there a general shorthand rule for (apply macro [arg1 arg2])? given
your version i'm assuming "no" :-)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group
if "and" were a function then i could do (apply and [true false]) and
get false, i think. is there some shorthand for doing that given that
apply doesn't work with macros?
(every? identity [true false])
--
You received this message because you are subscribed to the Google
Groups "Clojure" group
hi,
if "and" were a function then i could do (apply and [true false]) and
get false, i think. is there some shorthand for doing that given that
apply doesn't work with macros?
thanks.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this g
20 matches
Mail list logo
