Le 06/08/2012 20:01, Mafi a écrit :
> This comes from the 'real' function type is 'void f()' whose usage is
> deprecated in D except for any function-/method-declaration:
> Imagine a C-style declaration of the fuction type and you'll come to the
> conclusion it's the way one defines functions in C/C++/D. But this type
> has a big quirk: it's variable length because different fuctions with
> the same signature can have a different amount of machine instuctions.

Well, foo is either that either a function call. When it is which is quite unclear.

> Therefore this can't be stored, passed or returned. You can't have array
> of them. The only exception is when you define a constant, then it's a
> funciton definition. Now because of this there is a need for another
> type equivalent to the function itself: its address. It's written 'void
> (*f)()' in C. This type is mostly reffered to as function even though
> it's only its address. Now D wants to go away from C declarations so the
> 'void function()' syntax was invented. Regardless of its name it's only
> the pointer to the actual functions even though D allows you to call it
> without dereferencing.
>

No dereferencing is done in the compiled code anyway. BTW, an « address of » operation is done on the type mentioned above.

>
> Maybe it is. But it comes from the fact that ufcs is an afterthought.
>

So we have already started to pill up feature that don't integrate with each other C++ style.

> I don't like authorative formal specs. It means most things are set in
> stone and you have to write a new spec every once in a while which slows
> down development of awesome language features.
>

This isn't about awesome language features. This is about function calls ! The most basic feature ever.

BTW, not stabilized feature shouldn't appear in what we call stable release . . . They should be provided testing versions of the compiler so they can be tortured and refined to the point everything make sense.

On Monday, 6 August 2012 at 18:29:38 UTC, deadalnix wrote:
> Le 06/08/2012 20:01, Mafi a écrit :
>> This comes from the 'real' function type is 'void f()' whose usage is
>> deprecated in D except for any function-/method-declaration:
>> Imagine a C-style declaration of the fuction type and you'll come to the
>> conclusion it's the way one defines functions in C/C++/D. But this type
>> has a big quirk: it's variable length because different fuctions with
>> the same signature can have a different amount of machine instuctions.
>
> Well, foo is either that either a function call. When it is which is quite unclear.

Well, I'd say it's quite clear. It always does what's explicitly written. The only exception is when one tries to do something except calling or address-taking with a function (not a function pointer).

>
> No dereferencing is done in the compiled code anyway. BTW, an « address of » operation is done on the type mentioned above.
>

I don't get what you are saying here. For me there's an inherent difference between a fuction and a function pointer. You shouldn't try to conflate them in a system language in my opinion.

>>
>> Maybe it is. But it comes from the fact that ufcs is an afterthought.
>>
>
> So we have already started to pill up feature that don't integrate with each other C++ style.

I have to admit one could say this. But there's definitly a big difference between real members and ufcs which would be really hard to design around if one wants to stay in the C family.

>> I don't like authorative formal specs. It means most things are set in
>> stone and you have to write a new spec every once in a while which slows
>> down development of awesome language features.
>>
>
> This isn't about awesome language features. This is about function calls ! The most basic feature ever.
>
> BTW, not stabilized feature shouldn't appear in what we call stable release . . . They should be provided testing versions of the compiler so they can be tortured and refined to the point everything make sense.

This isn't about versioning schemes either! But there have been long discussions recently and at least some things will change with the development after 2.060 afaik.

Le 06/08/2012 20:15, Timon Gehr a écrit :
>> To me, the first big failure of D to implement functional style is to
>> not have first class functions.
>
> Last time I checked, D still had closures. The 'first big failure of D
> to implement functional style' is the lack of most of the other
> features traditionally encountered in functional languages.
>

I mentioned first class function. Functions are not first class, you have to go throw & .

> Actually it is just that function declarations don't introduce symbols
> that are bound to values of the first class type.
>
> Try enum foo = (){};
>

That is what I mean when I say that function are not first class.

>
> &a.foo could be disallowed if foo is bound by UFCS.
>

It wouldn't be more consistent and would limit expressiveness.

