On 07/14/2014 05:29 PM, Dicebot wrote:
> On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
>> On 07/14/2014 11:55 AM, Dicebot wrote:
>>> I must admit D is far from perfect in that regard because operator
>>> overloading is still not limited enough
>>
>> There is no real point in limiting it at all. It is just a matter of
>> naming your functions properly.
>>
>> auto subtract(int a, int b){ return a+b; }
>
> Same principle of surprise minimization. Reader expects arbitrary
> actions done by function call.

No way.

> Reader expects arithmetical semantics

Right, arithmetical semantics, which for built-in '+' can reach from wrap-around behaviour to saturated behaviour which is not even associative. Knowing what '+' does without being very aware what types its operands are is a pipe dream.

> from arithmetical operations.

'+' is opBinary!"+" and it is just another function name. There don't need to be 'anti-abuse' mechanics in place for this name and not for others.

> I don't see "you can change anything"

D does not allow you to e.g. redefine what the built-in operators do on built-in types, so where is this complaint coming from?

> language working for any large team production.

Languages that do not make built-in operators syntactically special are way better off regarding this issue because this way the question of automatically limiting implementations to match naming is even more obviously pointless. In any case, what are you arguing against here? Lexical scoping? Named definitions? Module systems? :o)

On Monday, 14 July 2014 at 16:10:54 UTC, Ary Borenszweig wrote:
> Making macros look like regular function calls, that you might not like. For me, it makes the code more readable. Instead of this:
>
> class Foo
>   mixin(property :foo)
> end
>
> Or this:
>
> class Foo
>   property!(:foo)
> end
>
> You simple write this:
>
> class Foo
>   property :foo
> end
>
> And it's super clear to everyone what this does (again: or read the docs or check the source code to see what this does).

Well as soon as it has own unique syntax it is not what I call "silent". Though `mixin` is much more notable than single : symbol but that is less of an issue.

This is exactly the point where I consider mixins + AST relfection functionally equivalent to macros.

On Monday, 14 July 2014 at 16:10:59 UTC, Timon Gehr wrote:
>> Same principle of surprise minimization. Reader expects arbitrary
>> actions done by function call.
>
> No way.

?

>> Reader expects arithmetical semantics
>
> Right, arithmetical semantics, which for built-in '+' can reach from wrap-around behaviour to saturated behaviour which is not even associative. Knowing what '+' does without being very aware what types its operands are is a pipe dream.

I don't mean low level semantics, just very simple "this adds two numbers" semantics - something you can ignore and abuse in D (though I don't know if it is even possible to define such constraints reasonably)

>> from arithmetical operations.
>
> '+' is opBinary!"+" and it is just another function name. There don't need to be 'anti-abuse' mechanics in place for this name and not for others.

Do you like boost::spirit? :)

>> I don't see "you can change anything"
>
> D does not allow you to e.g. redefine what the built-in operators do on built-in types, so where is this complaint coming from?

D is decent language in that regard - I am speaking about imaginary language that does not constraint any semantics and provides perfect expressive power.

> Languages that do not make built-in operators syntactically special are way better off regarding this issue because this way the question of automatically limiting implementations to match naming is even more obviously pointless.

You do realize this statement creates self-referential cycle and is thus pointless? :)

> In any case, what are you arguing against here? Lexical scoping? Named definitions? Module systems? :o)

macros that can't be recognized as macros at call site based on pure syntax

"Dicebot"  wrote in message news:luounykqutytridryekt@forum.dlang.org... 

> D is decent language in that regard - I am speaking about imaginary language that does not constraint any semantics and provides perfect expressive power.

Forth is not an imaginary language.

On Monday, 14 July 2014 at 17:48:12 UTC, Daniel Murphy wrote:
> Forth is not an imaginary language.

Ah, Forth, a language so terse that you don't edit files, but screens. Quite expressive indeed, remember waiting in line behind some dude hijacking printer for raytracing in postscript... ;)

On Monday, 14 July 2014 at 16:46:08 UTC, Dicebot wrote:
> On Monday, 14 July 2014 at 16:10:54 UTC, Ary Borenszweig wrote:
>> Making macros look like regular function calls, that you might not like. For me, it makes the code more readable. Instead of this:
>>
>> class Foo
>>  mixin(property :foo)
>> end
>>
>> Or this:
>>
>> class Foo
>>  property!(:foo)
>> end
>>
>> You simple write this:
>>
>> class Foo
>>  property :foo
>> end
>>
>> And it's super clear to everyone what this does (again: or read the docs or check the source code to see what this does).
>
> Well as soon as it has own unique syntax it is not what I call "silent". Though `mixin` is much more notable than single : symbol but that is less of an issue.
>
> This is exactly the point where I consider mixins + AST relfection functionally equivalent to macros.

Seeing as good ast reflection would form part of any ast macro system, perhaps everyone could agree to focus on designing the reflection syntax/semantics first, whether or not they ultimately want a macro system too.

On 7/14/14, 2:48 PM, Daniel Murphy wrote:
> "Dicebot"  wrote in message news:luounykqutytridryekt@forum.dlang.org...
>> D is decent language in that regard - I am speaking about imaginary
>> language that does not constraint any semantics and provides perfect
>> expressive power.
>
> Forth is not an imaginary language.

I can't seem to learn anything about this language without paying first.

On Monday, 14 July 2014 at 18:58:58 UTC, Ary Borenszweig wrote:
> I can't seem to learn anything about this language without paying first.

Not much to learn, it is kinda like stack-based assembly, but useful knowledge if you want to generate Postscript. GNU appears to have a free version:

http://www.gnu.org/software/gforth/

"Ary Borenszweig"  wrote in message news:lq199i$1312$1@digitalmars.com...

> I can't seem to learn anything about this language without paying first.

http://en.wikipedia.org/wiki/Forth_(programming_language)

It allows you to edit syntax as you go!

1 2 3 + + . (prints 6)
: 1 2 ;
: 2 3 ;
1 2 3 + + . (prints 8)
: + * ;
1 2 3 + + . (prints 18)

It even allows defining new control structures.  Every program is a new dsl. Too much freedom is a bad thing.