Simen Kjaeraas wrote:
> On Thu, 18 Dec 2008 07:01:49 +0100, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> 
>> Walter wants pure functions that have no side effects *AND* cannot be
>> affected by other functions' side effects.  Your example fails the second
>> requirement.
> 
> I should have put that in there as well. My point was that a delegate
> /can be/ as pure as a normal function.

Right, but the compiler might have to take it on faith that the delegate is really pure.

On Thu, 18 Dec 2008 13:27:16 +0100, Christopher Wright <dhasenan@gmail.com> wrote:

> Simen Kjaeraas wrote:
>> On Thu, 18 Dec 2008 07:01:49 +0100, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>
>>> Walter wants pure functions that have no side effects *AND* cannot be
>>> affected by other functions' side effects.  Your example fails the second
>>> requirement.
>>  I should have put that in there as well. My point was that a delegate
>> /can be/ as pure as a normal function.
>
> Right, but the compiler might have to take it on faith that the delegate is really pure.

Which is why I said a cast might be necessary.

-- 
Simen

Simen Kjaeraas Wrote:

> On Thu, 18 Dec 2008 13:27:16 +0100, Christopher Wright <dhasenan@gmail.com> wrote:
> 
> > Simen Kjaeraas wrote:
> >> On Thu, 18 Dec 2008 07:01:49 +0100, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> >>
> >>> Walter wants pure functions that have no side effects *AND* cannot be
> >>> affected by other functions' side effects.  Your example fails the
> >>> second
> >>> requirement.
> >>  I should have put that in there as well. My point was that a delegate
> >> /can be/ as pure as a normal function.
> >
> > Right, but the compiler might have to take it on faith that the delegate is really pure.
> 
> Which is why I said a cast might be necessary.
> 
> -- 
> Simen

In fact I thought that a returned delegate with no side effect was inherently pure, because I thought the delegate was the only one to have access to its closure variables. In fact, as Simen showed, the closure can be shared between several delegates.

So if all delegates sharing the same closure have no side effect, can we say that they are all pure ?

"Christopher Wright" wrote
> Simen Kjaeraas wrote:
>> On Thu, 18 Dec 2008 07:01:49 +0100, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>
>>> Walter wants pure functions that have no side effects *AND* cannot be
>>> affected by other functions' side effects.  Your example fails the
>>> second
>>> requirement.
>>
>> I should have put that in there as well. My point was that a delegate /can be/ as pure as a normal function.
>
> Right, but the compiler might have to take it on faith that the delegate is really pure.

It depends on the delegate.

I'd say that a delegate that points to a closure, or stack frame, is inherently unpure.  However, a delegate that points to a class instance member function can be pure if the class instance is immutable.

The purity will be stored with the signature of the function (and therefore the type).  So normal casts should work in the case that you know what you are doing, but there can't be any way for the compiler to know to cast the stack frame to immutable.

What you could do is form a requirement that if any inner function of another function is marked as pure, then ALL inner functions must be marked as pure.  Then, at the moment you pass a delegate to one of those functions, or call one of those functions, all local data becomes immutable.  I don't see a lot of benefit to all that, but then again, I'm not really experienced with functional programming techniques.

-Steve

On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com> wrote:

> For me, V1.038 compiles my code but takes a really really really long
> time to do so.
>
> It now takes  1 min 20 secs for a full build, when it used to compile
> in 13 seconds.
> Forget the 60% slowdown from LDC -- this is 515% slower!
>
> (building with DSSS and tango)
>
> --bb
>

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden@gmail.com> wrote:
> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>
>> For me, V1.038 compiles my code but takes a really really really long time to do so.
>>
>> It now takes  1 min 20 secs for a full build, when it used to compile
>> in 13 seconds.
>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>
>> (building with DSSS and tango)
>>
>> --bb
>>
>
> I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?
>

I'd love to have an unnecessary import finder tool.  How does that work?

--bb

On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter@gmail.com> wrote:

