View mode: basic / threaded / horizontal-split · Log in · Help
March 07, 2011
Re: Haskell infix syntax
On Mar 8, 11 05:13, Andrei Alexandrescu wrote:
> How about precedence?

They're not changeable[1] AFAIK.

OTOH, Haskell have the infix[rl]? declarations to allow users to 
customize the precedence (within a limited range of levels) and 
associativity of an operator.

Ref:
 [1] 
http://stackoverflow.com/questions/2922347/operator-precedence-in-scala
March 07, 2011
Re: Haskell infix syntax
On 2011-03-07 22:13, Andrei Alexandrescu wrote:
> On 3/7/11 5:05 AM, Jacob Carlborg wrote:
>> On 2011-03-07 01:10, Jonathan M Davis wrote:
>>> On Sunday 06 March 2011 10:03:05 Tomek Sowiński wrote:
>>>> bearophile bearophile napisał:
>>>>> Haskell is full of function calls, so the Haskell designers have
>>>>> used/invented several different ways to avoid some parenthesys in the
>>>>> code.
>>>>>
>>>>> From what I've seen if you remove some parenthesis well, in the right
>>>>> places, the resulting code is less noisy, more readable, and it has
>>>>> less
>>>>> chances to contain a bug (because syntax noise is a good place for
>>>>> bugs
>>>>> to hide).
>>>>>
>>>>> One of the ways used to remove some parenthesys is a standard syntax
>>>>> that's optionally usable on any dyadic function (function with two
>>>>> arguments):
>>>>>
>>>>> sum a b = a + b
>>>>>
>>>>> sum 1 5 == 1 `sum` 5
>>>>>
>>>>> The `name` syntax is just a different way to call a regular function
>>>>> with
>>>>> two arguments.
>>>>>
>>>>> In Haskell there is also a way to assign an arbitrary precedence and
>>>>> associativity to such infix operators, but some Haskell programmers
>>>>> argue that too much syntax sugar gives troubles (
>>>>> http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
>>>>>
>>>>> In D the back tick has a different meaning, and even if in D you use a
>>>>> different syntax, like just a $ prefix, I don't know how much good
>>>>> this
>>>>> syntax is for D:
>>>>>
>>>>> int sum(int x, int y) { return x + y; }
>>>>>
>>>>> int s = sum(1, sum(5, sum(6, sum(10, 30))));
>>>>> Equals to (associativity of $ is fixed like this):
>>>>> int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
>>>>>
>>>>> So I think it's not worth adding to D.
>>>>
>>>> I vaguely recall someone mentioned infixablility by naming convention.
>>>>
>>>> int _add_(int x, int y);
>>>>
>>>> int s = 1 _add_ 5 _add_ 10;
>>>>
>>>> As a feature of its own, it's just sugar. But if introducing infix
>>>> operators were contingent on banishing classic operator overloading,
>>>> then
>>>> it is worthwhile.
>>>
>>> LOL. And _what_ benefit would banishing classic operator overloading
>>> have? A
>>> function named add could be abused in _exactly_ the same ways that +
>>> can be.
>>
>> You could implement operator overloading without any special
>> cases/support in the language, like Scala does. In Scala
>>
>> 3 + 4
>>
>> Is syntax sugar for:
>>
>> 3.+(4)
>>
>> It's possible because of the following three reasons:
>>
>> * Everything is an object
>> * Method names can contain other characters than A-Za-z_
>> * The infix syntax discussed in this thread
>>
>> Implementing operator overloading like this also allows you to add new
>> operators and not just overloading existing ones.
>
> How about precedence?
>
> Andrei

It's basically determined by the first character in the name of the 
method. Associativity it determined by the last character in the name, 
if it ends with a colon it's right associative, otherwise left.

Have a look at: http://www.scala-lang.org/docu/files/ScalaReference.pdf 
6.12.3 InfixOperations

-- 
/Jacob Carlborg
March 07, 2011
Re: Haskell infix syntax
Jonathan M Davis napisał:

> > As a feature of its own, it's just sugar. But if introducing infix
> > operators were contingent on banishing classic operator overloading, then
> > it is worthwhile.  
> 
> LOL. And _what_ benefit would banishing classic operator overloading have?

I've worked on a financial system written in Java which used BigDecimal extensively. And, of course, I LOLed at that. But after having spent time with the code, a few benefits surfaced. It was clear which function was user-implemented. Displaying the docs by mousing over was nice too (outside the IDE grepping 'add' is easier than '+'). And above all, no abuse whatsoever. It all didn't outweigh the loss in terseness of syntax but did make up for some of it.

I'm bringing up this case because it's extremely in favour of operator overloading. Java is not big on number crunching and BigDecimal is one of the few spots on the vast programming landscape where overloaded operators make sense. And yet, the final verdict was: it doesn't suck.

> A function named add could be abused in _exactly_ the same ways that + can be.

There's far less incentive for abuse as there's no illusory mathematical elegance to pursue.

> The main benefit that infix syntax would provide would be if you had a variety of 
> mathematical functions beyond what the built in operators give you, and you want 
> to be able to treat them the same way. Whether classic operator overloading 
> exists or not is irrelevant.

That's mixing vect1 + vect2 with vect1 `dot` vect2. I'd rather see them treated the same way.

> Regardless, I don't think that adding infix syntax to the language is worth it. D 
> is already pretty complicated and _definitely_ more complicated than most 
> languages out there. One of the major complaints of C++ is how complicated it 
> is. We don't want to be adding extra complexity to the language without the 
> benefit outweighing that complexity, and I don't think that it's at all clear 
> that it does in this case.

I agree. Hence the idea of trading operator overloading for infixing. The added complexity is zero, if not less.

> As as KennyTM~ pointed out, if UFCS is ever 
> implemented, it gives you most of the benefit of this anyway, and there are 
> already a lot of people around here interested in UFCS. So, I find it _far_ more 
> likely that UFCS gets implemented than an infix function call syntax.

I also think it is more probable.

-- 
Tomek
March 07, 2011
Re: Haskell infix syntax
Caligo napisał:

> With C++, for example, Eigen uses expression templates.  How does one do
> expression templates in D? Could someone rewrite this
> http://en.wikipedia.org/wiki/Expression_templates this D?

You may look at my approach for QuantLibD.

http://dsource.org/projects/quantlibd/browser/ql/math/matrix.d

Mind you, project suspended.

-- 
Tomek
March 09, 2011
Re: Haskell infix syntax
On 07/03/11 01:01, Caligo wrote:
>
>
> On Sun, Mar 6, 2011 at 12:24 PM, Peter Alexander <peter.alexander.au
> <http://peter.alexander.au>@gmail.com <http://gmail.com>> wrote:
>
>     On 6/03/11 4:22 PM, bearophile wrote:
>
>             So I think it's not worth adding to D.
>
>
>         But if you don't agree... talk.
>
>         Bye,
>         bearophile
>
>
>     I agree.
>
>     It would be nice in some situations (like cross and dot products for
>     vectors), but otherwise it's unnecessary and just adds confusion in
>     exchange for a tiny but of convenience in a handful of scenarios.
>
>
>
> With C++, for example, Eigen uses expression templates.  How does one do
> expression templates in D? Could someone rewrite this
> http://en.wikipedia.org/wiki/Expression_templates this D?

>How does one do expression templates in D?

Same basic idea but it should be a lot saner because D metaprograming 
isn't a Turing tar pit like with C++. The return type of your function 
is a template encoding in types of the inputs. So you could define an + 
operator that has a return type of

opBinary(RHS,"+",LHS)

Or similar. The type of RHS and LHS could be other opBinary 
instansiations or a leaf time. Sooner or later you've got something that 
looks like a parse tree and you can process that at compile time using 
CTFE and then mixin the result. Heck, you might even be able to do 
something crazy like flatten the tree and re-parse and thus screw with 
the operator precedence or run your own specialized compiler backend and 
output inline asm.

Trouble is, each time I feel motivated to give this a go I run into 
compiler bugs. Hopefully things will get better soon.
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home