On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote: […]
> Does scala have arbitrary operators like Haskell? Looks useless in D. If you have an operator '+' that should not be pronounced 'plus' you are doing it wrong.

Yes.

	a + b

could be set union, logic and, string concatenation. The + is just a message to the LHS object, it determines what to do. This is the whole basis for DSLs.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 3 December 2013 at 12:41:40 UTC, Russel Winder wrote:
> On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
> […]
>> Does scala have arbitrary operators like Haskell? Looks useless in D. If you have an operator '+' that should not be pronounced 'plus' you are doing it wrong.
>
> Yes.
>
> 	a + b
>
> could be set union, logic and, string concatenation. The + is just a
> message to the LHS object, it determines what to do. This is the whole
> basis for DSLs.

Fully agree, I still cannot understand why so many people have
problems seeing operators as function calls with different set of
letters, like so many languages allow.

Maybe I've spent too much time with math at the uni. :)

--
Paulo

On Tuesday, 3 December 2013 at 12:18:32 UTC, bearophile wrote:
> Martin O.:
>>we should do something about operators. I like James Ward's idea to mandate an alphabetic alias for every operator - at least people would know how to pronounce them then.<
>
> Bye,
> bearophile

This is what was basically done with D1, all the operator overloading was name based so people know they were overloading 'add' and not 'concatenate.' Using the symbol wasn't legal. I don't think it will prevent people from doing what they want though so I don't see it necessary.

On Tuesday, 3 December 2013 at 09:46:27 UTC, Paulo Pinto wrote:
> Sadly plain C and C++ compilers are what most young developers know as AOT compilers, hence the spread of slow compilation message.
>
> --
> Paulo

I don't think that is limited to young developers. The only difference is that older developers are already comfortable programming in C/C++.

On Tuesday, 3 December 2013 at 14:25:50 UTC, Paulo Pinto wrote:
> On Tuesday, 3 December 2013 at 12:41:40 UTC, Russel Winder wrote:
>> On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:

> Maybe I've spent too much time with math at the uni. :)

You mean std.uni? Seriously, let's change that name into std.unicode. std.uni it is just laughable (yes, flames, flames) and tells, well, nothing.

eles:

> You mean std.uni? Seriously, let's change that name into std.unicode.

I think he meant "Unicorn".

Bye,
bearophile

On Tuesday, 3 December 2013 at 12:41:40 UTC, Russel Winder wrote:
> On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
> […]
>> Does scala have arbitrary operators like Haskell? Looks useless in D. If you have an operator '+' that should not be pronounced 'plus' you are doing it wrong.
>
> Yes.
>
> 	a + b
>
> could be set union, logic and, string concatenation. The + is just a
> message to the LHS object, it determines what to do. This is the whole
> basis for DSLs.


I really have no problem with operator overloading, but set union (∪), logic and (∧) and string concatenation (∘) do have well defined and commonly used symbols.

I would not argue against adding these to the language via a general mechanism and indeed then it might be useful to have a name for a user defined wtf-operator ?!?!. But if you overload an operator (+) it should be some kind of addition.

On 12/2/13 9:54 PM, Meta wrote:
> On Tuesday, 3 December 2013 at 03:06:20 UTC, Luís Marques wrote:
>> On Tuesday, 3 December 2013 at 00:36:32 UTC, Andrei Alexandrescu wrote:
>>> http://www.reddit.com/r/programming/comments/1rvltx/scala_1_would_not_program_again/#new
>>>
>>
>> I think he might not have liked D either:
>>
>>> This leads to ridiculous decisions such as using ~ to glue handlers
>>> together in the flexible DSL offered by spray
>>
>> ;-)
>
> I don't think this author is used to working with strongly-typed
> languages or languages with lower-level features:
>
> "And while I’m on the topic, thanks for making me care about the
> difference between long and int, again. It’s been far too long since I
> wrote C."
>
> I think he might've had a lot of the same criticisms for D as he did for
> Scala (save the build times. D's a real winner there).

He would at least to the extent a motivated and talented programmer could put together a rant against every language out there.

On the other hand Walter has been adamantly against configurable syntax (and talked me into that stance as well), so D is immune from quite a few issues pointed by that rant. D code is readable at least at surface level without needing context.

Also, the way D types work is quite a bit simpler so quite a few of the odd cases don't appear by design. I have this thought that D has offloaded to CTFE and Boolean logic a bunch of tasks that people achieve with complicated type-based proofs in Haskell or Scala. I think that's the real winner but time will tell.


Andrei

On 12/3/13 4:41 AM, Russel Winder wrote:
> On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
> […]
>> Does scala have arbitrary operators like Haskell? Looks useless
>> in D. If you have an operator '+' that should not be pronounced
>> 'plus' you are doing it wrong.
>
> Yes.
>
> 	a + b
>
> could be set union, logic and, string concatenation. The + is just a
> message to the LHS object

or RHS :o).


Andrei

On 12/3/2013 11:41 AM, Andrei Alexandrescu wrote:
> On the other hand Walter has been adamantly against configurable syntax (and
> talked me into that stance as well), so D is immune from quite a few issues
> pointed by that rant. D code is readable at least at surface level without
> needing context.
>
> Also, the way D types work is quite a bit simpler so quite a few of the odd
> cases don't appear by design. I have this thought that D has offloaded to CTFE
> and Boolean logic a bunch of tasks that people achieve with complicated
> type-based proofs in Haskell or Scala. I think that's the real winner but time
> will tell.

I also think it's abundantly clear that we hit a home run by making compile speed a priority since the beginning.