On Fri, Feb 27, 2009 at 12:47 AM, Allen Rohner wrote:
>
>
>> I agree regarding concatenation as well, but I think the case for
>> comparison of non-numerics is still pretty strong.
>>
>> -Phil
>
> Are you referring to using <, >, =, with objects that implement
> java.lang.Comparable?
>
> i.e. giv
On 26.02.2009, at 20:18, Phil Hagelberg wrote:
> One approach that's been proposed in #clojure is to make these
> functions
> more capable by default, but then provide a fast-math library that
> could
> redefine them in terms of numerics-only. I'm a big fan of functions
> doing the most helpf
> I'm not sure of the details since I don't know much about Java, but that
> sounds about right. I'm working on a date library, and having to use
> functions like earlier? and later? rather than >, <, <=, and >= feels
> awkward.
You are probably thinking of dates as numerical longs rather than
ac
Allen Rohner writes:
>> I agree regarding concatenation as well, but I think the case for
>> comparison of non-numerics is still pretty strong.
>
> Are you referring to using <, >, =, with objects that implement
> java.lang.Comparable?
>
> i.e. given x.compareTo(y) == -1
> (< x y)
> => true
>
>
If we wrote (add 2 3), there would be no confusion at
> all about what (add "foo" 2) should do, because you'd be writing (conj
> "foo" (str 2))
I wrote this too hastily. This could more easily be written (str "foo"
2)
--Allen
--~--~-~--~~~---~--~~
You received th
> I agree regarding concatenation as well, but I think the case for
> comparison of non-numerics is still pretty strong.
>
> -Phil
Are you referring to using <, >, =, with objects that implement
java.lang.Comparable?
i.e. given x.compareTo(y) == -1
(< x y)
=> true
I would find that useful.
Al
On Feb 26, 4:56 pm, Peter Wolf wrote:
>
> So my vote is that String are atomic built in objects, and at least +, <
> and > should work with Strings. The behavior should be just like Java,
> so (+ "foo" 2) --> "foo2"
I have an HP calculator. (I may get some of the details wrong here, I
haven
Laurent PETIT writes:
> > Concatenation is not addition. I'm almost opposed to numeric operators
> > all together. If we wrote (add 2 3), there would be no confusion at
> > all about what (add "foo" 2) should do, because you'd be writing (conj
> > "foo" (str 2))
>
> Agree
I agre
Agree,
I even think there *could* be some utility in having the opposite behavior
(but I'm not even sure about that) :
(+ "1" 2) --> 3 by + trying to cast its non numeric arguments before
throwing an exception ...
--
Laurent
2009/2/26 Allen Rohner
>
>
> >
> > So my vote is that String are at
>
> So my vote is that String are atomic built in objects, and at least +, <
> and > should work with Strings. The behavior should be just like Java,
> so (+ "foo" 2) --> "foo2"
>
-1
Concatenation is not addition. I'm almost opposed to numeric operators
all together. If we wrote (add 2 3), the
OK had my coffee, and had several thoughts...
1 -- What are Strings? How should the Clojure programmer think about
them? Are they sequences, in which case all the sequence functions
should work. Or are they atomic built-in types like Integers and Floats?
2 -- There is already some type chec
On Thu, Feb 26, 2009 at 1:18 PM, Phil Hagelberg wrote:
>
> Peter Wolf writes:
>
> > Is there a good reason that + can't do the right thing as with other
> > Java and scripting languages? I think this would be popular with
> > non-LISPers.
>
> Putting a type check in + would slow down basic math
Peter Wolf writes:
> Is there a good reason that + can't do the right thing as with other
> Java and scripting languages? I think this would be popular with
> non-LISPers.
Putting a type check in + would slow down basic math, and there is a
class of user who will complain loudly if basic mat
13 matches
Mail list logo
