Le 13/03/2012 12:02, Peter Alexander a écrit :
> On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
>> On 3/12/2012 1:08 AM, Martin Nowak wrote:
>>> What's wrong with auto-inference. Inferred attributes are only
>>> strengthening
>>> guarantees.
>>
>> Auto-inference is currently done for lambdas and template functions -
>> why? - because the function's implementation is guaranteed to be
>> visible to the compiler. For other functions, not so, and so the
>> attributes must be part of the function signature.
>
> Dumb question:
>
> Why not auto-infer when the function body is available, and put the
> inferred attributes into the automatically generated .di file?
>
> Apologies if I've missed something completely obvious.

That is exactly what I was thinking about.

On 13/03/12 03:05, Walter Bright wrote:
> On 3/12/2012 6:15 PM, Stewart Gordon wrote:
>> And what about toString?
>
> Good question. What do you suggest?

Why can't we just kill that abomination?

On Tue, 13 Mar 2012 01:40:08 +0100, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/12/2012 1:56 PM, Martin Nowak wrote:
>> It doesn't require all source code.
>> It just means that without source code nothing can be inferred and the
>> attributes fall back to what has been annotated by hand.
>
> Hello endless bug reports of the form:
>
> "It compiles when I send the arguments to dmd this way but not that way. dmd is broken. D sux."

Yeah, you're right. It would easily create confusing behavior.

On 3/13/12 6:02 AM, Peter Alexander wrote:
> On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
>> On 3/12/2012 1:08 AM, Martin Nowak wrote:
>>> What's wrong with auto-inference. Inferred attributes are only
>>> strengthening
>>> guarantees.
>>
>> Auto-inference is currently done for lambdas and template functions -
>> why? - because the function's implementation is guaranteed to be
>> visible to the compiler. For other functions, not so, and so the
>> attributes must be part of the function signature.
>
> Dumb question:
>
> Why not auto-infer when the function body is available, and put the
> inferred attributes into the automatically generated .di file?
>
> Apologies if I've missed something completely obvious.

Because in the general case functions call one another so there's no way to figure which to look at first.

Andrei

Le 13/03/2012 15:46, Andrei Alexandrescu a écrit :
> On 3/13/12 6:02 AM, Peter Alexander wrote:
>> On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
>>> On 3/12/2012 1:08 AM, Martin Nowak wrote:
>>>> What's wrong with auto-inference. Inferred attributes are only
>>>> strengthening
>>>> guarantees.
>>>
>>> Auto-inference is currently done for lambdas and template functions -
>>> why? - because the function's implementation is guaranteed to be
>>> visible to the compiler. For other functions, not so, and so the
>>> attributes must be part of the function signature.
>>
>> Dumb question:
>>
>> Why not auto-infer when the function body is available, and put the
>> inferred attributes into the automatically generated .di file?
>>
>> Apologies if I've missed something completely obvious.
>
> Because in the general case functions call one another so there's no way
> to figure which to look at first.
>
> Andrei

This problem is pretty close to garbage collection. Let's use pure as example, but it work with other qualifier too.

function are marked pure, impure, or pure given all function called are pure (possibly pure). Then you go throw all possibly pure function and if it call an impure function, they mark it impure. When you don't mark any function as impure on a loop, you can mark all remaining possibly pure functions as pure.

Le 13/03/2012 01:50, Walter Bright a écrit :
> On 3/12/2012 4:11 AM, deadalnix wrote:
>> For struct, we have inference,
>
> ? No we don't.
>

Ok my mistake. So why not dig in that direction ?

>> so most of the time attributes will correct.
>> const pure nothrow @safe are something we want, but is it something we
>> want to
>> enforce ?
>
> Yes, because they are referred to by TypeInfo, and that's fairly useless
> if it isn't const etc.

I always though that TypeInfo is a poor substitute for metaprograming and compile time reflexion.

On 13-03-2012 16:56, deadalnix wrote:
> Le 13/03/2012 01:50, Walter Bright a écrit :
>> On 3/12/2012 4:11 AM, deadalnix wrote:
>>> For struct, we have inference,
>>
>> ? No we don't.
>>
>
> Ok my mistake. So why not dig in that direction ?
>
>>> so most of the time attributes will correct.
>>> const pure nothrow @safe are something we want, but is it something we
>>> want to
>>> enforce ?
>>
>> Yes, because they are referred to by TypeInfo, and that's fairly useless
>> if it isn't const etc.
>
> I always though that TypeInfo is a poor substitute for metaprograming
> and compile time reflexion.

