Operator precedence

[mepcotterell]

Is there any way to define operator precedence or fixity in DSL's implemented in scala? If not, are there any plans to?

[Randall R Schulz]

On Saturday February 12 2011, mepcotterell wrote:
> Is there any way to define operator precedence or fixity in DSL's
> implemented in scala? If not, are there any plans to?

Assuming your mean internal DSLs: No and almost certainly no.

The parser support in the Scala standard library handles external DSLs
well.

Randall Schulz

[mepcotterell]

Thanks for an answer and such a quick reply! And yes, I was talking about internal DSL's. 

[mepcotterell]

Why is there no plan to support precedence in user-defined operators? At the moment, it seems that all such operators have the same precedence.

[Daniel Sobral]

There's a fixed precedence of operators which can be found on the scala reference, on any book about Scala, and in many other places as a matter of fact.

Precedence is not user-defined because it makes the parser and the language more complex for a gain that was deemed unworthy the trouble.

On Wed, Feb 16, 2011 at 14:35, mepcotterell <mepcot...@gmail.com> wrote:

Why is there no plan to support precedence in user-defined operators? At the moment, it seems that all such operators have the same precedence.

--
Daniel C. Sobral

I travel to the future all the time.

[mepcotterell]

I've seen the list. I just asked the question because I thought it would make the creation of embedded DSL's a little easier.

[Jim Powers]

On Wed, Feb 16, 2011 at 4:26 PM, mepcotterell <mepcot...@gmail.com> wrote:
> I've seen the list. I just asked the question because I thought it would
> make the creation of embedded DSL's a little easier.

Parens? Usually works for me.

Imagine we could alter precedence and you read this line:

val x = foo + bar * baz

how would I visually interpret the line in the presence of alterable
operator precedence?

Just asking. I can actually see the argument going both ways. In the
end the compiler writers get to decide.

--
Jim Powers

[Philippe Lhoste]

On 16/02/2011 17:35, mepcotterell wrote:
> Why is there no plan to support precedence in user-defined operators? At the moment, it
> seems that all such operators have the same precedence.

Maybe I am misinterpreting your question, but user-defined operators (well, functions...)
do have precedence:

Scala Reference 6.12.3:
<<
An infix operator can be an arbitrary identifier. Infix operators have precedence and
associativity defined as follows:
The precedence of an infix operator is determined by the operator’s first character.
Characters are listed below in increasing order of precedence, with characters on the same
line having the same precedence.

(all letters)
|
^
&
< >
= !
:
+ -
* / %
(all other special characters)

That is, operators starting with a letter have lowest precedence, followed by operators
starting with ‘|’, etc.
>>
and more in the ref.

The nice advantage of this approach is that classical numerical operators keep their
precedence, and custom operators have precedence in a familiar (I agree with Jim here)
way. It is similar in C++ (where you can only overload existing operators): whatever the
meaning assigned to them, they keep their precedence. Overloaded operators can be
confusing (often less readable than functions, ie. words, if you don't know the doc),
altering precedences would bring even more confusion! ;-)

And it is elegant: I wonder how you would define precedences otherwise? Using a numerical
value with a special notation? Using a special expression ordering the operators in a
relative way?

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[Tony Morris]

On 17/02/11 21:22, Philippe Lhoste wrote:
> On 16/02/2011 17:35, mepcotterell wrote:
>> Why is there no plan to support precedence in user-defined operators?
>> At the moment, it
>> seems that all such operators have the same precedence.
>
> Maybe I am misinterpreting your question, but user-defined operators
> (well, functions...) do have precedence:
>

I think he means user-defined precedence. It's a common complaint that
will come up with any sufficiently robust API design.

--
Tony Morris
http://tmorris.net/

[Philippe Lhoste]

On 17/02/2011 12:25, Tony Morris wrote:
> I think he means user-defined precedence. It's a common complaint that
> will come up with any sufficiently robust API design.

I understood and I show you can define precedence for your operators... as long as you
stick to Ascii (at least for the first char).
Indeed, if you use Unicode dingbats ;-) for operators, you have to rely on parentheses.
Not necessarily a bad thing, not sure if it is obvious that ※ has a higher precedence than
⁂ unless you are very familiar with the API.

BTW, these symbols can be nice for mathematical-oriented APIs, but can be a nightmare for
the poor programmer having to copy/paste them or or to use IDEs to exploit the API (or to
use textual aliases, but loosing the advantage of symbolic notation then).

[Jimmy Zhang]

VTD-XML 2.10 is now released. It can be downloaded at
https://sourceforge.net/projects/vtd-xml/files/vtd-xml/ximpleware_2.10/.
This release includes a number of new features and enhancement.

* The core API of VTD-XML has been expanded. Users can now perform
cut/paste/insert on an empty element.
* This release also adds the support of deeper location cache support for
parsing and indexing. This feature is useful for application performance
tuning for
processing various XML documents.
* The java version also added support for processing zip and gzip files.
Direct processing of httpURL based XML is enhanced.
* Extended Java version now support Iso-8859-10~16 encoding.
* A full featured C++ port is released.
* C version of VTD-XML now make use of thread local storage to achieve
thread safety for multi-threaded application.
* There are also a number of bugs fixed. Special thanks to Jozef Aerts, John
Sillers, Chris Tornau and a number of other users for input and suggestions