[m-dev.] 0.13 release: op/3 syntax

Mark Brown mark at cs.mu.OZ.AU
Fri Mar 3 15:28:44 AEDT 2006

On 03-Mar-2006, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> On Fri, Mar 03, 2006 at 02:10:15PM +1100, Ralph Becket wrote:
> > Of course, it's even easier if you think of a textual name and stick
> > with the usual convention...
> Perhaps Mercury's designers should do the same?  The langauge is chock
> full of extra little bits of syntax for this or that, all of which
> make programming easier at the cost of complicating the language.  As
> many as possible of these should be defined in the library.  The lack
> of syntax extension and program transformation (cf term_expansion/2)
> facilities in Mercury mean they all have to be wired into the
> language.  Some examples:
> 	@ syntax in pattern matching
> 	named field declaration and accessor and setter syntax
> 	state variables
> 	DCGs
> I'm sure there are more; I just found these by looking at the built-in
> op list (a huge list!).  How much simpler would the language be if
> these parts were part of the library instead of the langauge?

The operator table is both a part of the library _and_ a part of the
language.  The compiler is a program that that reads Mercury terms, but
it doesn't have to be the only one.

What you are talking about is making the operator table part of the
*program*.  (In fact, that should be operator table_s_, since there can
be more than one for any given program.)

> My point is the Mercury language designers feel no compunction about
> introducing new operators.

Yes we do... but not to the extent of sticking to ISO Prolog builtin
operators, for example.

> Why deny the same flexibility to users?

Beside the point.  The debate is not about what should go in the builtin
operator table, but whether there should be one fixed operator table that
is part of the language, or multiple operator tables co-existing.


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