<br><br><div><span class="gmail_quote">On 3/6/06, <b class="gmail_sendername">Peter Schachte</b> <<a href="mailto:schachte@csse.unimelb.edu.au">schachte@csse.unimelb.edu.au</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sun, Mar 05, 2006 at 12:36:43AM +1100, Jonathan Morgan wrote:<br><br>> I do<br>> not like the idea of any arbitrary word being an operator, as it would lessen<br>> the readability of the code<br><br>The problem is that most of the likely non-alphabetic ascii operators
<br>are taken.  And words as operators are quite readable.  Note, eg, the<br>preference of if ... then ... else over ( -> ; ).</blockquote><div><br>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.
<br>(->;) 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.
<br><br>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.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> I still think that user-defined operators lose most of their use if they cannot<br>> be exported,<br><br>Agreed.<br><br>> but I believe exporting them is going to cause more trouble.<br><br>Why?<br></blockquote>
</div><br>Implementation-wise it's problematic, as was stated about a month ago: see <a href="http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/mercury-developers.9907/0095.html">http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/mercury-developers.9907/0095.html
</a>.<br>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.
<br><br>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?
<br><br>Jon<br>