On Thursday, 13 March 2014 at 22:37:32 UTC, Timon Gehr wrote:
> On 03/13/2014 08:52 PM, Andrei Alexandrescu wrote:
>>
>> Following a good recent history with bounty work on D-related projects
>> (especially GDC and LDC, congratulations!), Facebook is offering more
>> funds to spend on useful D-related issues. The one way to increase
>> investment in the area is to show that the current investment does
>> improve things.
>>
>> The sweet spot seems to be $250 per issue.
>>
>> This is one place where discussing and voting would be very sensible.
>> Please reply to this and/or vote on D issues on http://d.puremagic.com.
>
> What about fixing compile-time reflection?
>
> There is the notorious case
>
> static if(!is(typeof(e))) enum f = true;
> static if(!is(typeof(f))) enum e = true;
>
> and many like it. Sometimes, compilation of the same program where source files are passed on the command line in a different order influences the behaviour of the produced executable.

http://wiki.dlang.org/DIP31

On Friday, 14 March 2014 at 01:03:32 UTC, Andrei Alexandrescu
wrote:
> On 3/13/14, 5:51 PM, Mike wrote:
>> On Friday, 14 March 2014 at 00:46:09 UTC, Andrei Alexandrescu wrote:
>>>
>>> Fantastic. I raised the number of votes per user to 20.
>>>
>>> Andrei
>>
>> What about multiple votes per issue, so users can quantify the
>> importance of an issue relative to others?
>
> I'd be okay with allowing a user to manage voting budget as they find fit. What do others think?
>
> Andrei

Limited voting is good. You have to prioritize.

On Friday, 14 March 2014 at 01:01:12 UTC, Brad Roberts wrote:

> The main reason I didn't make any changes is there was no decided on policy for what to change it to.  I was fine with the 10 votes 1 per bug setting (and was a part of the long ago discussion that lead to that value).  A nebulous 'change it please' is a pointless bug report and I don't own the policy.

I'm sorry, I didn't mean that the way it probably sounded.  I provided justification for the change, so it wasn't nebulous.

I was only hoping to highlight the fact that the current policy owners have stated they would prefer to not have to worry about these trivial matters, yet haven't delegated authority and ownership of such policy so they don't have to.

On Friday, 14 March 2014 at 01:15:54 UTC, deadalnix wrote:

>
> Limited voting is good. You have to prioritize.

The proposal is not to take away the limitation.  It to allow users to spend more of their limited budget on a single issue to quantify its importance.

