On Thursday, 14 March 2013 at 05:59:09 UTC, Maxim Fomin wrote:
> On Thursday, 14 March 2013 at 05:29:25 UTC, deadalnix wrote:
>> On Thursday, 14 March 2013 at 05:12:51 UTC, Maxim Fomin wrote:
>>> ABI, at least partly, is and should be part of the spec. Otherwise it has some of the C++ problems. And the point was not about ABI in a sense of adding piece of information to chapter in dlang.org, but about implementing compiler. I am not enthusiastic about most DIPs presented recently because 1) without Walter and Andrei approval 2) without somebody willing to implement it, DIP turns to be a paper intellect exercise and corresponding ideas defence in the forum.
>>>
>>
>> Timon Gehr and I are working on compiler. This isn't intellectual masturbation.
>
> And without significant usage it is a coding exercise or NIH syndrome. What is good in the compiler (brand new frontend?) relative to gdc/ldc/dmd? Why somebody would switch to it?
>

ldc/gdc/dmd all uses the same frontend. The frontend is not suitable to build static analysis tools, or any tool in general (code formater, ide support, repl, anything). It has many quirk, especially when you start mixing advanced features together.

In general, many people think that D suffer to be too much tied to one implementation.

>> As of ABI, it is right now insufficiently defined to have a situation different than C++'s.
>
> Yes, and this is a problem. But at least it does exists and covers some aspects.
>

If I had to specify it, I'd say that context and this parameter goes as first argument 100% of the time.

>>> The problem is that there is 1 qualifier in current syntax and two underlying objects.
>>
>> Exactly. And theses are using different (and opposite) rules for implicit casts.
>
> The perhaps should we move DIP in that direction too?

I'll edit it tonight.

On 03/14/2013 04:12 AM, deadalnix wrote:
> ...
>>
>
> It is a tempting idea, but do not work. Consider :
>
> void delegate() immutable a;
> const void delegate() b = a;
>
> This would be forbidden as covariance of function parameters and
> transitivity act in opposite directions.

Uh, why?

In my current opinion, it should be as follows:

void main(){
	void delegate()inout w;
	void delegate()immutable i;
	void delegate()const c;
	void delegate() m;
	void delegate()const inout wc;
	
	// The following cases should be disallowed:
	
	i=c; // there may be mutable references to context
	c=m; // m may modify context
	i=m; // m may modify context
	w=i; // cannot use immutable as const or mutable
	w=m; // cannot use mutable as immutable
	w=c; // cannot use const as immutable
	wc=m;// cannot use mutable as immutable
	wc=c;// wc will access context as const or immutable
	i=w; // inout could mean const or mutable
	c=w; // inout could mean mutable
	i=wc; // inout const could mean const

	// These should be allowed:
	
	c=i; // certainly const if only immutable data accessed
	c=wc;// certainly const if only const inout data accessed
	m=c; // just loses guarantees to caller
	m=i; // ditto
	m=w; // ditto
	m=wc;// ditto
	w=wc;// m=c, c=c and i=i are valid
	wc=i;// c=i and i=i are valid
	wc=w;// c=m is not valid, but does the same thing as c=c here
}

If you disagree with one of them, please demonstrate how to break the type system using the conversion, or argue why a conversion would be valid.

On Thursday, 14 March 2013 at 11:42:29 UTC, Timon Gehr wrote:
> On 03/14/2013 04:12 AM, deadalnix wrote:
>> ...
>>>
>>
>> It is a tempting idea, but do not work. Consider :
>>
>> void delegate() immutable a;
>> const void delegate() b = a;
>>
>> This would be forbidden as covariance of function parameters and
>> transitivity act in opposite directions.
>
> Uh, why?
>

This would be forbidden, according to the rule expressed in the post + transitivity guaranty. That is not the position I defend.

