Sönke Ludwig wrote:
> In my project compilation takes now several minutes for some files which compiled in about a second with 2.021. I stopped the compilation of the whole project after about 2 hours (took 2 min at most on 2.021).
> 
> I'll try to track this down when I get the time, but i doubt that those times get anywhere near those of the original.

Do you have modules that recursively import themselves, and instantiate a lot of templates?

On 2008-12-14 18:55:58 -0500, "Bill Baxter" <wbaxter@gmail.com> said:

> On Mon, Dec 15, 2008 at 7:43 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> Bill Baxter wrote:
>>> 
>>> On Mon, Dec 15, 2008 at 6:20 AM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>> 
>>>> Bill Baxter wrote:
>>>>> 
>>>>> On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok <daniel@nowhere.nospam>
>>>>> wrote:
>>>>>> 
>>>>>> On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:
>>>>>> 
>>>>>>>> Version D 1.038   Dec 11, 2008
>>>>>>>> New/Changed Features
>>>>>>>> * Added Partial IFTI Bugzilla 493
>>>>>>> 
>>>>>>> Hooray!  Now I can finish porting std.algorithm and friends to D1!
>>>>>> 
>>>>>> So, we'll see a new std2? :^) (I for one would be very happy)
>>>>> 
>>>>> Not a new std2, just updates to the old one.  But yeh.
>>>> 
>>>> Apologies for the delay in updating std2. I've had a good reason (in
>>>> addition to having a dissertation to complete), see www.erdani.org. :o)
>>> 
>>> I'm referring to this std2: http://www.dsource.org/projects/std2
>>> I think you're referring to std in v2 Phobos, but if you really are
>>> referring to std2 then I look forward to the updates.  ;-)
>>> 
>>> --bb
>> 
>> Sorry, I was indeed referring to std v2 in Phobos. I warn you guys, there's
>> going to be plenty of changes to std.algorithm.
> 
> With ranges and reference returns, I suspect so.  D2's added special
> support for foreach over ranges, right?  Is there anything else that
> had to change D2 in for ranges?
> 
> Anyway, my personal goal with D2 is not so much to facilitate
> compiling D2 code in D1, but more to just bring similar functionality
> to D1.  So if std2.algorithm gets stuck at today's rev because of
> porting issues, I can live with that.  But currently there is no
> functioning version std.algorithm at all in D1 because of the heavy
> use of partial IFTI with those string alias parameters.

Couldn't you use a double template?

	template doSomething(string predicate)
	{
		void doSomething(A)(a) { ... }
	}

Then call it like this:

	doSomething!("hello!")(5);

I'm using this trick at some places the D/Objective-C bridge.

Anyway, it's probably not worth the trouble anymore given that the latest DMD fixes the problem.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Tue, Dec 16, 2008 at 10:28 AM, Michel Fortin <michel.fortin@michelf.com> wrote:
> On 2008-12-14 18:55:58 -0500, "Bill Baxter" <wbaxter@gmail.com> said:
>
>> On Mon, Dec 15, 2008 at 7:43 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>> Bill Baxter wrote:
>>>>
>>>> On Mon, Dec 15, 2008 at 6:20 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>>>
>>>>> Bill Baxter wrote:
>>>>>>
>>>>>> On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok <daniel@nowhere.nospam> wrote:
>>>>>>>
>>>>>>> On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:
>>>>>>>
>>>>>>>>> Version D 1.038   Dec 11, 2008
>>>>>>>>> New/Changed Features
>>>>>>>>> * Added Partial IFTI Bugzilla 493
>>>>>>>>
>>>>>>>> Hooray!  Now I can finish porting std.algorithm and friends to D1!
>>>>>>>
>>>>>>> So, we'll see a new std2? :^) (I for one would be very happy)
>>>>>>
>>>>>> Not a new std2, just updates to the old one.  But yeh.
>>>>>
>>>>> Apologies for the delay in updating std2. I've had a good reason (in
>>>>> addition to having a dissertation to complete), see www.erdani.org. :o)
>>>>
>>>> I'm referring to this std2: http://www.dsource.org/projects/std2
>>>> I think you're referring to std in v2 Phobos, but if you really are
>>>> referring to std2 then I look forward to the updates.  ;-)
>>>>
>>>> --bb
>>>
>>> Sorry, I was indeed referring to std v2 in Phobos. I warn you guys,
>>> there's
>>> going to be plenty of changes to std.algorithm.
>>
>> With ranges and reference returns, I suspect so.  D2's added special support for foreach over ranges, right?  Is there anything else that had to change D2 in for ranges?
>>
>> Anyway, my personal goal with D2 is not so much to facilitate compiling D2 code in D1, but more to just bring similar functionality to D1.  So if std2.algorithm gets stuck at today's rev because of porting issues, I can live with that.  But currently there is no functioning version std.algorithm at all in D1 because of the heavy use of partial IFTI with those string alias parameters.
>
> Couldn't you use a double template?
>
>        template doSomething(string predicate)
>        {
>                void doSomething(A)(a) { ... }
>        }
>
> Then call it like this:
>
>        doSomething!("hello!")(5);
>
> I'm using this trick at some places the D/Objective-C bridge.
>
> Anyway, it's probably not worth the trouble anymore given that the latest DMD fixes the problem.