On 3/13/14, 6:04 PM, H. S. Teoh wrote:
> On Thu, Mar 13, 2014 at 05:46:29PM -0700, Andrei Alexandrescu wrote:
> [...]
>> Fantastic. I raised the number of votes per user to 20.
> [...]
>
> Only 20? :-(  I was hoping to vote on all AA bugs...

Don has protested in the past that too many votes blunt the statistics collected. I didn't agree with his argument, but he might have been up to something.

What would be a reasonable number?


Andrei

On 3/13/14, 6:15 PM, deadalnix wrote:
> On Friday, 14 March 2014 at 01:03:32 UTC, Andrei Alexandrescu
> wrote:
>> On 3/13/14, 5:51 PM, Mike wrote:
>>> On Friday, 14 March 2014 at 00:46:09 UTC, Andrei Alexandrescu wrote:
>>>>
>>>> Fantastic. I raised the number of votes per user to 20.
>>>>
>>>> Andrei
>>>
>>> What about multiple votes per issue, so users can quantify the
>>> importance of an issue relative to others?
>>
>> I'd be okay with allowing a user to manage voting budget as they find
>> fit. What do others think?
>>
>> Andrei
>
> Limited voting is good. You have to prioritize.

There's two: (a) votes per user, currently 20; (b) votes per user per issue, currently 1.

Andrei

On Thu, Mar 13, 2014 at 06:20:38PM -0700, Andrei Alexandrescu wrote:
> On 3/13/14, 6:04 PM, H. S. Teoh wrote:
> >On Thu, Mar 13, 2014 at 05:46:29PM -0700, Andrei Alexandrescu wrote: [...]
> >>Fantastic. I raised the number of votes per user to 20.
> >[...]
> >
> >Only 20? :-(  I was hoping to vote on all AA bugs...
> 
> Don has protested in the past that too many votes blunt the statistics collected. I didn't agree with his argument, but he might have been up to something.
> 
> What would be a reasonable number?
[...]

Hmm. Originally I would've said unlimited, but thinking about it again, I think he does have a point that having only a limited number forces you to consider more carefully which bugs are important to you. Maybe 50 would be a good upper limit? Past that point, it starts losing its meaning, since I doubt if many people have even read more than 50 bug reports on bugzilla.


T

-- 
Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert

On Friday, 14 March 2014 at 00:51:30 UTC, Mike wrote:
> On Friday, 14 March 2014 at 00:46:09 UTC, Andrei Alexandrescu wrote:
>>
>> Fantastic. I raised the number of votes per user to 20.
>>
>> Andrei
>
> What about multiple votes per issue, so users can quantify the importance of an issue relative to others?

Multiple votes per issue, combined with limited votes for person, leads to a bias where a newcomer will dump all their votes on one issue they find/create, whereas regulars will have a much more diluted effect on any single issue.

On 03/14/2014 02:14 AM, deadalnix wrote:
>>
>> What about fixing compile-time reflection?
>>
>> There is the notorious case
>>
>> static if(!is(typeof(e))) enum f = true;
>> static if(!is(typeof(f))) enum e = true;
>>
>> and many like it. Sometimes, compilation of the same program where
>> source files are passed on the command line in a different order
>> influences the behaviour of the produced executable.
>
> http://wiki.dlang.org/DIP31

"   3. A construct that may introduce unknown symbols.

The obvious feature of priority 2 is mixin, ..."

I think the explanation accidentally uses 0-based indexing.

"Any attempt to resolve a symbol will create a poison at the corresponding entry. ... Construct of priority 2 are evaluated in order of appearance in the source."

Order of appearance in the source is not well-defined. There can be circular imports. In any case, strategies dependent on declaration order at all do not result in predictable/flexible enough semantics in my opinion. One would need to reduce in parallel until analysis is completely stalled on lookups of unpoisoned symbols. Then one poisons all the stalled lookups in the topmost strongly connected component of the lookup-dependency-graph at once.

Eg. the following simple cases are easily seen to be completely unambiguous by this strategy:

// ----

static if(foo){ mixin("enum bar=true;"); }
mixin("enum foo=true;");

// ----

mixin(qux);
static if(foo.length){
    mixin("enum bar=true;");
    mixin(baz);
}
mixin("enum foo=baz;");
mixin("enum baz=`enum qux=q{enum fun=3;};`;");

static assert(fun==3);

The compiler should be able to resolve this.

Unfortunately this is not yet sufficient, eg. the following reasonably-looking case is not shown to be unambiguous by this strategy alone.

enum x = "enum xx = q{int y = 0;};";

struct SS{
    mixin(xx);
    mixin(x); // error, xx poisoned
}

On Friday, 14 March 2014 at 12:26:18 UTC, Timon Gehr wrote:
> "   3. A construct that may introduce unknown symbols.
>
> The obvious feature of priority 2 is mixin, ..."
>
> I think the explanation accidentally uses 0-based indexing.
>

You are right. I'm updating the DIP to make it 1 indexed.

> "Any attempt to resolve a symbol will create a poison at the corresponding entry. ... Construct of priority 2 are evaluated in order of appearance in the source."
>
> Order of appearance in the source is not well-defined. There can be circular imports. In any case, strategies dependent on declaration order at all do not result in predictable/flexible enough semantics in my opinion. One would need to reduce in parallel until analysis is completely stalled on lookups of unpoisoned symbols. Then one poisons all the stalled lookups in the topmost strongly connected component of the lookup-dependency-graph at once.
>

Order of inclusion only matter for symbol in socpe when compile time construct are present. They may introduce random symbols, it do not seems possible to make them independent of order in the source code in a paradox free manner. I have no proof of this, and I'd be happy to be proven wrong.

You are also right, they is an hole in the proposal when it comes to loop in module inclusion. I still think the proposal is a huge improvement over the current situation.

> Eg. the following simple cases are easily seen to be completely unambiguous by this strategy:
>
> // ----
>
> static if(foo){ mixin("enum bar=true;"); }
> mixin("enum foo=true;");
>
> // ----
>
> mixin(qux);
> static if(foo.length){
>     mixin("enum bar=true;");
>     mixin(baz);
> }
> mixin("enum foo=baz;");
> mixin("enum baz=`enum qux=q{enum fun=3;};`;");
>
> static assert(fun==3);
>
> The compiler should be able to resolve this.
>

I'm not sure what you think should happen as per my proposal here. Both module fail at the very first conditional :
static if(foo){ mixin("enum bar=true;"); } // priority 3, evaluate in order, foo doesn't exists. Error.
mixin(qux); // Same here, qux do not exists, error.

> Unfortunately this is not yet sufficient, eg. the following reasonably-looking case is not shown to be unambiguous by this strategy alone.
>
> enum x = "enum xx = q{int y = 0;};";
>
> struct SS{
>     mixin(xx);
>     mixin(x); // error, xx poisoned
> }

mixin are priority 2. mixin(xx) is processed first and is an error. If an xx string is defined somewhere (for instance in a imported module not present in the sample code) then mixin(x) becomes indeed an error, as it override the symbol xx, which would change the semantic of the previous mixin.