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

# Ideas about data types

- Date: Tue, 22 Jul 1997 10:53:27 -0700 (PDT)
- From:
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=US-ASCII
- In-Reply-To: <Pine.SUN.3.96.970720234609.15003A-100000@ren.us.itd.umich.edu> from "Christopher Unkel" at Jul 20, 97 11:48:33 pm

    I was thinking about MOOlang and datatypes, and realized that I have several
    expectations or thoughts about a language that supports an extensible
    datatype capability.

    One is that most datatypes have constant or literal values.
    These constant or literal values usually have some kind of syntactic
    form, which is distinct from any literals of all the other datatypes.
    floats have exponential notation, (including the decimal point and the E)
    lists have the curly braces {} surrounding them, and a comma between the
    elements. (Actually, I guess the full stop (.) seperates the elements
    of a floating point number - the whole part and the fractional part.)
    objects have a # (octothorpe) preceding.  A string has the quotes
    around its characters.

    Anyway, I was wondering what kind of interface would be best
    to allow for this kind of support for literal values of a new datatype.
    I agree that the server would have to load the definintion of the new
    datatype prior to parsing any programs that have literals specified in
    them.  so a function that is called to create a new in-memory
    literal structure from a string will be necessary.
    There will also be a need to create a new string from an in-memory
    literal structure. (for use by toliteral() and when the MOO checkpoints)

    This is of course, the tip of the iceberg, but is minimal for handling
    assignment to variables, passing as parameters, returning as results
    of verb calls, and writing programs that use the literals.

    One of the hard parts of expressions is handling coercion from
    one type to another type.  The experience we have with floats has
    resolved this issue for MOOlang. Mixing floats and integers
    was considered to be an error.
    Since we have already said that expressions may not mix types,
    we have a much simpler model to handle operators.
    It is necessary that a datatype provide a totype() function/builtin/verb
    just as tofloat(), tostr(), or toobj() exist.

    I would expect that part of loading/registering/checking-in a new datatype
    would include a way to specify what code should be run for each of the
    operators in MOOlang.  (dyadic +,-,*,/,in etc.)

    I suppose that if the new datatype is a container type, that
    it should be able to handle indexing of a variable like lists and strings
    currently allow.  (is a dictionary type really any different than a
    container type that allows indexing by something other than integers?)

    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.
    (personal opinion here, but I could see some usefulness in elevating
    the range operation to a full datatype just like a list -- this would
    provide a distinct unexpanded notation to handle groups of values, just aas
    lists provide a method to handle expanded /evaluated groups of values.)

    On a final note, I would also expect that a datatype would be able to
    register the number that typeof() returns.  And I guess the 'CONSTANT'
    like INT or FLOAT that can be used in comparisons.  Tho knowing how the
    server creates reserved variable names for these, I think a new pair of
    builtins typename(number) and typevalue("typestring") would be better than
    creating a whole bunch of new reserved variable names.
    I would assume you could then code:

    typeof(literal)==typevalue("literal's_type")

    Anyway, I' hope this will start some dialogue on how MOOlang will handle
    new datatypes.

    David (whitten@netcom.com) (713) 791-1414 ext 6116
    : rocky/boriz at most MOOs.

Follow-Ups:

- Re: Ideas about data types

- From: Nick Ingolia <ingolia@mit.edu>

- Re: Ideas about data types

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

References:

- Re: plug-in interface

- From: Christopher Unkel <cunkel@umich.edu>

- Prev by Subject: Re: High Wired MOO Core Release
- Next by Subject: Re: Ideas about data types
- Prev by thread: Re: plug-in interface
- Next by thread: Re: Ideas about data types
- Index(es):
  - Subject
  - Thread

Home | Subject Index | Thread Index