I don't like the idea of arbitrary (compiler/interpreter decision) conversion between numeric types in case when performance matters.
Me neither. It was not a proposal, it was a thought experiment to show the flaw in the parallell you drew between implicit type conversions and the internal conversions between native ints and bignums.
/.../ (while Pike is promoted as "similar to C/C++").
Syntactically similar, yes, but made simpler and more powerful. That's done by employing techniques seen in higher level languages like Lisp, e.g. loose typing, type-carrying values, runtime consistency checks, and garbage collection.
/.../ the type of numeric value should not be used as a flag, IMHO
- it leads to mistakes for beginners and mystical behavior when
arguments are mistyped/mispassed.
Not in my experience. Sure, it would be if you refuse to see that ints and floats are two different types. But since we don't want to change that by uniting them to a single numeric type, you better accept it. Once you do, it's not harder to hold ints and floats apart than e.g. ints and strings.
Your argument is somewhat similar to if someone would proclaim that there's no difference between single and double quotes and then whines about the "mystical" behavior when the single quoted "strings" are used in place of real strings.
The function may behave differently if it concerns return value, but if it involves something else - this is EvilThing (r) :)
Just out of curiosity, do you think that testing on run time types (i.e. use of intp, objectp, arrayp etc) is evil in general or is it evil only when used to tell the two numeric types apart?
/.../ Pike is developed as general purpose language (at least now), or?
Yes. More specifically, a high level general purpose language.
Not really. I like the idea of types in general, but I dislike the idea of strict (strongly) types.
Hmm, I don't know what you mean with this, but when I speak about strongly typed languages, I mean languages that resolve all types at compile time so that the values don't need to carry the type at runtime.
BTW, what about floats/ints in Java? Is those types so different there as well?
Java is strongly typed and has implicit type conversions, so I assume you'd call them less "different".
/.../ it is nice to have a language which is well suited for math too, but still is general purpose. Pike could be the one.
Unfortunately not if performance is important, which it typically is in those cases. Since Pike isn't strongly typed it's very hard to avoid the runtime type checks that it must do on every operand. Therefore it'll always be slow when all the calculations are done at the pike level. It can only be made efficient by lumping together many calculations into larger operations that are done in C modules, like Math.Matrix operations.
String may represent something that may not be converted (or interpreted) as numeric value, /.../
I already understand the differences you're describing, but that's beside the point I was trying to make. Forget it.
No type conversion whatsoever can be done in the generic == and equal() operations since that would make them lose the uniform behavior that makes them useful: They can compare any two values, and they always compare both the type and the value part of them, as they are.
I don't deny that a more specialized comparison function for numeric values which handles numeric equivalences, i.e. a numeric_equal(), could be useful. But then I think it works just as well use == and write the casts explicitly.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-16 02:06: Subject: Re: float type weirdness
On Mon, Sep 15, 2003 at 07:25:01PM -0400, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
contain any number, and that would choose between native integer, native float and Gmp object as suitable for the internal representation.
I don't like the idea of arbitrary (compiler/interpreter decision) conversion between numeric types in case when performance matters.
Ints are faster than floats, but floats are fast enough too, while Gmp objects are extremely slow comparing to both ints/floats.
Actually, even implicit bignums in Pike slow down things significantly - just compare execution time for sscanf("\x80\0\0\0", "%4c", n) and sscanf("\x7f\0\0\0", n) where n is an int - and this is typical operation when IP numbers processing is necessary. Multiply this by millions - you will see the difference.
whole slew of languages that are very similar to Lisp in how types and values are handled.
(programming) languages are tuned for specific tasks. Even Touring computer can do everything, but I don't see anyone who uses this. Same with Lisp - it is good for specific, but not general programming, especially for (former) C programmers (while Pike is promoted as "similar to C/C++").
numeric values: There are many functions that behave completely differently when given a float or an integer, i.e. the type itself is
This is a bad idea by itself - the type of numeric value should not be used as a flag, IMHO - it leads to mistakes for beginners and mystical behavior when arguments are mistyped/mispassed. The function may behave differently if it concerns return value, but if it involves something else - this is EvilThing (r) :)
Not at all. Pike is much more similar to Lisp than it is to C in several fundamental ways.
For instance? Sure you can find a lot of similarity between Pike and Lisp, but this is true for C++ and Lisp as well. Pike is developed as general purpose language (at least now), or?
It seems like you're comparing Pike to strongly typed languages like C, C++ and Java.
Not really. I like the idea of types in general, but I dislike the idea of strict (strongly) types. At least, it would be nice to have pragma or something like that to control this. BTW, what about floats/ints in Java? Is those types so different there as well?
I generally wouldn't want to use a language that's primarily designed to do math, since that's a very small portion of what a typical
True, but it is nice to have a language which is well suited for math too, but still is general purpose. Pike could be the one.
operations is to treat all values and types uniformly. In that regard the numeric equivalences are comparable to those of values and their string representations.
String may represent something that may not be converted (or interpreted) as numeric value, while numeric value may always be represented as string
- that's why it makes no sense to blindly (or uniformly) compare strings
and numerics.
Two numeric types are also comparable if we won't take precision into account. Actually, the only difference between int and float is exactly the "floating point", managed by exponent part, but this is implementation detail. They both are _numeric_ types - this is important.
Regards, /Al
/ Brevbäraren