MOO-cows Mailing List Archive
[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
Re: Ideas about data types
>
> A couple of points:
>
> Firstly, with regard to literals of new data types, I expect that the
> best way to implement this would be in the lexical analyzer. It would
> be fairly simple to call a series of load-time registered functions at
> the end of the lexical analyzer. The parser would then need to deal
> with a generic "literal data" token. The goal would be to avoid
> recompilation of the lexical analyzer, and certainly to avoid
> re-lexing and re-yaccing, when adding new data types.
I agree. It is rather unreasonable to expect you to rebuild the server
(at least teh lex and yacc portions) just to add support for literals of
a new datatype. This especially makes it difficult to dynamically (while
the MOO is running) add a new datatype.
I suppose the yacc grammar would have to call the datatype's parser
when it gets something it can't handle.
I will have to look at teh server code. My vague memory is that YACC
has a yyerror() function that may help us here.
I do remember the lexer handles recognistion of float constants.
>
> Also, we may want to consider changing the way in which the server
> deals with "INT", "FLOAT", etc. Currently, these are *variables*
> automatically created at the beginning of each stack frame. I think
> that "plug-in" data types would be an excellent place to change this
> somewhat ugly behavior.
>
I agree. that is why I suggested the builtins typename(number) and
typevalue("typestring"). Perhaps the new version of the server could
just replace INT with typevalue("INT") similar to the way it
replaces unknown built-ins with call_function()
> On the issue of operators, I would point out that some MOO operators
> are already overloaded (i.e., perform multiple functions depending on
> the types of their arguments). For instance, if '+' gets integers, it
> performs integer addition; with floats, it performs floating point
> addition; and with strings, it concatenates. It would be fairly
> simple to allow new data types to register functions for the various
> operators. This could be handled in the guts of run() in a manner
> transparent to the parser and to the lexical analyzer...
>
> --Nick
I agree again. I don't know of any MOO operators that take operands of
two separate types. This is nice because it cuts down on need for
searching for what code to run when the operator is executed.
Great comments. Now I guess I need to look at parser.y and figure out
where the support for lexing a literal of a new datatype would have to
be inserted. Um, and I guess in the code of unparser.c too.
David (whitten@netcom.com) (713) 791-1414 ext 6116
: rocky/boriz at most MOOs.
References:
Home |
Subject Index |
Thread Index