Compiler tool question

I'm a C programmer with no real background in parsing or compiler
design, and I'm slowly slogging through Holub's _Compiler Design in C_
and the documentation for Flex and Bison and other tools (notably
PRECCX). I'm working on some ideas for a language which will be
compiled to bytecode to be interpreted by a virtual machine. The
language is C-ish in syntax, but I'd like to give the user the ability
to overload existing operators and define new operators. I pretty much
understand how to handle the overloading of existing binary and unary
operators. The problem lies with defining new operators.


For new operators, the user will be able to choose characters from a
special operator character set (the usual C operator characters, plus
some extras) or alternatively give them names that follow the same
rules as any other variable or function identifier. I'd also like to
be able to define operators that consist of more than one token, like
the trinary "? :" operator in C, so that the following would be legal
(presuming all variables and operators had been defined beforehand):


put var1 into var2 using var3;


...where put..into..using is essentially a way of calling a function
like...


PutIntoUsing(var1, var2, var3);


Anyway, I can think of any number of ways to define function calls
disguised as "operators", but what I'm drawing a blank on is how to
write such things into a grammar for a parser generator. I get the
impression that there's no good way to do it with a LALR(1) parser,
which is why I'm picking through PRECCX's sparse documentation, but
I'm basically drawing a blank on how to dynamically define the
syntactic role of an identifier.


Can anyone give me a hint or direct me to some online documentation or
papers on the subject?


--Eric
[It's true, there's no reasonable way to modify a yacc grammar at runtime.
On the other hand, without a lot of work you can change the token values
your lexer returns. So one possibility is to build in extra parsing rules
with different precedence levels along the lines of
"expr: expr OPX expr" and then you can advise your lexer dynamically what
input token or tokens should turn into an OPX. Yes, this is a gross hack.
-John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.