I do not know the specifics of this issue, but just because it was reported
in 2016 does not necessarily imply that the Clojure spec developers believe
it is a bug, rather than something than an unexpected corner case that some
spec users wish would behave differently.
Also, Rich Hickey and Alex
On Wednesday, 18 September 2019 20:48:39 UTC+1, David Bürgin wrote:
>
> This is a known issue, see
> https://clojure.atlassian.net/projects/CLJ/issues/CLJ-1966
>
2016!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send
This is a known issue, see
https://clojure.atlassian.net/projects/CLJ/issues/CLJ-1966
--
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 -
On Tuesday, 17 September 2019 22:34:04 UTC+1, Daniel Dinnyes wrote:
>
> (let [x 42] :clojure.spec.alpha/invalid)
>
> That's an interesting one. It's failing the spec on the let's body, which
is just 'any?' , so this is initially surprising.
However s/valid? is implemented as, approximately,
I am using Clojure 1.10.0
Basic example for the issue is:
(let [x 42] :clojure.spec.alpha/invalid)
This will result in the following exception:
2. Unhandled clojure.lang.Compiler$CompilerException
1. Caused by clojure.lang.ExceptionInfo
Call to clojure.core/let did not conform to spec.
No, I still don't get it. Why wouldn't this work?
(def config1
{:key (fn [] (str "do something horrible complicated here" (:blah state)
(:key other-state) (:something evenmorestate)))})
;; To invoke:
((:key config1))
--
You received this message because you are subscribed to the Google
(defmacro encode [get-key]
(let [body (eval get-key)]
`(~@body)))
It turns out this is actually the macro I'm looking for, but I still don't
want to use eval :(
Honestly, it looks to me that you are concocting something
Honestly, it looks to me that you are concocting something overly
complicated. Are you sure that a combination of anonymous functions and
dynamic variables won't suffice? Can you, in broad strokes, describe what
you want to achieve?
On Sat, Mar 30, 2019, 18:31 Nathan Rogers wrote:
> (def dict
(def dict
{:key `(str "obj isn't defined in this scope" (:blah ~'obj))})
(defmacro encode [ncode get-key]
Ok, so it turns out I have other issues. Args is (:keys dict) and that
doesn't evaluate
(def dict
{:key `(str "obj isn't defined in this scope" (:blah ~'obj))})
Thanks everyone. That's what I needed.
On Fri, Mar 29, 2019 at 3:25 AM Alexander Yakushev
wrote:
> Looks like you are missing a few unquotes. Is this what you expected?
>
> (def dict
> {:key `(str "obj isn't defined in this scope" (:blah ~'obj))})
>
> (defmacro my-macro [my-obj & args]
>
Looks like you are missing a few unquotes. Is this what you expected?
(def dict
{:key `(str "obj isn't defined in this scope" (:blah ~'obj))})
(defmacro my-macro [my-obj & args]
`(let [~'obj ~my-obj]
(print ~(:key dict) ~@args)))
(my-macro {:blah "thingy"} "test string")
;; obj isn't
How about:
(def dict
{:key `(str "obj isn't defined in this scope" (:blah ~'obj))})
(defmacro my-macro [inobj & args]
`(let [~'obj ~inobj]
(print ~(:key dict) ~@args)))
(macroexpand '(my-macro {:blah "thingy"}
(def dict
{:key `(str "obj isn't defined in this scope" (:blah ~'obj))})
(defmacro my-macro [obj & args]
(def dict
{:key `(str "obj isn't defined in this scope" (:blah ~'obj))})
(defmacro my-macro [obj & args]
`(print ~(:key dict) ~@args))
(macroexpand '(my-macro {:blah "thingy"} "test string"))
I have a
Please file a jira with this info at https://dev.clojure.org/jira/browse/CLJ
--
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
) at bug.core$eval7278/
(form-init3641919424619236070.clj:49).
No matching ctor found for class clojure.reflect$typesym$fn__11912
Basically, symbols used inside of macros that had the new datafy protocol added
to their metadata caused this failure.
My use case that lead my to having this issue
f...@helpshift.com writes:
> I want to write a macro
>
> (defmacro params [] 'a 'b 'c)
>
> that will be used in places like this
>
> ;; without macro
> (fnc a b c)
>
> ;; with macro
> (fnc pararms) => (fnc a b c)
If you have a list of params, you can apply a function to it like
I want to write a macro
(defmacro params [] 'a 'b 'c)
that will be used in places like this
;; without macro
(fnc a b c)
;; with macro
(fnc pararms) => (fnc a b c)
If you see this could be easily done by C's #define which was just a text
replacement
--
You received this
x Miller wrote:
>>>>>>
>>>>>> I think the relevant change here is that exceptions thrown during
>>>>>> macroexpansion are now wrapped into CompilerExceptions as a way to
>>>>>> attach
>>>>>> all of
;>>>> all of the source context information. The REPL understands this and still
>>>>> prints the original cause so the printing hides some of that structure
>>>>> (but
>>>>> you can see it by looking at the exception chain).
>>&
And the macro which that test case exercises can be found here:
https://github.com/Engelberg/instaparse/blob/dcfffad5b065e750f0f5835f017cdd8188b8ca2e/src/instaparse/core.cljc#L274
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group,
;>>>>> all of the source context information. The REPL understands this and
>>>>>> still
>>>>>> prints the original cause so the printing hides some of that structure
>>>>>> (but
>>>>>> you can see it by looking at the exception
t structure
>>>>> (but
>>>>> you can see it by looking at the exception chain).
>>>>>
>>>>> This here is a particularly tricky case here though and I think there
>>>>> might be something else coming into play, still looking
here though and I think there
>>>> might be something else coming into play, still looking at it. There was a
>>>> couple other changes inside the compiler exception handling that might
>>>> also
>>>> be coming into play.
>>>>
>>>>
;>>> This here is a particularly tricky case here though and I think there
>>>> might be something else coming into play, still looking at it. There was a
>>>> couple other changes inside the compiler exception handling that might
>>>> also be coming into play.
>>>&g
t be something else coming into play, still looking at it. There was a
>>> couple other changes inside the compiler exception handling that might also
>>> be coming into play.
>>>
>>> (Would have been great to see this during a pre-release build rather
>>> t
o play.
>>
>> (Would have been great to see this during a pre-release build rather than
>> after release! ;)
>>
>>
>> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>>>
>>> Agreed. It is not a problem for functions which throw Assertion
during a pre-release build rather than
> after release! ;)
>
>
> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>>
>> Agreed. It is not a problem for functions which throw AssertionErrors,
>> only macros. But this is a change in behavior which
.
(Would have been great to see this during a pre-release build rather than
after release! ;)
On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>
> Agreed. It is not a problem for functions which throw AssertionErrors,
> only macros. But this is a change in behavior whi
Agreed. It is not a problem for functions which throw AssertionErrors,
only macros. But this is a change in behavior which breaks test suites
which passed previously.
On Tue, Dec 18, 2018 at 1:48 AM alex wrote:
> I'm not sure, but probably it behaves so because of throwing at
> macro
I'm not sure, but probably it behaves so because of throwing at macroexpand
stage.
вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler написал:
>
> Consider the following macro:
>
> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
> => (f 3)
> 8
> => (f true)
> Unexpected error
Consider the following macro:
(defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
=> (f 3)
8
=> (f true)
Unexpected error (AssertionError) macroexpanding f at
(test:localhost:62048(clj)*:265:28).
Assert failed: (number? x)
So, as expected it throws an AssertionError if passed a non-number.
However,
>
> --
> *From:* clo...@googlegroups.com > on behalf of Mark Engelberg >
> *Sent:* Sunday, July 22, 2018 11:41:58 PM
> *To:* clojure
> *Subject:* Re: OK idea to replace conj and cons with "prepend" and
> "append" macros tha
re
Subject: Re: OK idea to replace conj and cons with "prepend" and "append"
macros that have consistent behavior and return same types as args?
The book "Simply Scheme" teaches Scheme via a library that lets students do
things to either the left or right side
On Mon, Jul 23, 2018 at 3:29 AM, Christian Seberino
wrote:
> This might surprise some but I actually think some things are more
> elegant in Clojure than Scheme!
>
Expect these revelations to continue.
--
You received this message because you are subscribed to the Google
Groups "Clojure"
You can also tell them also that since in practice it can be slippery to
keep track of what type of collection you're dealing with, it's common to
defensively coerce, eg. (conj (vec foo) 1 2) instead of just (conj foo 1 2).
On Sun, Jul 22, 2018 at 2:22 PM Christian Seberino
wrote:
> - conj adds
The book "Simply Scheme" teaches Scheme via a library that lets students do
things to either the left or right side of the list, even though the
operations on the right side of the list are inefficient. That author
found it to be more intuitive to his students.
But Clojure is geared more towards
> Just what is it that you want to teach? Principles of computation, or
> Clojure? Not the same. If the former, forget Clojure and give them a week
> to work thru The Little Schemer. Then move on to clojure and the much more
> complex stuff involved.
>
I think you bring up a good point.
I
The whole "conj puts items in a place that's idiomatic for the collection"
makes stuff like `into` possible. In fact, into is (ignoring transients):
(defn into [dest src]
(reduce conj dest src))
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To
On Sun, 22 Jul 2018 at 22:22, Christian Seberino
wrote:
> - conj adds an element in the place best for the collection type.
>
>
> Is this a valid hypothetical to worry about?...
>
> Imagine you're the teacher and make the comment above.
>
> Student responds..
>
> "But why, Mr. Teacher, is the
rd manner about all of the sequence functions going forward.
> Then, I would teach them how to use higher order functions like map,
> filter, reduce, and range to replace loops and mutation in their program
> logic. After this, I would discuss recursion and function composition as
Well I’ve taught Clojure classes a couple dozen times and a short diversion
answering that question seems great. It really doesn’t need to be a 20 minute
discussion. It’s also perfectly ok to say, that’s a more advanced discussion,
let’s have it at a break or in an hour.
Either seems vastly
On Sun, Jul 22, 2018, 4:22 PM Christian Seberino
wrote:
> - conj adds an element in the place best for the collection type.
>
>
> Is this a valid hypothetical to worry about?...
>
> Imagine you're the teacher and make the comment above.
>
> Student responds..
>
> "But why, Mr. Teacher, is the
>
> - conj adds an element in the place best for the collection type.
Is this a valid hypothetical to worry about?...
Imagine you're the teacher and make the comment above.
Student responds..
"But why, Mr. Teacher, is the 'best' place different for lists and
vectors? That seems strange
You can both avoid efficiency concerns and avoid introducing operations that
are not idiomatic Clojure that that they will have to unlearn later when other
Clojure users say their code is weird.
Just:
- There are different kinds of data structures (vector, list, set, map). They
are better for
at
>> Clojure's standard library doesn't make it easy for you to do something
>> inefficient
>>
>
> Do you at least agree it is at least debatable whether an intro class
> might benefit from avoiding efficiency concerns initially?
> I incorrectly assumed that that wou
ns initially?
I incorrectly assumed that that would require macros, but, it really only
requires beginner friendly regular functions.
For example, see this...
(defn comb [& args]
(let [comb_ (apply concat args)
first_ (first args)]
(cond (list? first_)
Thanks, Gary and Justin, for spotting my code mistakes. Serves me right for
not double-checking the outputs at my REPL. :-P
Anyway, my examples with vectors, maps, and sets were all correct using
into. I goofed on lists, because the new elements are naturally always
applied to the front of the
To return to OP's question --
Good idea?
Answer: At first, I saw the standard library as a mud puddle, an inkblot
with just chaos, no airplane or number 42 in it. Then I got this book:
Clojure Programming - Practical Lisp for the Java World - by Chas Emerick,
Brian Carper, Christophe
lojure
>> programmer, I would first teach them the four main data structures (list,
>> vector, map, set) and the functions to operate on each of them. Next, I
>> would teach them the sequence API and demonstrate how these four data
>> structures are represented as sequen
mutation in their program
> logic. After this, I would discuss recursion and function composition as
> the fundamental components of flow control in a functional programming
> language. Finally, I would spend some time going over dynamic vs lexical
> scoping rules, shadowe
our data
> structures are represented as sequences. This enable everyone to reason in
> a straightforward manner about all of the sequence functions going forward.
> Then, I would teach them how to use higher order functions like map,
> filter, reduce, and range to replace loops and mutati
ion composition as
the fundamental components of flow control in a functional programming
language. Finally, I would spend some time going over dynamic vs lexical
scoping rules, shadowed bindings, namespaces, and the call stack.
This should provide your students with most of the groundwork th
| And to be completely clear, I'm not complaining about the design decision in
Clojure. I'm just trying to really understand what the design is, what are the
trade-offs and where the confusion might come from.
conj is what is known as a leaky abstraction. Leaky abstractions aren't always
bad,
> On 19 Jul 2018, at 21:17, Andy Fingerhut wrote:
>
>
> If you wish for the Clojure core team to provide that style of documentation
> for you, I expect your wish will not be fulfilled. It is not technically
> difficult to replace all Clojure doc strings with more verbose variants. It
>
Sorry if if it was not clear. I was not asking for more documentation. I
understand that the documentation of `conj` should not say anything about
how the different implementations work since it is only about adding an
element to a collection in constant time. And you can always have future
On Thu, Jul 19, 2018 at 1:04 PM Benoît Fleury wrote:
> Replying to myself ... :)
>
> 1. Am I wrong in thinking that most Clojure programmers use append/prepend
> as mental models for the different implementations of conj?
>
> No.
>
> 2. Am I wrong in thinking that they shouldn't?
>
> Yes.
>
>
Replying to myself ... :)
1. Am I wrong in thinking that most Clojure programmers use append/prepend
as mental models for the different implementations of conj?
No.
2. Am I wrong in thinking that they shouldn't?
Yes.
Clojure developers need to know the behavior of conj for vectors and
lists.
Building off of something Benoit mentioned about conj not being about order,
but about adding to a collection, consider conj’s behavior when adding a
map-entry to a hash-map:
(conj (hash-map :a 4 :c 1) [:b 3])
=> {:c 1, :b 3, :a 4}
conj is an interface for adding– not to be conflated with
On Thursday, July 19, 2018 at 10:04:39 AM UTC-5, Benoît Fleury wrote:
>
> I agree with Alex. It is important to understand the rationale behind the
> behavior of conj. conj is for adding an element to a collection. It doesn't
> say anything about ordering. It has been chosen as an operation, as
Thanks. I caught that yesterday. Like I said, I'm definitely a beginner.
;)
On Thursday, July 19, 2018 at 2:05:20 AM UTC-5, Vladimir Bokov wrote:
>
> First of all, def in a fn body is antipattern (use let), then do into on a
> itself
>
> (defn concat_ [a b]
> (if (vector? a)
> (into a
>
> - 'you always get back a value of the concrete type you supplied for
> argument X' isn't obviously less cognitively burdensome than 'you always
> get back a sequence'
>
Combining objects of type X should give a result that is of type X. That
seems the most natural to me.
> - doesn't
I agree with Alex. It is important to understand the rationale behind the
behavior of conj. conj is for adding an element to a collection. It doesn't
say anything about ordering. It has been chosen as an operation, as
opposed to append/prepend, because it can be implemented with the
same time
Hey Alan,
Nice job on Tupelo by the way. I do find it a bit bloated though, and
that's why I never use it. Any reason why all the different namespace are
still mixed together? Seem like they could each be an independent lib, like
how the datomic namespace was split out.
On Wednesday, 18 July
First of all, def in a fn body is antipattern (use let), then do into on a
itself
(defn concat_ [a b]
(if (vector? a)
(into a b)
(concat a b)))
четверг, 19 июля 2018 г., 4:07:46 UTC+7 пользователь Christian Seberino
написал:
>
> I'm just a Clojure beginner but it seems that the Lisp
gt;> collection?
>>
>> Anyways, my advice is to teach them concat. It's even nicer then
>> append/prepend. You just give it the arguments where you want them to go.
>>
>> (concat [1] [2 3])
>>
>> (concat [1 2] [3])
>>
>> And it works
Christian,
Nice to have you here. I guess a couple of things are being discussed in
parallel - a few trivial points:
- 'you always get back a value of the concrete type you supplied for
argument X' isn't obviously less cognitively burdensome than 'you always
get back a sequence'
- doesn't
I'm just a Clojure beginner but it seems that the Lisp Way(TM) is to append
and prepend one or more elements
with a single command if possible. The logical name for this command seems
to be concat which led to this..
(defn concat_ [a b]
(def c (concat a b))
(if (vector? a)
should have a core library of their own
>>> that they keep around for cases like this, where they disagree.
>>>
>>> And for beginners, I mean, what are you trying to teach them? What
>>> problem requires them to add items to the beginning and end of a
gt; append/prepend. You just give it the arguments where you want them to go.
>>
>> (concat [1] [2 3])
>>
>> (concat [1 2] [3])
>>
>> And it works for any type of ordered collections, even arrays.
>>
>> Also, this blog I think does a great job at teaching
On Wed, 18 Jul 2018 at 20:40, Gregg Reynolds wrote:
>
> On Wed, Jul 18, 2018, 2:25 PM Robert Levy wrote:
>
>> Literals can be persisted to strings and read back in with no problem,
>> whereas non-literals can't.
>>
>
> That's a different definition of "literal", no? James talked about
>
On Wed, 18 Jul 2018 at 20:19, Gregg Reynolds wrote:
>
> On Wed, Jul 18, 2018, 1:55 PM James Reeves wrote:
>
>>
>> Function expressions don't evaluate to themselves.
>>
>
> To me that means either the definition is wrong or your literal? is
> rigged. Probably the latter; "literal" is meta, it
On Wed, Jul 18, 2018, 2:40 PM Gregg Reynolds wrote:
>
>
> On Wed, Jul 18, 2018, 2:25 PM Robert Levy wrote:
>
>> > Of course you have to "evaluate" to know that, but you also have to
>> evaluate "2" in the same way to know what it means.
>>
>> I think you're missing the point.
>>
>
> I think
On Wed, Jul 18, 2018, 2:25 PM Robert Levy wrote:
> > Of course you have to "evaluate" to know that, but you also have to
> evaluate "2" in the same way to know what it means.
>
> I think you're missing the point.
>
I think maybe we're talking about different things.
2 is literal because you
> Of course you have to "evaluate" to know that, but you also have to
evaluate "2" in the same way to know what it means.
I think you're missing the point. 2 is literal because you read it, eval
it, print it, and 2 (the result of evaluation) as printed is the same as
the original input. A
On Wed, Jul 18, 2018, 1:55 PM James Reeves wrote:
> On Wed, 18 Jul 2018 at 19:38, Gregg Reynolds wrote:
>
>>
>> On Tue, Jul 17, 2018, 4:11 PM James Reeves wrote:
>>
>>>
>>> A data literal evaluates to itself. So for example, `2` is a literal,
>>> because we only need to read it to know its
On Wed, 18 Jul 2018 at 19:38, Gregg Reynolds wrote:
>
> On Tue, Jul 17, 2018, 4:11 PM James Reeves wrote:
>
>>
>> A data literal evaluates to itself. So for example, `2` is a literal,
>> because we only need to read it to know its value, whereas `(+ 1 1)`
>> isn't a literal, because we also
On Tue, Jul 17, 2018, 4:11 PM James Reeves wrote:
> On Tue, 17 Jul 2018 at 21:06, Christian Seberino
> wrote:
>
>>
>> Clojure, on the other hand, takes great care to ensure that its data can
>>> always be represented as literals. For data that isn't a standard
>>> collection type, there are
end of an ordered
>>> collection?
>>>
>>> Anyways, my advice is to teach them concat. It's even nicer then
>>> append/prepend. You just give it the arguments where you want them to go.
>>>
>>> (concat [1] [2 3])
>>>
>>> (conca
concat [1 2] [3])
>>
>> And it works for any type of ordered collections, even arrays.
>>
>> Also, this blog I think does a great job at teaching all this to a
>> beginner
>> https://medium.com/@greg_63957/conj-cons-concat-oh-my-1398a2981eab
>>
>>
>>
items to the beginning and end of an ordered
>>> collection?
>>>
>>> Anyways, my advice is to teach them concat. It's even nicer then
>>> append/prepend. You just give it the arguments where you want them to go.
>>>
>>> (concat [1] [2 3])
>>&
eginning and end of an ordered
>> collection?
>>
>> Anyways, my advice is to teach them concat. It's even nicer then
>> append/prepend. You just give it the arguments where you want them to go.
>>
>> (concat [1] [2 3])
>>
>> (concat [1 2] [3])
>>
>> And
;
> And it works for any type of ordered collections, even arrays.
>
> Also, this blog I think does a great job at teaching all this to a
> beginner https://medium.com/@greg_63957/conj-cons-concat-oh-my-
> 1398a2981eab
>
>
>
> [1] Except for reader macros. Rich didn't want
>
>
> Anyways, my advice is to teach them concat. It's even nicer then
> append/prepend. You just give it the arguments where you want them to go.
>
> (concat [1] [2 3])
>
> (concat [1 2] [3])
Thanks. This is perfect. I'm surprised it didn't up earlier in the
conversation. concat is a single
> But like others have said, that ship sailed in 2008.
>
Well depends what ship you are talking about. Using prepend and append
only requires two new function definitions. That is still easily done in
2018.
--
You received this message because you are subscribed to the Google
Groups
On Tue, Jul 17, 2018 at 3:48 PM, Tomasz Sulej wrote:
>
>
> W dniu wtorek, 17 lipca 2018 22:44:27 UTC+2 użytkownik Christian Seberino
> napisał:
>>
>>
>> data are functions and vice-versa
>>>
>>
>> What do you mean? e.g. How is the [1 2 3] a "function"?
>>
>>
Also take a look in
; (concat [1] [2 3])
>
> (concat [1 2] [3])
>
> And it works for any type of ordered collections, even arrays.
>
> Also, this blog I think does a great job at teaching all this to a
> beginner
> https://medium.com/@greg_63957/conj-cons-concat-oh-my-1398a2981eab
>
>
] Except for reader macros. Rich didn't want you to be able to change the
whole program syntax in unconstrained ways. That's probably a good thing to at
least keep the foundation universal accross code bases.
--
You received this message because you are subscribed to the Google
Groups "Cl
On Tue, 17 Jul 2018 at 22:47, Christian Seberino
wrote:
> When writing software in Clojure, the data structures are often the
>> keystone of the codebase. When I write Clojure, I start by mapping out what
>> data structures and keywords I need, and from there write functions around
>> them. It's
Macros aren't the right tool for that.
If you want to create a function that behaves differently, depending on the
input (Vector, seq or something else, like LinkedHashSet)
you should look into multimethods.
And if you want to do comprehensive data manipulation you should look
into https
I don't entirely buy the official story on this feature, but it is what it
is. In my experience, people do a lot of defensive typecasting, much more
than we reason about performance. Because the performance just doesn't
really matter in the vast majority of cases, and we're more concerned with
>
>
> When writing software in Clojure, the data structures are often the
> keystone of the codebase. When I write Clojure, I start by mapping out what
> data structures and keywords I need, and from there write functions around
> them. It's for this reason that I don't think prepend and append
On Tue, 17 Jul 2018 at 21:06, Christian Seberino
wrote:
>
> Clojure, on the other hand, takes great care to ensure that its data can
>> always be represented as literals. For data that isn't a standard
>> collection type, there are tagged literals. Clojure syntax starts from a
>> representation
Alex, though I mostly support you and value "understand efficiency from
first look" a lot, I'd speak about this:
> There is no Clojure operation for "add something to the right side of a
list" - instead there is the far simpler (in simple vs easy terms) "add
something to a collection"
I think
Ah no worries. I think you made a significant point..." Shaping your use
of the language's raw materials to build up to your domain/application is
very much a Lisp philosophy".
Everyone can use Clojure as they need. Amazing really.
cs
On Tue, Jul 17, 2018 at 3:58 PM, Robert Levy wrote:
>
Whoa, I think you are reading way too deeply into what I wrote. Let me
explain what I meant: Lisp is great, Clojure is great, the community
doesn't typically change the core of the language-- the change process is
very conservative and largely top-down. The rest of it was a cheap shot at
the
W dniu wtorek, 17 lipca 2018 22:44:27 UTC+2 użytkownik Christian Seberino
napisał:
>
>
> data are functions and vice-versa
>>
>
> What do you mean? e.g. How is the [1 2 3] a "function"?
>
>
user> ([1 2 3] 0)
1
user> ([1 2 3] 2)
3
user> ({:a 1 :b 2} 0)
nil
user> ({:a 1 :b 2} :a)
1
> cs
>
--
user> ([1 2 3] 0)
1
user> ([1 2 3] 2)
3
user> ({:a 1 :b 2} 0)
nil
user> ({:a 1 :b 2} :a)
1
On Tue, 17 Jul 2018 at 22:44, Christian Seberino
wrote:
>
> data are functions and vice-versa
>>
>
> What do you mean? e.g. How is the [1 2 3] a "function"?
>
> cs
>
> --
> You received this message
> data are functions and vice-versa
>
What do you mean? e.g. How is the [1 2 3] a "function"?
cs
--
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
1 - 100 of 1020 matches
Mail list logo
