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

# Re: Ideas about data types (toliteral)

- Date: Tue, 22 Jul 1997 15:01:50 -0500
- From:
- Content-Type: text/plain; charset="us-ascii"
- In-Reply-To: <199707221914.PAA01663@radish.research.att.com>
- References: <Your message of "Tue, 22 Jul 1997 10:53:27 PDT." <199707221753.KAA15412@netcom5.netcom.com>

    At 03:14 PM 7/22/97 -0400, Erik Ostrom <eostrom@research.att.com> 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.
    [1..10,20..30,45..47,49..50]
    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. :)

    Andy.

References:

- Re: Ideas about data types

- From: Erik Ostrom <eostrom@research.att.com>

- Prev by Subject: Re: Ideas about data types (fwd)
- Next by Subject: JHM Core Availability?
- Prev by thread: Re: Ideas about data types
- Next by thread: speedy list
- Index(es):
  - Subject
  - Thread

Home | Subject Index | Thread Index