> On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden@gmail.com> wrote:
>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>>
>>> For me, V1.038 compiles my code but takes a really really really long
>>> time to do so.
>>>
>>> It now takes  1 min 20 secs for a full build, when it used to compile
>>> in 13 seconds.
>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>
>>> (building with DSSS and tango)
>>>
>>> --bb
>>>
>>
>> I generally make all my imports private and run a command line tool that
>> strips unnecessary imports once in a while to minimize intermodular
>> dependencies. Maybe it could help in your case, too?
>>
>
> I'd love to have an unnecessary import finder tool.  How does that work?
>
> --bb

It's easy: remove an import and try if it still works :)
I recompile that file only and since all the imports are private, it generally doesn't break other files.

The only exception - templates. They aren't fully analyzed until instanciated and therefore some imports may be removed even if they are necessary. A simple tag prevents an import from removal:

private import std.algorithm; // force

Works about 3 minutes to remove all redundant imports from DWT.

Denis Koroskin escribió:
> On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
> 
>> On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden@gmail.com> wrote:
>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>>>
>>>> For me, V1.038 compiles my code but takes a really really really long
>>>> time to do so.
>>>>
>>>> It now takes  1 min 20 secs for a full build, when it used to compile
>>>> in 13 seconds.
>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>
>>>> (building with DSSS and tango)
>>>>
>>>> --bb
>>>>
>>>
>>> I generally make all my imports private and run a command line tool that
>>> strips unnecessary imports once in a while to minimize intermodular
>>> dependencies. Maybe it could help in your case, too?
>>>
>>
>> I'd love to have an unnecessary import finder tool.  How does that work?
>>
>> --bb
> 
> It's easy: remove an import and try if it still works :)
> I recompile that file only and since all the imports are private, it generally doesn't break other files.
> 
> The only exception - templates. They aren't fully analyzed until instanciated and therefore some imports may be removed even if they are necessary. A simple tag prevents an import from removal:
> 
> private import std.algorithm; // force
> 
> Works about 3 minutes to remove all redundant imports from DWT.

A problem with import removal in D is conditional compilation:

import foo;
import bar;

int lala() {
    version(FOO) {
        return somethingInModuleFoo();
    } else {
        return somethingInModuleBar();
    }
}

Now you need to compile your file twice, each time with a different version, and see if any import can be removed (in the example, if you remove foo, and FOO is not declared as a version, your file still compiles).

On Sat, Dec 20, 2008 at 10:01 PM, Denis Koroskin <2korden@gmail.com> wrote:
> On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>
>> On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden@gmail.com> wrote:
>>>
>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>>>
>>>> For me, V1.038 compiles my code but takes a really really really long time to do so.
>>>>
>>>> It now takes  1 min 20 secs for a full build, when it used to compile
>>>> in 13 seconds.
>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>
>>>> (building with DSSS and tango)
>>>>
>>>> --bb
>>>>
>>>
>>> I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?
>>>
>>
>> I'd love to have an unnecessary import finder tool.  How does that work?
>>
>> --bb
>
> It's easy: remove an import and try if it still works :)

Oh.  ok.  Well, removing things and trying to recompile is more or less what I do now.  That's not really what I'd call a "tool".  That's what I'd call "doing it manually".

--bb

Denis Koroskin wrote:
> On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
> 
>> I'd love to have an unnecessary import finder tool.  How does that work?
>>
>> --bb
> 
> It's easy: remove an import and try if it still works :)
> I recompile that file only and since all the imports are private, it generally doesn't break other files.
> 
> The only exception - templates. They aren't fully analyzed until instanciated and therefore some imports may be removed even if they are necessary. A simple tag prevents an import from removal:

Some more exceptions:
* http://d.puremagic.com/issues/show_bug.cgi?id=313 ("Fully qualified names bypass private imports")
* http://d.puremagic.com/issues/show_bug.cgi?id=314 ("Static, renamed, and selective imports are always public")