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

[Jonathan Morgan]

On 3/6/06, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
>
> On Sun, Mar 05, 2006 at 12:36:43AM +1100, Jonathan Morgan wrote:
>
> > I do
> > not like the idea of any arbitrary word being an operator, as it would
> lessen
> > the readability of the code
>
> The problem is that most of the likely non-alphabetic ascii operators
> are taken.  And words as operators are quite readable.  Note, eg, the
> preference of if ... then ... else over ( -> ; ).


They can be readable - they can also be readable enough in English but not
particularly well expressed in English, meaning that you lose their
advantage, or find them misleading.
(->;) never really had much meaning anyway.  My best guess at what it meant
would have to be something like "a implies b then c", which is nothing like
its meaning.  If-then-else is also a little different because it's already a
construct in most languages.

I still see the advantage of having some good way of defining operators that
are separate from the rest of syntax, as this means you know you have to
look for a user-defined operator.

> I still think that user-defined operators lose most of their use if they
> cannot
> > be exported,
>
> Agreed.
>
> > but I believe exporting them is going to cause more trouble.
>
> Why?
>

Implementation-wise it's problematic, as was stated about a month ago: see
http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/mercury-developers.9907/0095.html
.
Since the Mercury developers do not seem to be interested in adding this
feature anyway, it is unlikely that they would make an implementation that
is likely to be problematic, or require a lot of work, or greatly increase
compilation time.

Would it be simpler to merely define operators as an alias for functions
(with precedence and associativity)? (eg. :- define_op(700, xfx, +++,myop),
where myop is some function).  Would this reduce any of the work on
generating interfaces and parsing, or not?

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20060306/18b67575/attachment.html>