On 2010 May 5, at 10:32 AM, Stuart Halloway wrote:
A SIMPLER SOLUTION: WARN, DON'T ERR
That's a lot better than being dead with an error.
Is there a way to turn those warnings back into errors for those
really paranoid of us?
PROMOTION AND DEPRECATION
With warn on
On 2010 May 4, at 4:55 PM, Bryce wrote:
For reference, the deriv macro is at
http://github.com/liebke/incanter/blob/master/modules/incanter-core/src/incanter/symbolic.clj
Unquote splicing and switching to `(fn ~fn-args ~(deriv exp v degree))
both produce errors of the type count not supported
On 2010 Apr 30, at 7:33 AM, Rich Hickey wrote:
People don't consider sets, vectors, arrays or strings to have
'keys'.
That is not consistent with the documentation:
Sets: http://clojure.org/data_structures:
Sets support 'removal' with disj, as well as contains? and get, the
latter
On 2010 Apr 30, at 5:45 PM, Mark J. Reed wrote:
Of course. Which is what I would have done automatically with a
Lispier construct. Just still not used to seeing literal vectors as
functions. :)
On Friday, April 30, 2010, Michael Wood esiot...@gmail.com wrote:
Well, you didn't *have* to call
On 2010 Apr 29, at 2:17 AM, Mark Engelberg wrote:
On Wed, Apr 28, 2010 at 10:49 PM, Douglas Philips wrote:
What is the purpose, goal, design-rationale of not making seq-
contains? fast
on maps or sets?
I think Rich's point is that if seq-contains? is sometimes fast and
sometimes slow
On 2010 Apr 29, at 4:21 AM, ataggart wrote:
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val? should expect it to be O(n). The only
effective difference would be that the test
On 2010 Apr 29, at 7:52 AM, Laurent PETIT wrote:
2010/4/29 Mark J. Reed markjr...@gmail.com:
I like this proposal. I'd make contains? an alias for contains-key?
with a deprecation warning, and just forget about seq-contains? in
favor of contains-val?
This makes a lot of sense to me.
(and
On 2010 Apr 29, at 8:27 AM, Meikel Brandmeyer wrote:
did you also check some? I would use (some #{item} coll)
or (some #(= % item) coll) from core instead of sucking in
3.5Mb contrib for includes?.
Odd, isn't it, that there is a special function zero? when everyone
could just use #(= 0 %)
On 2010 Apr 28, at 4:31 PM, Stuart Halloway wrote:
After review, several seq functions from clojure-contrib have been
promoted to clojure [1], [2], [3]. Hopefully the FAQ below will
answer the major questions you may have:
Cool!
3. Why did some of the fn names change?
...Similarly,
On 2010 Apr 28, at 5:14 PM, Meikel Brandmeyer wrote:
If you have a map or a set looking up a key is fast. So contains? is
fast (read O(1) resp. something like O(log32 N)). seq-contains? does
a linear search through a sequence. That is O(N). Protocols cannot
change this.
How is having an
On 2010 Apr 28, at 5:32 PM, Meikel Brandmeyer wrote:
On Wed, Apr 28, 2010 at 05:26:46PM -0400, Douglas Philips wrote:
How is having an optimized version of seq-contains? for sets/maps
any different from what Stuart showed in his video, where reduce can
have a specialization that is faster
On 2010 Apr 28, at 6:10 PM, Stuart Halloway wrote:
The seq in seq-contains? says I want a sequential search.
Protocols *could* make this do something different, but that would
violate the contract of this function.
How would having it work faster if passed a set or map violate that?
On 2010 Apr 28, at 6:55 PM, Stuart Halloway wrote:
Specializations are available where there is a clear use case, e.g.
contains?, peek (instead of last), disj, etc.
...
Tying to concrete types is limiting. *Never* having special purpose
fns that know about performance characteristics is also
On 2010 Apr 28, at 6:06 PM, Meikel Brandmeyer wrote:
Ah, ok. I misunderstood what you were saying. But I think it doesn't
change the argumentation. If seq-contains? was fast on maps and sets,
people would abandon contains? because seq-contains? is always
right:
works on seqs, fast on maps and
On 2010 Apr 28, at 7:38 PM, Mark Engelberg wrote:
But I think you're not fully appreciating the complexity of the
situation. This is not just about performance, but a question of two
different possible semantics for contains?, which is why it can't
*only* be addressed with a protocol.
...
On 2010 Apr 28, at 11:04 PM, Rich Hickey wrote:
It is an important aspect of Clojure that, in general, performance
guarantees are part of the semantics of functions. In particular,
functions are not supported on data structures where they are not
performant.
Understood. That isn't the
On 2010 Apr 22, at 8:17 AM, Base wrote:
say i have a string that contains a form:
(+ 1 1)
I want to actually execute this. How do you do this? I thought that
eval would be able to handle this but apparently am misunderstanding
what eval does.
Well, eval is the second half of what you want.
On 2010 Apr 21, at 8:11 AM, Alex Osborne wrote:
I suggest you use the stable 1.1 releases of both Clojure and contrib
for your initial learning as it will better match the book. When
1.2 is
released stable I'm sure there will be a document written that
explains
the differences.
That
On 2010 Apr 21, at 9:31 AM, Stuart Halloway wrote:
The second level header tells you the branch (e.g. master). On the
left hand side is a list of branches (so you can click on e.g. 1.1.x).
Wow, that is quite subtle. As you click into contrib from clojure.org
it isn't very noticeable.
It
On 2010 Apr 21, at 5:04 PM, Tom Faulhaber wrote:
(For those who don't know, I'm the one who maintains the autodoc API
documentation.)
Cool, thank you!
One resource to use is the index included with each API. (See the
index link in the left sidebar.)
I saw that, but you know, after finding
On 2010 Apr 15, at 11:53 PM, Derek wrote:
(defn foo [map1 map2] (map (fn [k v] (map2 k)) map1))
(foo {:a 1 :b 2} {:a 5 :b 6 :c 7})
When you turn a map into a sequence, you get a sequence of two-element
sequences(1),
so if you change your anonymous function to destructure that, it will
On 2010 Apr 12, at 10:48 PM, Glen Rubin wrote:
I am working with a collection of integer sequences ...(e.g.
coll:
((3 7 3 5 9 2 0 8 4 0 1 2323 4 11...) (243 4 664 478 3948...) (6 3 7 4
3335 2 4 5 7 6...)...)
I want to create an average sequence such that all of the first
elements are averaged,
On 2010 Apr 11, at 1:28 PM, Glen Rubin wrote:
I am working with a collection of sequences ...(e.g.
coll:
((/f /b /c /4 /5 /6 /3 /6 /f /4 /3 /2 /4 /5 /7 /3 /6) (/2 /b /c /4 /
2 /
6 /3 /7 /f /4 /3 /2 /4 /5 /7 /3 /6)...)
I want to partition the sequences into groups of 4, but when I try the
On 2010 Apr 10, at 1:42 AM, Per Vognsen wrote:
On Sat, Apr 10, 2010 at 12:25 PM, Douglas Philips d...@mac.com
wrote:
The differences between def and binding are also weird, since
binding does
not also shadow the meta-data on the var, so not only :macro will
be wrong,
but :file, :line
On 2010 Apr 10, at 3:11 AM, Mike Mazur wrote:
On Sat, Apr 10, 2010 at 12:19, Douglas Philips d...@mac.com wrote:
Run lein deps:
$ lein deps
No project.clj found in this directory.
You need to run `lein deps` from within the labrepl directory. If you
clone the labrepl repo, project.clj
Having a few free moments, I thought I would try to get labrepl
according to the instructions at:
http://github.com/relevance/labrepl
Since I'm using a Mac, I went to the Getting Started (Mac/Linux
command line) section.
Java installed: Check.
lein installed: Check. I even re-re-ran
On 2010 Apr 10, at 12:29 AM, Per Vognsen wrote:
Not surprising. The binding form deals with dynamic run-time extents.
Here you are treating it like Common Lisp's macrolet.
When you
explicitly wrap the inner expression in eval, then the run time of the
outer code effectively becomes the
I'm trying to understand how the two forms here differ:
In a fresh repl:
user= '((a) (b) (c))
((a) (b) (c))
which is OK, those are just symbols.
But then:
user= (defn x [] (a) (b) (c))
java.lang.Exception: Unable to resolve symbol: a in this context
On 2010 Apr 8, at 11:16 PM, Per Vognsen wrote:
It's not a defn thing. If you write (do (a) (b) (c)) at the REPL, you
should see the same exception.
Yes, I would expect that since at the REPL I am asking to have the
expression evaluated immediately.
Same with let.
Yet, if I say: '(do (a)
On 2010 Apr 6, at 9:09 AM, Christophe Grand wrote:
On Mon, Apr 5, 2010 at 4:54 PM, Douglas Philips d...@mac.com wrote:
Immutability is orthogonal to reference-ness.
There is nothing wrong with having immutable cyclic graphs of
values.
There is something wrong with immutable cyclic data
On 2010 Apr 6, at 10:59 AM, Christophe Grand wrote:
The cycles are gone but the identity john-doe aand its curren-state
are still conflated so you get the same problem:
Thus, since simple trees have the exact same issues, circularity is
not the problem.
Really, to me the problem isn't
On 2010 Apr 5, at 3:49 AM, ataggart wrote:
The docs say what characters are guaranteed future-safe for *you* to
use in symbols, nothing more. I don't see what's so puzzling about
this.
I asked a specific question:
Is it really still an open question that the comparison functions
would be
On 2010 Apr 5, at 4:15 PM, Michael Wood wrote:
I think his question should be read as if he had not included any
backslashes anywhere. i.e. he's asking about , , and =. Not \ or
\ etc.
Well, I was/am trying to be precise.
Symbols are looked up by strings and strings contain characters,
(This is a follow up to my query last week, where upon I didn't fully
connect these dots)
According to:
http://clojure.org/reader
\ and \ are not in the valid list of sanctioned symbol characters.
According to:
http://richhickey.github.com/clojure/clojure.core-api.html
On 2010 Apr 2, at 8:06 AM, Rich Hickey wrote:
On Apr 1, 2010, at 7:37 AM, Konrad Hinsen wrote:
- Two characters, . and /, are treated specially even though this
is not or not clearly stated in the documnentation. Better don't
use those in unqualified symbols.
Hmm. There are two sentences
On 2010 Apr 1, at 12:56 PM, Stuart Halloway wrote:
I think you are reading this backwards. Nothing will be removed from
the list, things won't become more limiting. The lack of guarantee
is around the addition of new features.
:)
Clojure is remarkably stable. The ecosystem of libraries
From a pragmatic point of view, I'd summarize the situation as
follows:
- The Clojure documentation lists which characters can be used in
symbols. If you care about long-term portability, you'd best stick
to those, though no one will sign a contract guaranteeing this list
forever.
According to: http://clojure.org/reader
Symbols begin with a non-numeric character and can contain
alphanumeric characters and *, +, !, -, _, and ? (other characters
will be allowed eventually, but not all macro characters have been
determined). ...
It seems that '' is permitted in 1.1,
I've been using clojure 1.1.0 (via MacPorts clojure+rlwrap) and every
time I type Control-C, it kills closure and dumps me back at my shell.
Is that what is supposed to happen?
Is there some other keystroke I should be using that will interrupt
clojure and put me back at the clojure
On 2010 Mar 25, at 11:29 PM, Per Vognsen wrote:
Look at clojure.contrib.repl-utils/add-break-thread!:
http://richhickey.github.com/clojure-contrib/repl-utils-api.html
Nice. Now I have to figure out how to get a clojure rc file! :)
-Doug
--
You received this message because you are
On 2010 Mar 24, at 2:39 AM, Meikel Brandmeyer wrote:
On Mar 24, 2:22 am, Douglas Philips d...@mac.com wrote:
would (let [s1 (first seq1)
s1tail (rest seq1)] ...)
be any better? rest says it calls seq on its argument, and that would
force as well?
Hmmm... So only things like map
Last week, Per Vognsen answered my first version of this question, how
can I number just the vowels in a string: http://groups.google.com/group/clojure/msg/22186113b36041f1?hl=en
But that got me thinking that numbering was just an instance of
consuming from the (iterate inc 0) sequence.
As I
On 2010 Mar 23, at 9:14 AM, Per Vognsen wrote:
Remember the one-liner I gave you last time?
Yup. It was the 'hard coded + 0' parts that had been ruminating in the
back of my mind as being something that could be abstracted out. :)
Since the one you just posted didn't have all the features
On 2010 Mar 23, at 8:26 AM, Meikel Brandmeyer wrote:
here some notes:
Thanks!
I would use vector instead of list in the example since vector is more
idiomatic in Clojure.
Ok. Just my old lisp roots showing. Still haven't gotten the fingers/
spine
rewired to use [] around defn parameters.
On 2010 Mar 23, at 4:13 PM, Meikel Brandmeyer wrote:
(let [[s1 s1tail] seq1
In the above destructuring the first element of s1tail is also
realised.
That is what I mean with one step ahead. I'm not sure why it is done
like this. I does not seem necessary. But I'm not an expert in
On 2010 Mar 23, at 9:28 PM, Per Vognsen wrote:
So you can see that scan-filter-zip is lazy in the source sequence but
apparently not the primary input sequence. That was surprising to me
because I see nothing in my code that should have forced that. Then I
remember that some functions like range
On 2010 Mar 23, at 10:56 PM, Per Vognsen wrote:
:keys elements optionally be two-element vectors with the second
element supplying the default value:
user= (defn funkymonkey [x y z {:keys [[a -1] [b -2] [c -3]]] [x
y z a b c])
What do you think? I hacked this into my local version of
On 2010 Mar 20, at 10:40 AM, Steve Purcell wrote:
Which looks the same as clojure.contrib.seq/reductions to me...
On 20 Mar 2010, at 13:54, Per Vognsen wrote:
Learn to love scan: http://gist.github.com/338682
Thanks Per and Steve! I knew there was catch that I wasn't seeing.
I did see
Hello all,
I'm new to clojure, but not lisp.
I'm looking for a functional way to index/number only some items
of a list.
For example, I know I can do this (indexed is from the contrib
seq_utils library):
(using a short example to
keep it
49 matches
Mail list logo