> The formalisation can formalise the behaviour in a compatible or mostly
> compatible way. eg:
>
> a symbol that refers to a function (template) declaration can appear in
> some distinct contexts:
>
> 1. its address is taken
> 2. it is called
> 3. it is assigned to
> 4. none of the above
>
> In case 1:
> - If the function was looked up by UFCS, then this is the problematic
> case. Eg. just error out.
> - the address of expression will evaluate to a function pointer
> if the function is static and to a suitable delegate otherwise.
>
> In case 2:
> - Call.
>
> In case 3:
> - Call with the assigned expression.
>
> In case 4:
> - Rewrite to a call without parameters.
>
> Why would this be hard to implement?
>

Well it isn't straightforward, add @property into that and it become quite scary, now try to keep up with dmd that introduce changes into that process every release or so and you'll get my point.

>> Reading the @property thread, it seems that most people want to keep
>> dmd's current behavior. Because code rely on it. This make sense, but if
>> dmd's implement is the only goal, it means that other compiler are only
>> to be reverse engineering dmd's behavior, and are guaranteed to lag
>> behind. Considering this, I seriously wonder if it make sense to even
>> try to follow dmd's behavior and decide whatever seems the right one
>> when writing a D compiler, which will result in community split, or no
>> alternative compiler produced for D.
>>
>
> I think this is blown out of proportion.
>

As you say :

>
> That is inevitable if there is only one front end implementation and no
> formal specification.

The function call mess is one aspect.

Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
> On 08/06/2012 07:20 PM, Christophe Travert wrote:
>>
>> What do you think?
> 
> Creating byzantine language rules to cater to unimportant or non-existent use cases will slaughter the language.

What exactly do you consider byzantine here, whatever that means? Implicit cast is an already defined feature. Clarifying the way parenthesis-less function calls exist by adding a casting rule is making the langage more simple IMHO, and might improve the current position. Of course, if your point is that parenthesis-less function calls are unimportant or non-existent, then I understand your point of view, but other people seems to think differently.

-- 
Christophe

Le 06/08/2012 21:07, Mafi a écrit :
>> No dereferencing is done in the compiled code anyway. BTW, an «
>> address of » operation is done on the type mentioned above.
>>
>
> I don't get what you are saying here. For me there's an inherent
> difference between a fuction and a function pointer. You shouldn't try
> to conflate them in a system language in my opinion.
>

On any hardware, a function call will boil down to set up stuff on the stack and branching, jumping, calling or whatever on the ADDRESS of the function's code.

In other term, what is generated always involve the function's instruction address. If you dereference that address, you get instructions, but that hardly something useful to have at higher levels because you can"t do anything with it anyway.

>>>
>>> Maybe it is. But it comes from the fact that ufcs is an afterthought.
>>>
>>
>> So we have already started to pill up feature that don't integrate
>> with each other C++ style.
>
> I have to admit one could say this. But there's definitly a big
> difference between real members and ufcs which would be really hard to
> design around if one wants to stay in the C family.
>

Well D also advertise itself as OO and functional. Obviously, decision will have to be made. Because if no design decision is made, you ends up like it is now : micro decision are made when coding, and no overall is followed.

>>> I don't like authorative formal specs. It means most things are set in
>>> stone and you have to write a new spec every once in a while which slows
>>> down development of awesome language features.
>>>
>>
>> This isn't about awesome language features. This is about function
>> calls ! The most basic feature ever.
>>
>> BTW, not stabilized feature shouldn't appear in what we call stable
>> release . . . They should be provided testing versions of the compiler
>> so they can be tortured and refined to the point everything make sense.
>
> This isn't about versioning schemes either! But there have been long
> discussions recently and at least some things will change with the
> development after 2.060 afaik.
>

Yes, that was a digression. When stating that UFCS don't integrate nicely with other features, this showed the need for incubation of feature, and as recent discussions have been made on versioning, I made a bridge.

