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 checking in + to deal with Integers,
Floats and infinite precision. Line 1212 of Numbers.java has the ops()
method which (I think) implements this
static Ops ops(Object x){
Class xc = x.getClass();
if(xc == Integer.class)
return INTEGER_OPS;
else if(xc == Double.class)
return DOUBLE_OPS;
else if(xc == Float.class)
return FLOAT_OPS;
else if(xc == BigInteger.class)
return BIGINTEGER_OPS;
else if(xc == Long.class)
return BIGINTEGER_OPS;
else if(xc == Ratio.class)
return RATIO_OPS;
else if(xc == BigDecimal.class)
return BIGDECIMAL_OPS;
else
return INTEGER_OPS;
}
3 -- Type hints can take the place of a fast-math library. The compiler
could automatically call the appropriate fast math routine when given
the necessary information.
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 don't think this will slow down math because the String case will be
the last "else if" in ops() and will only happen when the args are not
some sort of Number.
Finally, if it doesn't already, I would expect type hints to make things
faster. So, it should not be necessary to explicitly call a fast-math
library.
My 2 n00by cents...
P
Phil Hagelberg wrote:
> Peter Wolf <opus...@gmail.com> 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 math slows
> down. However, this also means that > and < also don't work on strings,
> which is pretty lousy.
>
> 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 helpful thing by default but being able to offer better
> speed when you need it.
>
> Convenience vs speed is always a trade-off, but I think convenience
> should win in the default case. What do others think about this?
>
> -Phil
>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
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
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