Technically yes, but the code would require so many changes to make that work that I didn't think it was worth it.  I might as well call it bills.algorithm at that point instead of std2.algorithm. Apparently Andrei didn't like the thought of having to write the code that way either, which is presume why he convinced Walter to change/fix IFTI in D2.

--bb

On Tue, 16 Dec 2008 01:48:21 +0300, mastrost <titi.mastro@free.fr> wrote:

> Hi,
>
> first of all, thank you Walter and all the D community for making the great "pure"
> feature become reality.
> I have 2 questions concerning the behaviour of this feature.
>
> The first one concerns the existence -or not- of "pure delegates".
> It makes sense to use a delegate if its closure is not empty -otherwise it is no
> more than a function-. This is the reason why we can think delegates cannot be
> pure. Let's take an example:
>
> void foo(){
>     int x=0;
>     //bar is not pure at all in this context
>     int bar(){
>         return x;
>     }
>     writefln(bar()); // prints '0'
>     ++x;
>     writefln(bar()); // prints '1'
> }
>
> But the fact is that when returning a delegate, its closure freezes forever and so
> behaves like a local variable and not like a global variable by respect to the
> delegate :
>
> int delegate() getPureFunction(int x){
>     int bar(){
>         return x;
>     }
>     return &bar;
> }
>
> void main(){
>     int delegate() myPureFunction;
>     myPureFunction = getPureFunction(5);
> }
>
> In this example, myPureFunction looks like a pure function, does it?
> So how does dmd 2.022 behave for such kind of "pure delegates" ? Do you think
> there is a futur for pure delegates in the D language ? If not this would mean
> that we cannot use the power of delegates (to do real functionnal programming) and
> the power of purity in the same time, which will be very disapointing for
> programmers, don't you think ?
>

Yes, it was previously discussed many times (not only delegates but any function in general (locally impure)).
Current plan it to make pure function restrictive and then lift unnecessary restrictions where possible.

> This was my first question. The second one concerns purity and parallel
> programming. Is dmd 2.022 implementing some kind of parallelism thanks to pure
> function? In fact I have been argued that "pure" keyword is not enough for the
> compiler to make an efficient parallel program. The problem would be that the
> compiler has no mean to know the granularity of the tasks. What are your feelings
> about that?
>

This is not implemented yet. Pure function are just being added into language.

> Thanks a lot
>
>
>

On Mon, 15 Dec 2008 17:48:21 -0500, mastrost <titi.mastro@free.fr> wrote:
> int delegate() getPureFunction(int x){
>     int bar(){
>         return x;
>     }
>     return &bar;
> }

 int delegate() getPureFunction(int x){
     int bar(){
         return x++; // no longer pure
     }
     return &bar;
 }

> In this example, myPureFunction looks like a pure function, does it?

No it doesn't, but on the other hand, pure member functions argue that pure delegates are reasonable and useful. (i.e. delegates tagged as pure and then checked for references to non-pure data)

> This was my first question. The second one concerns purity and parallel
> programming. Is dmd 2.022 implementing some kind of parallelism thanks to pure
> function? In fact I have been argued that "pure" keyword is not enough for the
> compiler to make an efficient parallel program. The problem would be that the
> compiler has no mean to know the granularity of the tasks. What are your feelings
> about that?