Le 06/08/2012 21:42, Christophe Travert a écrit :
> Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
>> On 08/06/2012 07:20 PM, Christophe Travert wrote:
>>>
>>> What do you think?
>>
>> Creating byzantine language rules to cater to unimportant or
>> non-existent use cases will slaughter the language.
>
> What exactly do you consider byzantine here, whatever that means?
> Implicit cast is an already defined feature. Clarifying the way
> parenthesis-less function calls exist by adding a casting rule is making
> the langage more simple IMHO, and might improve the current position. Of
> course, if your point is that parenthesis-less function calls are
> unimportant or non-existent, then I understand your point of view, but
> other people seems to think differently.
>

auto opDispatch(string name, T, U...)(T delegate() dg, U u) {
    mixin("return dg()." ~ name ~ "(u);");
}

I was thinking about something along that line instead of adding again more language feature.

But that really isn't that important. Being able to call or not without () isn't a that big deal. The mess created is.

On 08/06/2012 09:42 PM, Christophe Travert wrote:
> Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
>> On 08/06/2012 07:20 PM, Christophe Travert wrote:
>>>
>>> What do you think?
>>
>> Creating byzantine language rules to cater to unimportant or
>> non-existent use cases will slaughter the language.
>
> What exactly do you consider byzantine here, whatever that means?

byzantine means involved. Why deliberately make the language more
complicated for no gain whatsoever?

> Implicit cast is an already defined feature. Clarifying the way
> parenthesis-less function calls exist by adding a casting rule is making
> the langage more simple IMHO,

I don't know what to respond to this. Are you serious?

> and might improve the current position. Of
> course, if your point is that parenthesis-less function calls are
> unimportant or non-existent,

It isn't. My point is that there actually is no issue that would
require some complex solution.

> then I understand your point of view, but other people seems to think differently.
>

Le 06/08/2012 22:45, Timon Gehr a écrit :
> It isn't. My point is that there actually is no issue that would
> require some complex solution.
>

Actually, we have a very complex solution with no issue. That is in itself, an issue, especially when that very complex solution isn't defined properly anywhere except in dmd's implementation.

On 08/06/2012 09:33 PM, deadalnix wrote:
> Le 06/08/2012 20:15, Timon Gehr a écrit :
>>> To me, the first big failure of D to implement functional style is to
>>> not have first class functions.
>>
>> Last time I checked, D still had closures. The 'first big failure of D
>> to implement functional style' is the lack of most of the other
>> features traditionally encountered in functional languages.
>>
>
> I mentioned first class function. Functions are not first class, you
> have to go throw & .
>
>> Actually it is just that function declarations don't introduce symbols
>> that are bound to values of the first class type.
>>
>> Try enum foo = (){};
>>
>
> That is what I mean when I say that function are not first class.
>

What I mean when I say that functions are not first class is that there
are no first class functions. If functions are not first class there
eg. is no built-in way to pass a function to another function or
lexical closure does not work. Basing the decision on whether '&' is
required in some places is not useful.


>> &a.foo could be disallowed if foo is bound by UFCS.
>
> It wouldn't be more consistent and would limit expressiveness.

It can as well be allowed, because fields/properties of 'a' can behave
in a similar way. I don't really see what kind of consistency you aim
to preserve though.

This consistency argument feels to me like complaining about the fact
that &a.method returns a delegate while &a.field returns a pointer and
&a.property fails with a not an lvalue error.

>> The formalisation can formalise the behaviour in a compatible or mostly
>> compatible way. eg:
>> ...
>> Why would this be hard to implement?
>>
>
> Well it isn't straightforward, add @property into that and it become
> quite scary,

It is a bunch of syntactic rewrite rules. How hard can it be?

> now try to keep up with dmd that introduce changes into
> that process every release or so

I don't expect that to be the case.

> and you'll get my point.
>

What is this point? This feature is quite small and should be easy
to add even after almost all of the analysis implementation is finished
without spending much attention to it.

>> class A { void B() {} }
>> auto a = new A().B();
>> // ^ semicolon expected following auto declaration, not '.'
>>
> Obviously. No clue what this snippet is trying to do.

Well I meant "int B() { return 0; }" of course. I think you deliberately miss the point.