I don't understand, the error message you get is the error that occurred.
the docstring from even? says it throws an exception if the argument
is not and integer.
I would hope that anyone that has read the docstring for contains?
would not use (contains? 'foo 'bar), because, uh, that just makes
On Mon, Nov 9, 2009 at 8:08 PM, Kevin Downey wrote:
>
> I don't understand, the error message you get is the error that occurred.
Both of them honor their documentation - no doubt. My point is not
that, my point is that the behavior is different between the 2
functions for the same kind of issue
The general philosophy in Clojure seems to be that if you use a
function in a way that is not intended, there's no guarantee about
what might happen. You might get an error, or you might just get a
strange result.
--~--~-~--~~~---~--~~
You received this message be
2009/11/9 Tiago Antão :
> What is the rationale for even? and contains? having different
> behaviors for the exact same error (ie, one throws the other works
> fine and just returns false on a type error)? From a design
> perspective this seems to increase the cognitive load to programmers
> witho
the behavior of functions outside of their domain is undefined. I
guess I still don't get it. why would you use a function on something
outside of its domain? do people just pick functions at random to
compose their programs?
2009/11/9 Tiago Antão :
>
> On Mon, Nov 9, 2009 at 8:08 PM, Kevin Down
On Mon, Nov 9, 2009 at 12:32 PM, Kevin Downey wrote:
>
> the behavior of functions outside of their domain is undefined. I
> guess I still don't get it. why would you use a function on something
> outside of its domain? do people just pick functions at random to
> compose their programs?
Of cour
Here's another way to think about it.
Why is functional programming better than imperative programming?
One common answer to this question is that functional programs are
easier to debug. Why? Because in an imperative program, if one part
has an error, the error doesn't necessarily manifest in
what makes functional programming better is the reduction of state. so
for example, if I decide that the function call out to contains? is
too much overhead in a tight loop, I can just copy and paste the
relevant code without being concerned that I might miss some crucial
piece of state it twiddle
On Mon, Nov 9, 2009 at 8:31 PM, Mark Engelberg wrote:
> I imagine the rationale is efficiency. Every core function could
> conceivably do a number of runtime checks to make sure that each input
> is the right kind of type, and then Clojure might feel more sluggish.
> So instead, the core functio
Tiago Antão a écrit :
> Just a question about the consistency of the API:
> When one passes a "strange" (ie, wrong type) object to contains?, say
> (contains? 'blab 'a)
> the result is a false.
> But if one passes the wrong type to, e.g., even?, like
> (even? 'a)
> The result is:
> java.lang.Cla
Even more interesting is the behavior of contains? when passed strings:
user=> (contains? "foo" \o)
false
user=> (contains? "foo" 2)
true
user=> (contains? "foo" 3)
false
user=> (contains? 'foo 2)
false
It seems to treat strings as it does vectors, seeing if an index is in
bounds or not. It doesn
Mark Engelberg wrote:
> 2009/11/9 Tiago Antão :
>> What is the rationale for even? and contains? having different
>> behaviors for the exact same error (ie, one throws the other works
>> fine and just returns false on a type error)?
> I imagine the rationale is efficiency.
Here's the function
On Mon, Nov 9, 2009 at 10:20 PM, John Harrop wrote:
> It seems to treat strings as it does vectors, seeing if an index is in
> bounds or not. It doesn't treat symbols as anything though.
> The clojure.contrib.seq-utils/includes? function gives true for "foo" and
I did not want to make this a di
2009/11/9 Tiago Antão :
> But the end result with strings and vectors is a tad unintuitive...
Right, strings and vectors can be thought of as either collections, or
as associative mappings from integers to characters/objects.
contains? treats them as associative mappings. Yes, it's unintuitive,
> Right, strings and vectors can be thought of as either collections, or
> as associative mappings from integers to characters/objects.
> contains? treats them as associative mappings. Yes, it's unintuitive,
> but it has a certain degree of internal consistency.
This certainly encourages you to
On Mon, Nov 9, 2009 at 5:50 PM, Alex Osborne wrote:
> Mark Engelberg wrote:
> > 2009/11/9 Tiago Antão :
> >> What is the rationale for even? and contains? having different
> >> behaviors for the exact same error (ie, one throws the other works
> >> fine and just returns false on a type error)?
>
On Mon, Nov 9, 2009 at 8:28 PM, John Harrop wrote:
> Why not:
>
> static public Object contains(Object coll, Object key){
> if(coll == null)
> return F;
> else if(coll instanceof Map)
> return ((Map) coll).containsKey(key) ? T : F;
> else if
On Mon, Nov 9, 2009 at 5:41 PM, John Harrop wrote:
> In the meantime, the main thing still missing from Clojure is a convenient
> queue.
What's wrong with clojure.lang.PersistentQueue?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
On Mon, Nov 09, 2009 at 08:41:25PM -0500, John Harrop wrote:
>In the meantime, the main thing still missing from Clojure is a convenient
>queue. Lists and vectors both add and remove efficiently only at one end,
>and at the same end for add and remove in both cases. Doubly-linked lists
>can't be
On Mon, Nov 09, 2009 at 05:53:28PM -0800, Mark Engelberg wrote:
>
>On Mon, Nov 9, 2009 at 5:41 PM, John Harrop wrote:
>> In the meantime, the main thing still missing from Clojure is a convenient
>> queue.
>
>What's wrong with clojure.lang.PersistentQueue?
The only clojure constructor I could fi
On Mon, Nov 09, 2009 at 05:54:36PM -0800, David Brown wrote:
>Depending on use behavior, you can also make a decent lazy queue just
>out a two lists, where you reverse and append whenever the source side
>fills up.
Ok, this is what PersistentQueue is, except without the reverse and
append, so it
On Mon, Nov 9, 2009 at 5:54 PM, David Brown wrote:
> Perhaps the GHC Data.Sequence library could be ported. It's based on
> 2-3 finger trees, and allows efficient adding and removal from either
> end of the sequence.
I've tried porting finger trees to Scheme before, and although it is
efficient
On Mon, Nov 9, 2009 at 8:41 PM, John Harrop wrote:
> In the meantime, the main thing still missing from Clojure is a convenient
> queue. Lists and vectors both add and remove efficiently only at one end,
> and at the same end for add and remove in both cases. Doubly-linked lists
> can't be made p
On Mon, Nov 9, 2009 at 8:53 PM, Mark Engelberg wrote:
> On Mon, Nov 9, 2009 at 5:41 PM, John Harrop wrote:
> > In the meantime, the main thing still missing from Clojure is a
> convenient
> > queue.
>
> What's wrong with clojure.lang.PersistentQueue?
There is one? There's no corresponding API i
Yes, it's in Clojure 1.0, it just doesn't have a convenient name.
So give it a convenient name like this:
(def empty-queue clojure.lang.PersistentQueue/EMPTY)
and then you're ready to go.
conj, peek, pop, into and all the other sequence-based functions work
the way you'd expect.
The implementa
On Mon, Nov 9, 2009 at 10:37 PM, Mark Engelberg wrote:
> Yes, it's in Clojure 1.0, it just doesn't have a convenient name.
>
> So give it a convenient name like this:
> (def empty-queue clojure.lang.PersistentQueue/EMPTY)
>
> and then you're ready to go.
>
> conj, peek, pop, into and all the other
> How does it efficiently deal with when the list-part has been completely
> consumed?
Well, the latest code is here:
http://github.com/richhickey/clojure/blob/master/src/jvm/clojure/lang/PersistentQueue.java
I don't know whether it has changed since 1.0.
Just look in the src/jvm/clojure/lang dir
On Mon, Nov 9, 2009 at 3:31 PM, Mark Engelberg wrote:
>
> 2009/11/9 Tiago Antão :
>> What is the rationale for even? and contains? having different
>> behaviors for the exact same error (ie, one throws the other works
>> fine and just returns false on a type error)? From a design
>> perspective th
On Nov 10, 2:28 am, John Harrop wrote:
> (I suppose T and F are static fields holding java.lang.Booleans, and this
> code was written pre-autoboxing?)
It's still much faster to use a "pre-boxed Boolean" than to create a
new boxed value every time around.
Kresten
--
You received this message
29 matches
Mail list logo
