MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Wishful thinking

I know I should have spoken out earlier, but I have 2 main suggestions 
for LambdaMOO... These two reasons alone are pretty much the reason why I 
use LPMOO...

Floating point numbers: They work just like integers, except a float 
would be returned if 1 number in the expression was a float.

;2+2 => 4
;2.0+2 => 4.0
;2.0+2.0 => 4.0

tonum() would be adjusted to convert floats to integers (rounding up). A 
new builtin, tofloat(), would do the same as tonum(), except change the 
parameter to a FLOAT (type 5?)
The current builtins that do trig would return floating point numbers if 
a floating point number was passed to it. Other useful builtins like 
floor() (always rounding down) would be nice too.

Floating point numbers are the entire backing of our space system on 
StarMOO. Without them, space would be very inaccurate.

Tables/dictionaries: Lists with indicies, or keys, other than integers. 
For example:

a = {"a","b","c"}
a[1] => "a"

a = {"a" ~ "Letter A", "b" ~ "Letter B","c" ~ "Letter C"}
a[1] => E_TYPE
a["a"] = "Letter A"

For would have to be modified so that you could do: 
for letter ~ string in (a)
endfor

Additionally, builtins such as tablekeys() and tablevalues():
tablekeys(a) => {"a","b","c"}
tablevalues(a) => {"Letter A","Letter B","Letter C"}

There should be other builtins as well for both types, but compatibility 
with LPMOO would be best. Why am I asking all this from LambdaMOO? LPMOO 
is great, but its slow. Thats because all MOO code has to be translated 
to LPC and executed by DGD. While many of the non-interactive code has 
been ported to LPC (most of out space system, $string_utils, and 
$object_utils), the actual interaction has a significant delay. If floats 
and tables were incorporated into Lambda, that would likely bring 
together the best of both worlds.

Kudos Pavel and Rob!

Joe
Follow-Ups:
Home | Subject Index | Thread Index