View mode: basic / threaded / horizontal-split · Log in · Help
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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?
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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
3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home