MOO-cows Mailing List Archive

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

Ideas about data types



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: References:
Home | Subject Index | Thread Index