> In my current opinion, it should be as follows:
>
> void main(){
> 	void delegate()inout w;
> 	void delegate()immutable i;
> 	void delegate()const c;
> 	void delegate() m;
> 	void delegate()const inout wc;
> 	
> 	// The following cases should be disallowed:
> 	
> 	i=c; // there may be mutable references to context
> 	c=m; // m may modify context
> 	i=m; // m may modify context
> 	w=i; // cannot use immutable as const or mutable
> 	w=m; // cannot use mutable as immutable
> 	w=c; // cannot use const as immutable
> 	wc=m;// cannot use mutable as immutable
> 	wc=c;// wc will access context as const or immutable
> 	i=w; // inout could mean const or mutable
> 	c=w; // inout could mean mutable
> 	i=wc; // inout const could mean const
>
> 	// These should be allowed:
> 	
> 	c=i; // certainly const if only immutable data accessed
> 	c=wc;// certainly const if only const inout data accessed
> 	m=c; // just loses guarantees to caller
> 	m=i; // ditto
> 	m=w; // ditto
> 	m=wc;// ditto
> 	w=wc;// m=c, c=c and i=i are valid
> 	wc=i;// c=i and i=i are valid
> 	wc=w;// c=m is not valid, but does the same thing as c=c here
> }
>
> If you disagree with one of them, please demonstrate how to break the type system using the conversion, or argue why a conversion would be valid.

I do agree with you on that one. However, c=m may be ok, as nothing immutable can be muted. That is an open question.

inout don't make a lot of sense without return type. It needs to be ironed out in that regard. Very good list !

On Thursday, 14 March 2013 at 11:42:29 UTC, Timon Gehr wrote:
> On 03/14/2013 04:12 AM, deadalnix wrote:
>> ...
>>>
>>
>> It is a tempting idea, but do not work. Consider :
>>
>> void delegate() immutable a;
>> const void delegate() b = a;
>>
>> This would be forbidden as covariance of function parameters and
>> transitivity act in opposite directions.
>
> Uh, why?
>
> In my current opinion, it should be as follows:
>
> void main(){
> 	void delegate()inout w;
> 	void delegate()immutable i;
> 	void delegate()const c;
> 	void delegate() m;
> 	void delegate()const inout wc;
> 	
> 	// The following cases should be disallowed:
> 	
> 	i=c; // there may be mutable references to context
> 	c=m; // m may modify context
> 	i=m; // m may modify context
> 	w=i; // cannot use immutable as const or mutable
> 	w=m; // cannot use mutable as immutable
> 	w=c; // cannot use const as immutable
> 	wc=m;// cannot use mutable as immutable
> 	wc=c;// wc will access context as const or immutable
> 	i=w; // inout could mean const or mutable
> 	c=w; // inout could mean mutable
> 	i=wc; // inout const could mean const
>
> 	// These should be allowed:
> 	
> 	c=i; // certainly const if only immutable data accessed
> 	c=wc;// certainly const if only const inout data accessed
> 	m=c; // just loses guarantees to caller
> 	m=i; // ditto
> 	m=w; // ditto
> 	m=wc;// ditto
> 	w=wc;// m=c, c=c and i=i are valid
> 	wc=i;// c=i and i=i are valid
> 	wc=w;// c=m is not valid, but does the same thing as c=c here
> }
>
> If you disagree with one of them, please demonstrate how to break the type system using the conversion, or argue why a conversion would be valid.

DIP updated.

The loss of information in cases like m=i causes problem when the copy or the destruction of the context isn't trivial.

Cases like c=m must be enabled as they will happen anyway by transitivity (or we must prevent delegate call when the type qualifier is changed via transitivity which seem worse to me).

inout const isn't a valid type qualifier so I dropped it.

On 03/14/2013 06:59 AM, Maxim Fomin wrote:
> On Thursday, 14 March 2013 at 05:29:25 UTC, deadalnix wrote:
>> On Thursday, 14 March 2013 at 05:12:51 UTC, Maxim Fomin wrote:
>>> ABI, at least partly, is and should be part of the spec. Otherwise it
>>> has some of the C++ problems. And the point was not about ABI in a
>>> sense of adding piece of information to chapter in dlang.org, but
>>> about implementing compiler. I am not enthusiastic about most DIPs
>>> presented recently because 1) without Walter and Andrei approval 2)
>>> without somebody willing to implement it, DIP turns to be a paper
>>> intellect exercise and corresponding ideas defence in the forum.
>>>
>>
>> Timon Gehr and I are working on compiler. This isn't intellectual
>> masturbation.
>
> And without significant usage it is a coding exercise or NIH syndrome.

