Marko Kreen <marko@l-t.ee> writes:
> 1) Precedence. I quite nonscientifically hacked in gram.y,
> and could not still make it understand expression '5 # ~1'
> nor the precedence between '&' and '|#'...
> At the moment all the gram.y changes could be dropped and
> it works ok, but without operator precedence. Any hints?
What you missed is that there's a close coupling between gram.y and
scan.l. There are certain single-character operators that are returned
as individual-character tokens by scan.l, and these are exactly the ones
that gram.y wants to treat specially. All else are folded into the
generic token "Op". You'd need to twiddle the character type lists in
scan.l if you want to treat '~' '&' or '#' specially in gram.y.
However, I'm pretty dubious of the idea of changing the precedence
assigned to these operator names, because there's a real strong risk
of breaking existing applications if you do that --- worse, of breaking
them in a subtle, hard-to-detect way. Even though I think '|' is
clearly given a bogus precedence, I doubt it's a good idea to change it.
> 3) Choice of operators. As I understand the '^' is taken,
> I wont get it. Now, in gram.y I found that the '|' is
> used in weird situations and with weird precedence so
> maybe I should use something else for OR too?
Well, you *could* use '^' since there's no definition of it for integer
operands. But that would mean that something like '4^2', which was
formerly implicitly coerced to float and interpreted as floating
power function, would suddenly mean something different. Again a
serious risk of silently breaking applications. This doesn't apply to
'|' though, since it has no numeric interpretation at all right now.
> 4) Is anybody else interested? ;)
Dunno. I think the bitstring datatype is probably a better choice,
since it's standard and this feature is not.
regards, tom lane