I'd say that you're unlikely to get an optimal parallel program, but there already exists several functional languages (i.e. pure) that automatically parallelize their code bases quite efficiently.

On Tue, 16 Dec 2008 18:58:47 +0100, Robert Jacques <sandford@jhu.edu> wrote:

> On Mon, 15 Dec 2008 17:48:21 -0500, mastrost <titi.mastro@free.fr> wrote:
>
>> In this example, myPureFunction looks like a pure function, does it?
>
> No it doesn't

So this does not seem pure to you?

  int myPureFunction(int x) {
    return x;
  }

-- 
Simen

On Tue, 16 Dec 2008 12:28:43 -0800, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:

> On Tue, 16 Dec 2008 18:58:47 +0100, Robert Jacques <sandford@jhu.edu> wrote:
>
>> On Mon, 15 Dec 2008 17:48:21 -0500, mastrost <titi.mastro@free.fr> wrote:
>>
>>> In this example, myPureFunction looks like a pure function, does it?
>>
>> No it doesn't
>
> So this does not seem pure to you?
>
>    int myPureFunction(int x) {
>      return x;
>    }

Short answer: That's a function, not a delegate and without a 'pure' tag it's unreasonable for the complier to know it's logically pure.

Long answer: Your original arguement was:

> But the fact is that when returning a delegate, its closure freezes forever and so
behaves like a local variable and not like a global variable by respect to the
delegate :

Which I read to mean that a returned delegate is inherently pure. On a second read, I think you mean that the closure heap variables may be treated as immutable once a delegate is returned if the delegate doesn't mutate them. While an interesting observation, it too is easily broken:

int delegate() impure;

int delegate() getPureFunction(int x){
    int bar(){
        return x;
    }
    int foo() {
        return x++;
    }
    impure = foo;    // The closure may not be considered immutable since 'x' escapes
    return &bar;
}

On Wed, 17 Dec 2008 00:39:00 +0100, Robert Jacques <sandford@jhu.edu> wrote:

> On Tue, 16 Dec 2008 12:28:43 -0800, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:
>
>> So this does not seem pure to you?
>>
>>    int myPureFunction(int x) {
>>      return x;
>>    }
>
> Short answer: That's a function, not a delegate and without a 'pure' tag it's unreasonable for the complier to know it's logically pure.

I agree with this, but feel that's beside the point argued by mastrost.
My point (and I believe mastrost's as well) was that the above function
and mastrost's example could be considered pure by the simple addition
of the 'pure' keyword.

> Long answer: Your original arguement was:
>
>> But the fact is that when returning a delegate, its closure freezes forever and so
> behaves like a local variable and not like a global variable by respect to the
> delegate :
>
> Which I read to mean that a returned delegate is inherently pure. On a second read, I think you mean that the closure heap variables may be treated as immutable once a delegate is returned if the delegate doesn't mutate them. While an interesting observation, it too is easily broken:

Ah, I read it to mean that a delegate with no side effects is just as
pure as a function with none, which I find hard to argue against. As D
is a systems language, one might argue that casting a delegate to pure
is reasonable, as it may be too hard to statically check if it is pure,
and a cast is a confirmation from the programmer that yes, he knows
what he's doing.

-- 
Simen

"Simen Kjaeraas" wrote
> On Wed, 17 Dec 2008 00:39:00 +0100, Robert Jacques wrote:
>> Which I read to mean that a returned delegate is inherently pure. On a second read, I think you mean that the closure heap variables may be treated as immutable once a delegate is returned if the delegate doesn't mutate them. While an interesting observation, it too is easily broken:
>
> Ah, I read it to mean that a delegate with no side effects is just as pure as a function with none, which I find hard to argue against. As D is a systems language, one might argue that casting a delegate to pure is reasonable, as it may be too hard to statically check if it is pure, and a cast is a confirmation from the programmer that yes, he knows what he's doing.

Please note, Walter's vision of pure is not the same as C's implementation of pure.

Walter wants pure functions that have no side effects *AND* cannot be affected by other functions' side effects.  Your example fails the second requirement.

This is more in line with actual fucntional languages, where all data is invariant (and therefore, cannot be affected by outside functions).

-Steve

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.

-- 
Simen