Yes, and in some cases, it doesn't even work right; i.e. you can declare certain opCmp and opEquals signatures that work fine for ==, >, <, etc but don't get emitted to the TypeInfo metadata, and vice versa. It's a mess.

-- 
- Alex

On 3/13/12 10:47 AM, deadalnix wrote:
> This problem is pretty close to garbage collection. Let's use pure as
> example, but it work with other qualifier too.
>
> function are marked pure, impure, or pure given all function called are
> pure (possibly pure). Then you go throw all possibly pure function and
> if it call an impure function, they mark it impure. When you don't mark
> any function as impure on a loop, you can mark all remaining possibly
> pure functions as pure.

Certain analyses can be done using the so-called worklist approach. The analysis can be pessimistic (initially marking all functions as not carrying the property analyzed and gradually proving some do carry it) or optimistic (the other way around). The algorithm ends when the worklist is empty. This approach is well-studied and probably ought more coverage in compiler books. I learned about it in a graduate compiler class.

However, the discussion was about availability of the body. A worklist-based approach would need all functions that call one another regardless of module. That makes the analysis interprocedural, i.e. difficult on large codebases.


Andrei

Le 13/03/2012 17:06, Andrei Alexandrescu a écrit :
> On 3/13/12 10:47 AM, deadalnix wrote:
>> This problem is pretty close to garbage collection. Let's use pure as
>> example, but it work with other qualifier too.
>>
>> function are marked pure, impure, or pure given all function called are
>> pure (possibly pure). Then you go throw all possibly pure function and
>> if it call an impure function, they mark it impure. When you don't mark
>> any function as impure on a loop, you can mark all remaining possibly
>> pure functions as pure.
>
> Certain analyses can be done using the so-called worklist approach. The
> analysis can be pessimistic (initially marking all functions as not
> carrying the property analyzed and gradually proving some do carry it)
> or optimistic (the other way around). The algorithm ends when the
> worklist is empty. This approach is well-studied and probably ought more
> coverage in compiler books. I learned about it in a graduate compiler
> class.
>
> However, the discussion was about availability of the body. A
> worklist-based approach would need all functions that call one another
> regardless of module. That makes the analysis interprocedural, i.e.
> difficult on large codebases.
>
>
> Andrei

I expect the function we are talking about here not to call almost all the codebase. It would be scary.

On Tue, Mar 13, 2012 at 11:06:00AM -0500, Andrei Alexandrescu wrote:
> On 3/13/12 10:47 AM, deadalnix wrote:
> >This problem is pretty close to garbage collection. Let's use pure as example, but it work with other qualifier too.
> >
> >function are marked pure, impure, or pure given all function called are pure (possibly pure). Then you go throw all possibly pure function and if it call an impure function, they mark it impure. When you don't mark any function as impure on a loop, you can mark all remaining possibly pure functions as pure.
> 
> Certain analyses can be done using the so-called worklist approach. The analysis can be pessimistic (initially marking all functions as not carrying the property analyzed and gradually proving some do carry it) or optimistic (the other way around). The algorithm ends when the worklist is empty. This approach is well-studied and probably ought more coverage in compiler books. I learned about it in a graduate compiler class.
[...]

I have an idea.

Instead of making potentially risky changes to the compiler, or changes with unknown long-term consequences, what about an external tool (or a new compiler option) that performs this analysis and saves it into a file, say in json format or something?

So we run the analysis on druntime, and it tells us exactly which functions can be marked pure, const, whatever, then we can (1) look through the list to see if functions that *should* be pure aren't, then investigate why and (possibly) fix the problem; (2) annotate all functions in druntime just by going through the list, without needing to manually fix one function, find out it breaks 5 other functions, fix those functions, find another 25 broken, etc..

We can also run this on phobos, cleanup whatever functions aren't marked pure, and then go through the list and annotate everything in one shot.

Now that I think of it, it seems quite silly that we should be agonizing over the amount of manual work needed to annotate druntime and phobos, when the compiler already has all the necessary information to automate most of the tedious work.


T

-- 
It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford