[m-dev.] Re: user-defined operators

Fergus Henderson fjh at cs.mu.OZ.AU
Fri Jul 9 07:54:28 AEST 1999


On 09-Jul-1999, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> As Fergus pointed out, it's a bit tricky to get the interaction
> between ops and modules right.  OTOH, Mercury doesn't allow
> reexportation, so it's not *that* hard.  In fact, Fergus, why isn't it
> just a matter of making the interface-extraction code allow op
> declarations to be included into the .int file if they appear in the
> interface for a module?  I'd think that would handle public operators
> right.

Well, the current implementation reads in and parses one file at a time.
If op declarations can occur in interface files, then the parsing of the
main module would have to be interleaved with the parsing of the
interface files.  The compiler would also need to be able to save and
restore the state of the current operator table, because any operator
declarations in the main file should not affect the way that declarations
in the interface files are parsed.

Not a major problem, really, but not trivial either.

> I guess there is still the question of how to handle importation of
> two different modules that have incompatible operation declarations
> for the same symbol.  Since operators are used as the lexical level,
> before it's even known whether the symbol is a predicate, constructor,
> or whatever, much less what the argument types are, it would be
> impossible to use context to decide which of the conflicting op
> declarations for the symbol to apply, so that problem seems
> insurmountable.  But maybe that's forgivable, since user-defined
> operators are occasionally so useful.

One possible approach is to use a partial order rather than a total
order for the operator precedences.  Then, if you have an expression
such as `foo op1 bar op2 baz', and op1 and op2 have incomparable
precedences (this may be due to multiple declarations for the same operator,
or, if you allow partial orderings in the user-level syntax for declaring
operators, it could also be due to the user just not specifying their
relative precedences) the parser would require the user to insert explicit
parentheses.

> Are there any other hard problems?

Integrating operators with the module system in this way would make it
significantly more difficult to write programs that parse Mercury source
code, e.g. preprocessors.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list