MOO-cows Mailing List Archive

[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

Re: Ideas about data types (toliteral)

At 03:14 PM 7/22/97 -0400, Erik Ostrom <> wrote:
>The down side of this is that now, for the first time, there may be values 
>that can't usefully be printed (e.g., with toliteral()).  Aaaaand, I'll just 
>leave it at that, for now.

The main reason for a value to be "printed" is so that you can get that
value back via a literal evaluation.  But if these values/types do not have
literal representations, then getting them into a literal form would be
mostly useless (since you can't go back to the value once you have the
literal form).

I don't think this is such a problem, assuming the design that Erik has
already thought out is kept.  Afterall, we can already print the most basic
types in literal format, and freely interchange between values and their
literal representations.  What would be the use of printing out a 500k
dictionary type?  Lists with more than 50 elements are hard to read anyway.
 The only real purpose would be to port these values between different
MOOs, but then, you may be better off just "regenerating" the value
(porting the code to make the value, rather than porting it's literal
representation), for example, using a perl-ish hash table example:

users["Tom"] = #2;
users["Dick"] = #3;
users["Harry"] = #4;

rather than:

users = ["Tom" => #2, "Dick" => #3, "Harry" => #4]

(I actually find the first one more readable; think if this had 100
elements in it.)
Heh, or perhaps a toliteral() of a newly created type could produce the
expressions necessary to build the value.  That would be interesting.  Then
you eval that to get the value, just like you can do with toliteral does now.

Not all values are going to have literal representation.  Erik mentioned
file handles.  I envision people starting to make new types like "binary
trees" and whatnot (which don't have useful literal values), when really,
these should be implemented in MOOcode using the more basic types.

Note that in C, printf takes a %p format spec, allowing you to print the
value of a pointer, and I've commonly used this to verify the value of
pointer to a structure, not really caring what's in the structure.  Perhaps
that relates somehow...

>> If the new datatype is a range type, I would expect the
>> for var in [literal..literal]  construct to allow you to iterate over
>> a sequence of literal values in that type.
>Can you give an example of this?

The expression [1..3] returns the value {1, 2, 3}
This would make list slicing more interesting, to say the least, with
expressions like:

x = {"apple", "orange", "pear", "grapes"}
y = x[1..2,4]

(altho, my example is just like y=x;y[3..3] ={};)
I've often thought how cool this would be.
y = x[$..1] to reverse the list.

Actually, a type such as that supported by $set_utils would be cool.
Would be a set of the numbers from one to fifty, excluding 11 through 19,
31 through 44 and 48.

Allowing a range value over any type is a perl-ish thing, and can make for
some really ugly code. :)  ('aaaa'..'zzzz') is actually much bigger than it
looks. :)


Home | Subject Index | Thread Index