There's a significant amount of easy-to-implement language features missing.

> What is good in the compiler (brand new frontend?) relative to
> gdc/ldc/dmd? Why somebody would switch to it?
>

I do not care whether someone switches to it, but the plan is:

* Diagnostics
  - Nicely formatted: Yes.
  - Useful diagnostics for template instantiation failures: TODO

* CTFE
  - Working: Yes (eg: full support for closures.)
  - Fast: Partly done. (the implementation is not as horribly slow as DMD's.)

* Sane and well-defined treatment of complex analysis dependencies.
  - Makes sure that is-expressions are consistent and unambiguous
    throughout compilation.
  - To the point diagnostics.
  - dlang.org spec and DMD frontend fundamentally broken in this regard.
  - Mostly works already.

* Complete independence of compiler backend
  - (In fact, there is no backend yet, CTFE is sufficient for testing.)

* Easy-to-use minimal wrapper library
  - Enabling frameworks for program analysis.
  - Simple plugging of custom back ends.
  - Not done yet.

* Using the front end in a code editor
  - Incremental compilation. (Change only code gen of the function that
    was last accessed.
  - Display of semantic information.
  - Not done yet. (But the design of the front end will
    support such endeavours nicely.)

* Short to-the-point code. Written in D.

> ...

On 03/14/2013 04:41 PM, deadalnix wrote:
> ...
>
> DIP updated.
>

Using a vastly different set of allowed/disallowed cases. Every delegate type must implicitly convert to unqualified. Otherwise attribute inference may break code that would be valid without.
(this has to work differently with explicitly-typed contexts, because those are not opaque.)

> The loss of information in cases like m=i causes problem when the copy
> or the destruction of the context isn't trivial.
>
> Cases like c=m must be enabled as they will happen anyway by
> transitivity (or we must prevent delegate call when the type qualifier
> is changed via transitivity which seem worse to me).
>

I favour neither, but your approach removes all guarantees on const.
(For the time being, my front end implements the parenthesized part.)

> inout const isn't a valid type qualifier so I dropped it.

I consider that a DMD bug.

On Thursday, 14 March 2013 at 16:01:28 UTC, Timon Gehr wrote:
> On 03/14/2013 04:41 PM, deadalnix wrote:
>> ...
>>
>> DIP updated.
>>
>
> Using a vastly different set of allowed/disallowed cases. Every delegate type must implicitly convert to unqualified. Otherwise attribute inference may break code that would be valid without.
> (this has to work differently with explicitly-typed contexts, because those are not opaque.)
>

Can you elaborate on that please ? I fail to see the problem.

> I favour neither, but your approach removes all guarantees on const.

Such guarantee can already be broken with aliasing so nothing new.

>> inout const isn't a valid type qualifier so I dropped it.
>
> I consider that a DMD bug.

What would be the semantic ?

14-Mar-2013 09:59, Maxim Fomin пишет:
> On Thursday, 14 March 2013 at 05:29:25 UTC, deadalnix wrote:
>> On Thursday, 14 March 2013 at 05:12:51 UTC, Maxim Fomin wrote:
>>> ABI, at least partly, is and should be part of the spec. Otherwise it
>>> has some of the C++ problems. And the point was not about ABI in a
>>> sense of adding piece of information to chapter in dlang.org, but
>>> about implementing compiler. I am not enthusiastic about most DIPs
>>> presented recently because 1) without Walter and Andrei approval 2)
>>> without somebody willing to implement it, DIP turns to be a paper
>>> intellect exercise and corresponding ideas defence in the forum.
>>>
>>
>> Timon Gehr and I are working on compiler. This isn't intellectual
>> masturbation.
>
> And without significant usage it is a coding exercise or NIH syndrome.
> What is good in the compiler (brand new frontend?) relative to
> gdc/ldc/dmd? Why somebody would switch to it?

Being fed up with 'the one and only' and 'the implementation is the reference' principle?

The more compilers we have - the better defined language standard we get. And the latter is a very good thing in its own right.


