> > ... then @autoconf me harder@ could be used as the start and
> > ending token,
>
> Hm, I should have read your message more carefully --- I missed the
> bit at the middle where you propose nearly the same idea I had ;-).
> But the flex patterns you wrote don't actually support this do they?
They support both your original idea of "$$FOO\n" and "$FOO$" as
tokens.
> > @(@[^\n]+\n|[^@]*@)
> > %(%[^\n]+\n|[^%]*%)
> > $($[^\n]+\n|[^$]*$)
>
> Doesn't quite seem to do what we're talking about here.
The only reason I listed all three is I don't believe that there would
be any more lexical ambiguity than with any of the other operators.
scan.l, line 195:
op_chars [\~\!\@\#\^\&\|\`\?\+\-\*\/\%\<\>\=]
At line 428 in scan.l, include:
\@[\^\n\@]*\@ { /* Will take lexical precedence over {operator} */ }
And that should be the end of it since this new token returns a
string, just the same way that ' does, but without any escaping done.
> I don't see a need for three of these; that just eats up lexical
> token space. Is there a reason for the $ variant not to be enough?
Nope, no reason why it isn't enough. $ is just as valid as any of the
other characters. In my mind, since @ has a more limited use than $
in a global context (perl, shell, ruby), I figure its use to be safer
than @, even though PostgreSQL uses @ for abs (rarely seen in the wild
from my experience, and has a lower match precedence in flex).
> In any case, @ and % are valid (and popular) operator names in
> Postgres, so we could not use them for this purpose without removing
> that meaning, which would be painful.
Really? Hrm, guess @'s out. $ works for me.
-sc
--
Sean Chittenden
