Smaller Datatypes for LSL

Could we please get a few additional datatypes? (just so memory isnt such an issue constantly)

My Suggestions - the whole kit & caboodle of standard X086 datatypes & some suggested names:

short - 16 bit unsigned integer

nybble - 4 bit unsigned integer

char - 8 bit unsigned integer (can also be assigned as a single character)

shortfloat - 8 bit mantissa, 16 bit exponent

coord - vector minus the float for Z

boolean - 1 bit integer (unsigned )

and now for the opposite side of the scale -

word - 32bit unsigned integer

dword - 64bit unsigned integer


-Adam

Totally.

I totally agree with this, espicially with the addition of a bool type. Integers are just too fat to use for a simple TRUE or FALSE comparison.

Also, Id like to see, if bool type is integrated, a way to short circuit conditional statements.

==Chris

the short circuting should be done by the interpreter probably, not the coder.

This gets the Oz Spade stamp of endorsement.

*endorse*

at least a boolean i mean come on

I'll never turn down more types, but I don't get the sense that memory is the limiting factor for most folks right now. I suspect it's processor share.

However, I think we could address both issues (memory and computation) by allowing us to use my personal type wish: homogenous arrays. Not only should these use less memory and be faster than lists, we could use direct indexing, rather than llList2Float(blah).

AND, once we have arrays, I can lobby for pointers. yum. Can pointers be made dummy proof (i.e. safe) and yet still be powerful?

Also, I don't believe a boolean type will save memory. At least not over a short int (it's doubtful the interpreter would take the time to lump bools into the same address, so each would probably end up costing a byte). This is one reason boolean flags often get lumped together as powers of 2 and ORd in LSL rather than each being given separate variables. If you're using a lot of bools and feel this is taxing memory (that'd have to be a LOT of bools), then you can similarly lump them together by defining global variables as powers of two and lumping 16 booleans together in one integer.

I'm curious how LSL works. Is the script interpreted every time it runs, or does it get compiled to bytecode when you save (this would seem very costly for all the debugging that goes on). It would be kind of cool if, after debugging a script, you could have it compiled to binary (say at a cost of L$10 to keep people from bogging the server by compiling each edit) and thus get a significant speed boost for the same processor allotment. Having code that's both interpretable and compilable running simultaneously would probably constitute a C.S. dissertation, so it's very unlikely to happen, but I can dream.

To the best of my knowledge, scripts are compiled to bytecode upon saving, not interpreted at runtime. Costly when debugging, but much more efficient when running, and at any given time the processor load for running scripts is higher than that for compiling.

No pointers. LSL is a language designed for people with little or no programming experience. The amount of safeguards you would have to put into it to make it safe for this audience would cause a serious runtime efficiency hit. Also, with all of these safeguards for the general populace, you would probably have to limit the utility of pointers to such an extent that they would no longer be any more useful than references.