-- 
Dmitry Olshansky

14-Mar-2013 20:45, Timon Gehr пишет:
> On 03/14/2013 06:59 AM, Maxim Fomin wrote:
>> On Thursday, 14 March 2013 at 05:29:25 UTC, deadalnix wrote:
>>> On Thursday, 14 March 2013 at 05:12:51 UTC, Maxim Fomin wrote:
>>>> ABI, at least partly, is and should be part of the spec. Otherwise it
>>>> has some of the C++ problems. And the point was not about ABI in a
>>>> sense of adding piece of information to chapter in dlang.org, but
>>>> about implementing compiler. I am not enthusiastic about most DIPs
>>>> presented recently because 1) without Walter and Andrei approval 2)
>>>> without somebody willing to implement it, DIP turns to be a paper
>>>> intellect exercise and corresponding ideas defence in the forum.
>>>>
>>>
>>> Timon Gehr and I are working on compiler. This isn't intellectual
>>> masturbation.
>>
>> And without significant usage it is a coding exercise or NIH syndrome.
>
> There's a significant amount of easy-to-implement language features
> missing.
>
>> What is good in the compiler (brand new frontend?) relative to
>> gdc/ldc/dmd? Why somebody would switch to it?
>>
>
> I do not care whether someone switches to it, but the plan is:
>
> * Diagnostics
>    - Nicely formatted: Yes.
>    - Useful diagnostics for template instantiation failures: TODO
>
> * CTFE
>    - Working: Yes (eg: full support for closures.)
>    - Fast: Partly done. (the implementation is not as horribly slow as
> DMD's.)
>
> * Sane and well-defined treatment of complex analysis dependencies.
>    - Makes sure that is-expressions are consistent and unambiguous
>      throughout compilation.
>    - To the point diagnostics.
>    - dlang.org spec and DMD frontend fundamentally broken in this regard.
>    - Mostly works already.
>
> * Complete independence of compiler backend
>    - (In fact, there is no backend yet, CTFE is sufficient for testing.)
>
> * Easy-to-use minimal wrapper library
>    - Enabling frameworks for program analysis.
>    - Simple plugging of custom back ends.
>    - Not done yet.
>
> * Using the front end in a code editor
>    - Incremental compilation. (Change only code gen of the function that
>      was last accessed.
>    - Display of semantic information.
>    - Not done yet. (But the design of the front end will
>      support such endeavours nicely.)
>
> * Short to-the-point code. Written in D.
>

Dunno about others but I'm sold.
In fact, I was since I've first heard about it.


-- 
Dmitry Olshansky

On 03/14/2013 05:14 PM, deadalnix wrote:
> On Thursday, 14 March 2013 at 16:01:28 UTC, Timon Gehr wrote:
>> On 03/14/2013 04:41 PM, deadalnix wrote:
>>> ...
>>>
>>> DIP updated.
>>>
>>
>> Using a vastly different set of allowed/disallowed cases. Every
>> delegate type must implicitly convert to unqualified. Otherwise
>> attribute inference may break code that would be valid without.
>> (this has to work differently with explicitly-typed contexts, because
>> those are not opaque.)
>>
>
> Can you elaborate on that please ? I fail to see the problem.
>

int foo(int delegate() dg){ return dg(); }

void main(){
    foo(delegate()=>2); // error, int delegate()pure immutable
                        // does not convert to int delegate()
}


>> I favour neither, but your approach removes all guarantees on const.
>
> Such guarantee can already be broken with aliasing so nothing new.
>

Guarantees about const pure functions are lost. This is new. (Assuming a sound implementation.)

>>> inout const isn't a valid type qualifier so I dropped it.
>>
>> I consider that a DMD bug.
>
> What would be the semantic ?

It's just the combination of const and inout.
It behaves in the straightforward fashion.

inout is a wildcard standing for mutable, const or immutable.

inout is mutable   => const(inout) = const
inout is const     => const(inout) = const(const) = const
inout is immutable => const(inout) = const(immutable) = immutable

Hence const(inout) can be seen as a wildcard standing for const or immutable (but that's just derived information). Identifying const(inout) with const, as DMD does it, gratuitously loses type information.