Tim Bunce writes:
: For perl at least I thought Larry has said that you'll be able to
: create new ops but only give them the same precedence as any one
: of the existing ops.
Close, but not quite. What I think I said was that you can't specify
a raw precedence--you can only specify a precedence relative to an
existing operator. That way it doesn't matter what the initial
precedence assignments are. We can always change them internally.
: Why not use a 16 bit int and specify that languages should use
: default precedence levels spread through the range but keeping the
: bottom 8 bits all zero. That gives 255 levels between '3' and '4'.
: Seems like enough to me!
:
: Floating point seems like over-egging the omelette.
It's also under-egging the omelette, and not just because you
eventually run out of bits. I don't think either integer or floating
point is the best solution, because in either case you have to remember
separately how many levels of derivation from the standard precedence
levels you are, so you know which bit to flip, or which increment to
add or subtract from the floater.
In an approach vaguely reminscent of surreal numbers, I'd just use a
string that does trinary ordering. Suppose you have 26 initial
precedence levels. Call these A-Z. Subsequent characters can just be
0-2. Skip A for the moment, call the lowest precedence level B, the
next lowest C, and so on.
* To make a new operator at the same precedence, simply copy the base
precedence string.
* To make a new operator at a higher precedence level, copy the base
precedence and append a "1" to it.
* To make a new operator at a lower precedence level, copy the base
precedence, decrement the last character (that's why we skipped A)
and append a "2".
This is now extensible to any number of precedence levels, and you can
now use simple string comparison to compare any two precedences. It even
short circuits the comparison as soon as it finds a character that
differs.
Gee, maybe I should patent this.
: p.s. I missed the start of this thread so I'm not sure why this is
: a parrot issue rather than a language one. I also probably don't
: know what I'm talking about :)
It's a language issue insofar as the language specifies that the
implementation should avoid arbitrary limits.
Larry
