On Sat, Oct 04, 2008 at 02:05:02PM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

Integers which can fit in an INT_TYPE are stored as such, not as bignums.

yes, but there is a difference between signed and unsigned int. an integer larger than 2147483648 and smaller than 4294967296 does not fit into INT_TYPE

but it would very well fit into an unsigned int type.

if pike handles an array of a few thousand of these the use of bignum vs unsigned int type could make a difference.

(In strings smaller integer types are used as appropriate, because there it actually saves memory.)

right, i was thinking of something like array(int(0..255)) because this could be saved as a string.

greetings, martin.

On Sat, Oct 04, 2008 at 02:25:03PM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

In short, adding a new pike type for "unsigned INT_TYPE" would create lots of work for rather small benefits.

you mean on the C level? since on the pike level that type already exists. anyways, that makes sense and is good enough for me.

If you have a use-case where you would benefit from unsigned INT_TYPEs, I can show you how to rewrite it to benefit from signed INT_TYPEs instead.

if i can rewrite it why can't i let pike do it for me?

just to keep it in line with: "All so that you morons can write crappy code and still have it running fast as a breeze.... "

how would you rewrite an array of ipaddresses for example?

something like this?

class IPAddressList { array(int(-2147483648..2147483648)) ipaddresslist = ({}); int `[](int index) { return ipaddresses[index]+2147483648; } }

greetings, martin.

if pike handles an array of a few thousand of these the use of bignum vs unsigned int type could make a difference.

The tradeoff is with the added complexity of all parts on the C level that handle integers of any sort visible to the language (thousands of places in the code). You don't really want that added burden everywhere for the (relatively) small feature in conserved storage.

Some custom applications that handle tons and tons of numbers in that range and don't want to adapt their logic to use signed integers to get the range right may well benefit from using C, for instance, and unsigned integers, but that does not make it the right decision for a much larger language like Pike.

isn't int(0..4294967295) good enough for that?

That is a compiletime type, not a core runtime type. The runtime values are stored as one of the core runtime types T_INT or T_OBJECT, depending on if it fits in an INT_TYPE or not. What you suggest would require a new core runtime type T_UINT, and support for it in basically all C code which supports T_INT.

...

Adding builtin support for unsigned native integers would mean adding another core runtime type

isn't int(0..4294967295) good enough for that?

You think on the pike language "user" level, but pike has to implement it on the C level, where compile time types are much more of an issue.

If you want to understand it better, you might try working in C a bit, which is a completely different reality, devoid of the dynamic typing that makes int(0..255), int(-128..127), and so on, feel more like the mere changing of a single declaration line rather than something that has big implications on every operation on the value. In pike code we never have to do any bounds checking to cater the type containers -- which is one of the comforts not offered the poor C level programmers.

(Changing languages once in a while is a good reminder of what you like in your favourite one. And, occasionally, what it lacks. :-)

i am happy with no as an answer, i am just trying to understand all the details and alternative solutions so that i can pass them on to people interested in pike who are asking about this.

To view this from a more general perspective, Pike offers a limited set of runtime data types: int, float, string, array, mapping, and multiset(*). It doesn't provide a plethora of different integer types like C, just as it doesn't provide a multitude of hash table variants like HashMap, TreeMap, LinkedHashMap, etc in Java. There is only one integer type and one mapping type. They are designed to be reasonably efficient for general use, but you can't modify them for your specific needs.

Since these types are built directly into the language with special syntax (e.g. "([ ])"), special types, special behaviors in operators, etc, they are very convenient to use. That's both positive and negative, the negative side being that you can't add new builtin types without a lot of effort. You can make objects that mimics them in various situations by implementing `+, __hash, etc, but those objects never become quite the real thing, and they'll be slower.

*) program and type are also runtime types, but they aren't data containers in the sense I'm talking about here, and object is a "catch-all" for everything else.

Well, if you want them in pike they have to be objects.

My point is that people might argue that mapping should have all those variants, just as they argue that int should have an unsigned variant (or that string should have an unshared variant, or that float should have a longer variant, or whatever).

All such arguments don't fit very well with the very deep integration of the basic data types. One could possibly argue for modifying (slightly) the behavior of one of these types, but adding another one is basically a no-no.

Worth noting that it wouldn't necessarily have to be that way, though. The pike internals could have been built with a different architecture so that all referenced data types (i.e. everything except native integers and floats) are basically handled as objects, and all the special behaviors of the type system and operators etc would be controlled by properties in those objects (like in any pure object oriented language).

That would have been pretty, and possibly lessen the code bloat in the core parts. But what we're talking about then is such a fundamental change that almost nothing would remain the same on the C level.

i meant: aren't they objects in java too?

Yes, but the reason I mentioned them is that they are all mapping-like data containers. In Java, C++ and many more you can choose which mapping implementation you want. In Pike you can't (unless you're prepared to take the cost of emulating a mapping with an object, of course).

a pure object pike would indeed be nice :-) but wouldn't that cost optimization?

Maybe, maybe not. It's hard to say. It's mostly a matter of doing the same things but in different places: Instead of having a big global predef::`+ which knows how to add all these types in various combinations, it'd instead be the job of each type to know how to get itself added.