On 08/05/2015 07:12 PM, Max Samukha wrote:
> On Wednesday, 5 August 2015 at 15:58:28 UTC, Timon Gehr wrote:
>
>>> The point is that '+' for string concatenation is no more of an 'idiot
>>> thing' than '~'.
>>
>> My point is that it is. String concatenation is not commutative.
>
> Ok, good point. Except that '+' in a programming language is not the
> mathematical '+'.

It's obvious where the notation has been borrowed from.

> Why define '+' as strictly commutative operation and
> not more generally as an abstract binary operation,

Descriptive names do have some value.

> considering the middle dot is unavailable?

(It isn't.)

> Or, if we want to stick to the math notation,
> then '*' would be more appropriate than the idiot thing '~'.

That's a different discussion. '*' is certainly more appropriate than '+'. Anyway, I think it is sensible to use distinct names for distinct operations when they are used in the same system.

On 08/05/2015 07:32 PM, deadalnix wrote:
> On Wednesday, 5 August 2015 at 17:12:29 UTC, Max Samukha wrote:
>> On Wednesday, 5 August 2015 at 15:58:28 UTC, Timon Gehr wrote:
>>
>>>> The point is that '+' for string concatenation is no more of an 'idiot
>>>> thing' than '~'.
>>>
>>> My point is that it is. String concatenation is not commutative.
>>
>> Ok, good point. Except that '+' in a programming language is not the
>> mathematical '+'. Why define '+' as strictly commutative operation and
>> not more generally as an abstract binary operation, considering the
>> middle dot is unavailable? Or, if we want to stick to the math
>> notation, then '*' would be more appropriate than the idiot thing '~'.
>
> Nobody want to stay in the math world. Not that math are worthless, but
> it has this tendency to make simple things absurdly complex by requiring
> you to learn a whole area of math to understand the introduction.
>

I assume the set of examples you are generalizing this from has cardinality close to one? Anyway, it seems like an exaggeration.

> This is commonly referred as the monad curse: once you understand what a
> monad is, you loose all capacity to explain it.

I'm not buying it.

> In fact, Most developers
> have used some sort of monad, but only a very small portion know they
> were using one or can explain you what it is.
> ...

Which isn't surprising. This isn't a very useful name in their (quite specific) use cases.

> Mathematical language is geared toward generality and correctness, not
> practicality. That makes sens in the context of math, that do not in the
> context of every day programming.

I don't see what you are trying to get at here, but I guess it is almost entirely unrelated to choosing a notation for string concatenation.

On Wednesday, 5 August 2015 at 14:21:13 UTC, jmh530 wrote:
> On Wednesday, 5 August 2015 at 06:03:14 UTC, rsw0x wrote:
>>
>> This thread is really long so I didn't read all the posts. Sorry if this has been mentioned.
>
> Don't worry, I don't recall anybody talking about it. Nevertheless, plugins aren't unique to Rust: GCC and Clang allow plugins. Nevertheless, I think that the Rust C++ plugin you posted was cool. Reminds me of Rcpp.

Oh, it _is_ talked about a lot. Just normally called 'syntax extensions' (the most used aspect of the plugin system), so it _is_ used. Though because it relies on compiler internals everything released as a plugin is only usable on Nightly.

On Friday, 24 July 2015 at 21:44:42 UTC, Tofu Ninja wrote:
> But the part that I don't think makes sense for
>
>      auto a = {return 4;};
>
> to type "a" to a function pointer. I would expect {return 4;} to be treated as a function(not a function pointer). With it being treated as a function, I would expect it to be called with optional parens and type "a" to an int. I would expect auto
>
>       a = &{return 4;};
>
> to type "a" to a function pointer, which makes much more sense to me. But that's not how function literals work right now. Treating {return 4;} as a function(not a function pointer) makes a lot more sense and allows
>
>      alias a = {return 4;};
>
> to work as well, which is simply a function declaration.

Not crazy about your last point, TBH. Personally I really dislike function literals being _just_ `{ ... }` and as a matter of principle only write `(){...}` when I need one. `{}` to me can only mean blocks that are part of the current scope, but they're sometimes that and sometimes lambdas, depending on whether they had any `return`s and are in a place to be assigned a name or immediately called :/

A related thing is having _some way_ to quickly return a value from inside an invoked function literal without `return`. Somme stuff can't be done in a one-liner and need _two_(ish) lines and have to write, say, `{ Type myval, myres; res_by_ref(myval, myres); return myres; }()` instead of `{ Type myval, myres; res_by_ref(myval, myres); myres }` (expression-oriented) or `(){ ...; => myres; }()`(hypothetically). Point is, writing `return` in the middle of a function and having it return _only_ from a lambda breaks the flow, I believe, same as in C++.

On Wednesday, 5 August 2015 at 22:24:34 UTC, Enamex wrote:
>
> Oh, it _is_ talked about a lot. Just normally called 'syntax extensions' (the most used aspect of the plugin system), so it _is_ used. Though because it relies on compiler internals everything released as a plugin is only usable on Nightly.

I had been talking about this thread. You're right that there are a bunch of mentions on the forums (which I found after searching the term you list), but only two in the past day (including yours) on this thread.

On Wednesday, 5 August 2015 at 19:56:37 UTC, Timon Gehr wrote:
> On 08/05/2015 07:32 PM, deadalnix wrote:
>> Mathematical language is geared toward generality and correctness, not
>> practicality. That makes sens in the context of math, that do not in the
>> context of every day programming.
>
> I don't see what you are trying to get at here, but I guess it is almost entirely unrelated to choosing a notation for string concatenation.

Well, I don't think practicality is the main issue, but the mnemonic aspect of syntax is important.

It is not unreasonable to make the identity of operators/functions consist of both name and parameter types like in C++ and D. So you don't have "+" as the operator name, you have "+(int,int)" and "+(string,string)".

If one makes mathematical properties intrinsic to untyped part of the name then a lot of overloading scenarios break down e.g. for non-euclidean types.

It has been argued that functional languages would benefit from teaching functional programming in a less mathematical manner (e.g. talk about "callbacks" rather than "monads" etc):

https://youtu.be/oYk8CKH7OhE

On 8/2/2015 8:17 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com> wrote:
> It's a weird thing to do for a C-decendant as I would expect "~=" to do binary
> negation.

If you really felt this way, you'd expect the C != operator

  a != b

to be the same as:

  a = !b

On 8/3/2015 2:19 AM, Max Samukha wrote:
> The point is that '+' for string concatenation is no more of an 'idiot thing'
> than '~'.

Sure it is. What if you've got:

   T add(T)(T a, T b) { return a + b; }

and some idiot overloaded + for T to be something other than addition?

On Thursday, 6 August 2015 at 06:54:45 UTC, Walter Bright wrote:
> On 8/3/2015 2:19 AM, Max Samukha wrote:
>> The point is that '+' for string concatenation is no more of an 'idiot thing'
>> than '~'.
>
> Sure it is. What if you've got:
>
>    T add(T)(T a, T b) { return a + b; }
>
> and some idiot overloaded + for T to be something other than addition?

Having add("a", "b") return "ab" is not that weird. But consider this: http://pastebin.com/R3csc5Pa

I can't put it in dpaste because it doesn't allow threading, but here is an example output:

45
45
45
45
45
45
45
45
45
45
MyString("0361572489")
MyString("0379158246")
MyString("0369158247")
MyString("0582361479")
MyString("0482579136")
MyString("0369147258")
MyString("0371482569")
MyString("0469137258")
MyString("0369147258")
MyString("0561472389")

On Thursday, 6 August 2015 at 09:15:25 UTC, Idan Arye wrote:
> Having add("a", "b") return "ab" is not that weird. But consider this: http://pastebin.com/R3csc5Pa
>
> I can't put it in dpaste because it doesn't allow threading, but here is an example output:
>


This would just be an argument for having static typing through and through, or Rust traits…

If you wan't to address usability you have to look at what kind of problems people run into, not what they could construct if they tried really hard to create problems.