You can see it if you read:
user=> (read-string "(= (list {'a 42}) '({'a 42}))")
;;=> (= (list {(quote a) 42}) (quote ({(quote a) 42})))
If you remove it:
user=> (= (list {'a 42}) '({a 42}))
;;=> true
On Saturday, September 26, 2015 at 3:12:44 PM UTC+2, Chris Cornelison wrote:
>
> Anyone know
(doc dir)
-
clojure.repl/dir
([nsname])
Macro
Prints a sorted directory of public vars in a namespace
On Friday, April 4, 2014 6:53:54 PM UTC-5, Christopher Howard wrote:
>
> Is there some trick Clojure command to list all functions defined in a
> namespace?
>
--
You
On Fri 4 Apr 2014 at 03:53:54PM -0800, Christopher Howard wrote:
> Is there some trick Clojure command to list all functions defined in a
> namespace?
I use these functions to create cheatsheets on the fly:
(defn fn-var? [v]
(let [f @v]
(or (contains? (meta v) :arglists)
(fn? f)
On Apr 4, 2014, at 7:53 PM, Christopher Howard wrote:
> Is there some trick Clojure command to list all functions defined in a
> namespace?
http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/ns-publics
is a good start.
--Steve
--
You received this message because you are su
Hey,
I replied in the ticket with some comments. The main issue I see is
that I'm used to the notion that IPersistentLists are things which are
not lazy and which have next/rest parts which are themselves IPLs and
this approach seems to cause that no longer to be the case. If it were
not to be the
I found CLJ-1060 [1] and added there a patch with Cons implementing
IPersistentList and (apply list args) in one-argument case of list*.
Marek
[1] http://dev.clojure.org/jira/browse/CLJ-1060
On Wednesday, December 26, 2012 9:35:25 PM UTC+1, Marek Šrank wrote:
>
> function list* doesn't return
On 27 December 2012 18:52, Ben Wolfson wrote:
> On Thu, Dec 27, 2012 at 9:08 AM, Michał Marczyk
> wrote:
>> On 27 December 2012 03:28, Tom Jack wrote:
>>> It looks like the only thing missing to make Cons implement IPersistentList
>>> is IPersistentStack. Why not implement it?
>>
>> IPersistentS
Making Cons implement IPersistentList will solve all cases except when
list* gets only one argument. This is problematic. The source looks like
this:
(defn list*
"Creates a new list containing the items prepended to the rest, the
last of which will be treated as a sequence."
{:added "1.0"
On Thu, Dec 27, 2012 at 9:08 AM, Michał Marczyk
wrote:
> On 27 December 2012 03:28, Tom Jack wrote:
>> It looks like the only thing missing to make Cons implement IPersistentList
>> is IPersistentStack. Why not implement it?
>
> IPersistentStack extends IPersistentCollection, which includes
> cou
On 27 December 2012 03:28, Tom Jack wrote:
> It looks like the only thing missing to make Cons implement IPersistentList
> is IPersistentStack. Why not implement it?
IPersistentStack extends IPersistentCollection, which includes
count(), so that's no go for Cons (the rest part might be a lazy seq
On Wed, Dec 26, 2012 at 6:28 PM, Tom Jack wrote:
> A small bug in ClojureScript was related to this:
> https://github.com/clojure/clojurescript/commit/88b36c177ebd1bb49dbd874a9d13652fd1de4027
>
> It looks like the only thing missing to make Cons implement IPersistentList
> is IPersistentStack. Why
A small bug in ClojureScript was related to this:
https://github.com/clojure/clojurescript/commit/88b36c177ebd1bb49dbd874a9d13652fd1de4027
It looks like the only thing missing to make Cons implement IPersistentList
is IPersistentStack. Why not implement it?
On Wednesday, December 26, 2012 4:13:
On Wed, Dec 26, 2012 at 2:07 PM, Stephen Compall
wrote:
> On Wed, 2012-12-26 at 12:35 -0800, Marek Šrank wrote:
>> ...however, its docstring says: "Creates a new list containing the items
>> prepended to the rest, the last of which will be treated as a sequence."
>
> List is almost always colloqui
On Wed, 2012-12-26 at 12:35 -0800, Marek Šrank wrote:
> ...however, its docstring says: "Creates a new list containing the items
> prepended to the rest, the last of which will be treated as a sequence."
List is almost always colloquial, not literally IPersistentList.
I would be in favor of elim
hey,
thanks, it works. Did not know/think apply can be used in this situation.
Regards,
Amir
On Thursday, December 6, 2012 12:19:28 PM UTC+1, Baishampayan Ghose wrote:
>
> How about using apply?
>
> For example -
>
> (sql/with-connection (db-connection)
> (apply sql/insert-values "table
On Thursday, December 6, 2012 12:18:05 PM UTC+1, Amir Wasim wrote:
>
> I am trying to use insert-values with value-groups which works like the
> following
>
> (sql/with-connection (db-connection)
> (sql/insert-values "table-name" ["id" "val"] [2 "B"][3 "C"]))
>
> here [2 "B"][3 "C"] is wit
How about using apply?
For example -
(sql/with-connection (db-connection)
(apply sql/insert-values "table-name" ["id" "val"] [[2 "B"][3 "C"]]))
Does that work?
-BG
On Thu, Dec 6, 2012 at 4:48 PM, Amir Wasim wrote:
>
> I am trying to use insert-values with value-groups which works like
I'm not aware of such a list, but there aren't that many special forms.
Other than the mentioned fn*, let* and catch, you have loop* and def.
def doesn't create a lexical binding like the others, but creates its var
before evaluating its init-expr.
--
You received this message because you are su
(dotimes [x 10] ...) should do the trick if you're just interested in side
effects.
On Jun 16, 2011, at 12:24 PM, Baishampayan Ghose wrote:
> 'for' is not recommended for causing side-effects. Since you are not using
> the return value of the for comprehension, the lazy sequence is not getting
'for' is not recommended for causing side-effects. Since you are not using
the return value of the for comprehension, the lazy sequence is not getting
realised. You can either use 'doall' around it or better still, use 'doseq'.
Hope that helps.
Regards,
BG
---
Sent from phone. Please excuse bre
On May 24, 10:36 am, Ambrose Bonnaire-Sergeant
wrote:
> On Wed, May 25, 2011 at 12:55 AM, Alex Robbins <
>
> alexander.j.robb...@gmail.com> wrote:
> > What is the difference between
> > (into #{} (for x..))
> > and
> > (set (for x ..))
> > Is one preferred?
>
> I don't think one is preferr
On Wed, May 25, 2011 at 12:55 AM, Alex Robbins <
alexander.j.robb...@gmail.com> wrote:
> What is the difference between
> (into #{} (for x..))
> and
> (set (for x ..))
> Is one preferred?
>
>
I don't think one is preferred over the other in general.
Personally I prefer into, I find it gen
On Wed, May 25, 2011 at 12:20 AM, Mark Engelberg
wrote:
> Scala's approach to comprehensions is to automatically produce the
> same type of collection that is used first in your comprehension.
> Clojure's approach is to always produce a lazy sequence which can then
> be "poured" into the collectio
What is the difference between
(into #{} (for x..))
and
(set (for x ..))
Is one preferred?
Thanks!
Alex
On Tue, May 24, 2011 at 11:20 AM, Mark Engelberg
wrote:
> Scala's approach to comprehensions is to automatically produce the
> same type of collection that is used first in your compre
Scala's approach to comprehensions is to automatically produce the
same type of collection that is used first in your comprehension.
Clojure's approach is to always produce a lazy sequence which can then
be "poured" into the collection of your choice using "into". Both
approaches have their merits
> (set (for [x (range 4)] (* 4 x)))
> ;=> #{0 4 8 12}
>
> Does that help?
yes, thank you.
--
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
> Does this actually yield a set in Scala?
yes, it does
> What is p()? A set constructor?
p(i) reads i-nth element from a vector
def selectRow(p: Vector[Int], i: Int) = {
for (i <- (i - i % 9 to i - i % 9 + 8).toSet[Int]) yield p(i)
}
--
You received this message because you are subscri
Hi,
try
(set (for [x (range 4)] (* x 4)))
Cheers
Andreas
On 24/05/2011, at 8:40 PM, MarisO wrote:
> Is it possible to use list comprehension to generate a set ?
> For example in scala I can do:
>
> for (i <- (2 to 8).toSet[Int]) yield p(i)
>
> In clojure this
>
> (for [ x (set (range 4))]
On Tue, May 24, 2011 at 6:40 PM, MarisO wrote:
> Is it possible to use list comprehension to generate a set ?
> For example in scala I can do:
>
> for (i <- (2 to 8).toSet[Int]) yield p(i)
>
>
Does this actually yield a set in Scala?
What is p()? A set constructor?
Thanks,
Ambrose
--
You rece
On Tue, May 24, 2011 at 4:10 PM, MarisO wrote:
> Is it possible to use list comprehension to generate a set ?
> For example in scala I can do:
>
> for (i <- (2 to 8).toSet[Int]) yield p(i)
>
> In clojure this
>
> (for [ x (set (range 4))] (* 4 x))
>
> generates a list.
(set (for [x (range 4)] (*
Hi Maris,
`into` is a useful function for this case.
user>> (into #{} (for [ x (set (range 4))] (* 4 x)))
#{0 4 8 12}
You can use it for lists, maps, vectors.
user>> (into {} '([:a "a"] [:b "b"]))
{:a "a", :b "b"}
user>> (into [] '([:a "a"] [:b "b"]))
[[:a "a"] [:b "b"]]
Thanks,
Ambrose
On Tu
Hi,
On 17 Jan., 11:28, LordGeoffrey wrote:
> The docs don't say that it is lazy. How (as a newbie) can i tell that it
> is lazy?
By the words "the last of which will be treated as a sequence". A
sequence is (in general) lazy. Hence, what list* returns is actually a
sequence and not a list. As m
The docs don't say that it is lazy. How (as a newbie) can i tell that it
is lazy?
Docs:
"Creates a new list containing the items prepended to the rest, the
last of which will be treated as a sequence."
On 17/01/11 06:27, Sean Allen wrote:
the documentation on that could be improved. the doc
the documentation on that could be improved. the doc string for that
is basically the same as for list. but they return different types.
rather surprising when you first see it.
On Sun, Jan 16, 2011 at 1:55 PM, Alan wrote:
> list* consumes its last argument lazily, which means it can't count it
On Jan 16, 2011, at 12:55 PM, Alan wrote:
> list* consumes its last argument lazily, which means it can't count it
That is indeed what it does. seq* would have been a better name. Too late now,
I guess.
-
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Author of /
list* consumes its last argument lazily, which means it can't count it
(a requirement to be a real list). Both functions return objects that
are seqs, though, so you can (seq?) them if you want.
user=> (def x (list* (range)))
#'user/x
user=> (def x (apply list (range)))
java.lang.OutOfMemoryError:
On Wed, Oct 6, 2010 at 16:59, Justin Kramer wrote:
> On Oct 6, 8:39 am, B Smith-Mannschott wrote:
> > On Wed, Oct 6, 2010 at 08:49, Abraham wrote:
> > > ; prints all files
> > > (import 'java.io.File)
> > > (defn walk [dirpath]
> > > (doseq [file (-> dirpath File. file-seq)]
> > > (println
I should mention that Ben's solution is still nice and is basically
how tree-seq is implemented under the hood. It is more idiomatic than
using loop/recur (for most use cases).
Justin
On Oct 6, 10:59 am, Justin Kramer wrote:
> On Oct 6, 8:39 am, B Smith-Mannschott wrote:
>
> > On Wed, Oct 6, 20
On Oct 6, 8:39 am, B Smith-Mannschott wrote:
> On Wed, Oct 6, 2010 at 08:49, Abraham wrote:
> > ; prints all files
> > (import 'java.io.File)
> > (defn walk [dirpath]
> > (doseq [file (-> dirpath File. file-seq)]
> > (println (.getPath file) )))
>
> This doesn't do what you said you wanted
Thanks a lot .. really good
On Oct 6, 5:39 pm, B Smith-Mannschott wrote:
> On Wed, Oct 6, 2010 at 08:49, Abraham wrote:
> > Dear All ,
>
> > I wanted to list the files of a folder , if a folder within , then it
> > should list the files of that folder and so on.. ie recursively list
> > files o
On Wed, Oct 6, 2010 at 08:49, Abraham wrote:
> Dear All ,
>
> I wanted to list the files of a folder , if a folder within , then it
> should list the files of that folder and so on.. ie recursively list
> files of folders
>
> I tried with recur & loop and could not do it . Then i searched the
>
Thanks Stuart!
Wow. It's like a breath of fresh air. My responses are actually arriving on
time.
Really, it felt weird previously, sort of like I was stuck in a timewarp. :-p
- Greg
On Jul 9, 2010, at 6:58 PM, Stuart Halloway wrote:
> Hi Greg,
>
> I thought that the approval process was supp
Hi Greg,
I thought that the approval process was supposed to auto-approve people after a
certain number of approved messages, but that doesn't seem to have happened (at
least in your case).
Your messages are no longer moderated. Sorry for the delays.
Stu
> Is there anything we can do to impro
On Fri, Jan 22, 2010 at 4:55 PM, ataggart wrote:
>
>
> On Jan 22, 1:30 pm, samppi wrote:
>> This is not a big deal: it is a quibble with a weird and inconvenient
>> behavior of list*: when given an empty sequence, it returns nil
>> instead of the empty list. Why is this? According to list*'s
>> d
Fair enough. Clearly list* isn't intended to do what you want. I'd
suggest using (into '() ...).
On Jan 23, 8:38 am, samppi wrote:
> The Clojure parser I'm writing needs to differentiate between nil and
> the empty list. It should parse "[1 2 3]" and read that as [1 2 3],
> and the same for li
The Clojure parser I'm writing needs to differentiate between nil and
the empty list. It should parse "[1 2 3]" and read that as [1 2 3],
and the same for lists, maps, and sets. If it parses "()" and reads
that nil, then it's not working correctly.
In addition, code in some other libraries I'm wri
I'm still confused by why you'd need a list version of vec. Just
return the sequence. Whatever would consume the list should
equivalently consume the seq.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@g
Reading the source code of core.clj, I've just realized that list*
isn't like vec at all: the point of list* is to help the apply
function, and that it doesn't even ever return lists: it always
returns Cons objects (if there are two+ arguments), or a sequence (if
there is one argument). The only ti
@DeSeno: list*'s doc does indeed say that the last element will be
treated as a seq, but the beginning of the same doc definitely says
that list* returns a list. The doc is:
Creates a new list containing the items prepended to the rest, the
last of which will be treated as a sequence.
"The last
See this:
http://groups.google.com/group/clojure/browse_thread/thread/bc938600ddaaeada/0600e5c3f0c44770?lnk=gst&q=nil#0600e5c3f0c44770
--
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
The doc for list* says the last element will be treated as a seq. (seq ())
returns nil.
On Fri, Jan 22, 2010 at 1:30 PM, samppi wrote:
> This is not a big deal: it is a quibble with a weird and inconvenient
> behavior of list*: when given an empty sequence, it returns nil
> instead of the empty
I'm writing a Clojure parser in Clojure. A certain parser reads a
series of forms, and returns a seq (potentially including nil).
Certain other parsers use the first parser to read list forms, vector
forms, map forms, and set forms.
The vector parser calls vec on its contents' sequence, the set pa
On Jan 22, 1:30 pm, samppi wrote:
> This is not a big deal: it is a quibble with a weird and inconvenient
> behavior of list*: when given an empty sequence, it returns nil
> instead of the empty list. Why is this? According to list*'s
> documentation, list* should always return a list.
Judging
Hi,
Am 23.12.2009 um 18:59 schrieb Phil Hagelberg:
>> http://www.google.com/search?hl=en&q=site:github.com+clojure
>
> Also noteworthy: all Clojure projects on Github sorted by most recent
> activity:
>
> http://github.com/languages/Clojure/updated
>
> That weeds out inactive projects.
Then y
BitBucket (the GitHub of Mercurial) has a few pages of Clojure-based
projects: http://bitbucket.org/repo/all/?name=clojure
On Dec 22, 9:27 pm, Kasim wrote:
> I am just thinking if anyone can list up open source projects so one
> can pick and work on?
--
You received this message because you are
I try to avoid using reading macros in macro definitions. Maybe you
could wrap the desired data in a quote form instead?
On Dec 23, 6:13 am, Andreas Fredriksson
wrote:
> Hi,
> I'm prototyping a source translation framework in Clojure and I've run
> across a problem. I have a bunch of files with
Steve Purcell writes:
> http://www.google.com/search?hl=en&q=site:github.com+clojure
Also noteworthy: all Clojure projects on Github sorted by most recent
activity:
http://github.com/languages/Clojure/updated
That weeds out inactive projects.
> But the best plan is to start using clojure for
Here's a good start:
http://www.google.com/search?hl=en&q=site:github.com+clojure
But the best plan is to start using clojure for real work, then contribute to
the open source tools you find yourself using.
-Steve
On 23 Dec 2009, at 02:27, Kasim wrote:
> I am just thinking if anyone can lis
two element vectors implement MapEntry, two element lists do not
On Sat, Jul 11, 2009 at 9:09 AM, Stuart
Halloway wrote:
>
> Is there a reason these work differently?
>
> (into {} [(list 1 2) (list 3 4)])
> -> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.util.Map$Entry
On Fri, May 15, 2009 at 2:36 PM, Vagif Verdi wrote:
>
> What are the use case scenarios where one is preferable to the other
> in clojure ?
A lot of good points have been raised in this thread. A minor point to
add is that literal vectors are a bit easier to pick out in code than
literal lists.
On May 16, 2009, at 8:23 PM, Michel S. wrote:
That's a bit of a red herring, though? You can always rewrite the code
to use normal (as opposed to tail) recursion, if you don't want to use
reverse. Depending on how large the resulting list is, it's a space-
vs-
time tradeoff: the normal recurs
On May 15, 4:41 pm, "Stephen C. Gilardi" wrote:
>
> Another nice benefit of Clojure's efficient vectors over lists is that
> functions that produce a collection of results can produce and store
> them in order without needing to "reverse" the result just before
> returning. Reversing is a
In my own experimentation, I was really surprised to find that
traversal over vectors seemed to be faster than lists, so I tend to
use vectors rather than lists for any "fixed collection" that I'm
basically just traversing once I've built. Haven't benchmarked
recently, though, so this could have
Remember clojure, like other lisps, is homoiconic: the program code
itself is clojure data. Lists are very common in clojure, since a list
is is used in the function invocation syntax, e.g. (inc 0).
Otherwise, used as a general purpose lists have the same benefits of
linked lists over arrays that
On May 15, 2009, at 3:36 PM, Vagif Verdi wrote:
It looks to me like vectors almost completely overtake lists for all
purposes.
I think that's a fair statement.
Lists are still:
- key as the data structure that represents a "call" (to a function,
macro, or special form)
- useful for c
And here are some numbers from my machine:
(def my-list (list 'a 'b 'c 'd 'e 'f 'g 'h 'i 'j))
(def my-vector ['a 'b 'c 'd 'e 'f 'g 'h 'i 'j])
; ~44ms
(time (dotimes [x 100]
(conj my-list 'k)))
; ~26ms
(time (dotimes [x 100]
(pop my-list)))
; ~100ms
(time (dotimes [x 100]
(conj my-vec
I'm no expert, but I think this explain some:
Clojure's conj function is like Lisp's cons, but "does the right
thing", depending on the data type. It is fast to add something to
the front of the list, and slower to add something to the end.
Vectors are the opposite, you can add to the end fast,
ahhh I see. That makes sense. So it's not like procedural
programming. You could see what I was trying to understand.
I didn't want case/swtich semantics. like the (cond) or if, else if
style. I was trying to return at the first true thing, but it doesn't
work like that. it always gets
>
>
> this seemed like a clean, nice way to merge to sorted lists into one
> sorted list. I'm not getting clojure syntax, it seems:
>
>
> (defn listmerge [l1 l2]
> (let [l1first (first l1) l2first (first l2)]
>(if (= l1first nil) l2)
>(if (= l2first nil) l1)
>(if (< l1first l2first)
>
On Jan 11, 5:53 pm, e wrote:
> this seemed like a clean, nice way to merge to sorted lists into one
> sorted list. I'm not getting clojure syntax, it seems:
>
> (defn listmerge [l1 l2]
> (let [l1first (first l1) l2first (first l2)]
> (if (= l1first nil) l2)
> (if (= l2first nil) l1)
>
On Mon, Dec 8, 2008 at 7:15 PM, Chouser <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 10:42 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>>
>> On Dec 8, 10:08 am, Chouser <[EMAIL PROTECTED]> wrote:
>>>
>>> doseq currently supports both. If both appear on the same binding,
>>> the :while is al
On Mon, Dec 8, 2008 at 10:42 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 10:08 am, Chouser <[EMAIL PROTECTED]> wrote:
>>
>> doseq currently supports both. If both appear on the same binding,
>> the :while is always test first regardless of the order in which they
>> appear in the dose
On Mon, Dec 8, 2008 at 10:42 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 10:08 am, Chouser <[EMAIL PROTECTED]> wrote:
>>
>> doseq currently supports both. If both appear on the same binding,
>> the :while is always test first regardless of the order in which they
>> appear in the dos
On Dec 8, 10:08 am, Chouser <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 9:06 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > On Dec 6, 7:52 pm, André Thieme <[EMAIL PROTECTED]> wrote:
> >> (for [x (range 1 20) :when (> x 8) :while (< 0 (rem x 13))] x) ==>
> >> java.lang.Exception: Unsup
On Mon, Dec 8, 2008 at 9:06 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> On Dec 6, 7:52 pm, André Thieme <[EMAIL PROTECTED]> wrote:
>> (for [x (range 1 20) :when (> x 8) :while (< 0 (rem x 13))] x) ==>
>> java.lang.Exception: Unsupported binding form: :while
>>
>> But:
>> (for [x (range 1 20) :w
On Dec 6, 7:52 pm, André Thieme <[EMAIL PROTECTED]> wrote:
> (for [x (range 1 20) :when (> x 8) :while (< 0 (rem x 13))] x) ==>
> java.lang.Exception: Unsupported binding form: :while
>
> But:
> (for [x (range 1 20) :when (> x 8)] x) ==>
> (9 10 11 12 13 14 15 16 17 18 19)
>
> And:
> (for [x (ra
76 matches
Mail list logo
