|Calculating expressions with several types firstname.lastname@example.org (=?koi8-r?B?4c7Uz84=?=) (2000-12-11)|
|Re: Calculating expressions with several types email@example.com (Fairbairn Family) (2000-12-13)|
|Re: Calculating expressions with several types firstname.lastname@example.org (Chris Locke) (2000-12-13)|
|Re: Calculating expressions with several types email@example.com (Jean Pariseau) (2000-12-18)|
|From:||"Chris Locke" <firstname.lastname@example.org>|
|Date:||13 Dec 2000 15:04:07 -0500|
|Posted-Date:||13 Dec 2000 15:04:07 EST|
out ECMA-262 at http://www.ecma.ch/
It gives procedural semantics for evaluation of expressions. It
defines (in its own odd way!) what conversions should be applied at a
particular time when parsing and evaluating expressions.
looked at implementing this sort of stuff before it might be
interesting to see what's involved.
are fairly type anonymous until an explicit value type is required, at
which time type conversion is carried out. Fom your original post it
sounded as if this is the sort of thing you are after. Internally,
objects are carried around in a union with a tag indicating the active
type and corresponding field of the union. New objects are created
with a nul type and value, with appropriate conversion rules. (e.g
nul type converts to the empty string)
Once you get into the area of converting to/from strings you have to
start defining a whole bunch of supported notations e.g. do you
support hexadecimal numbers in String -> Number conversions? What is
the format? Will round-trip conversions (e.g. String -> Number ->
String) yield consistent results. The ECMA-262 standard has to go
into those sorts of details! Depending on what your language is for,
you may not have too go into such detail.
Return to the
Search the comp.compilers archives again.