On Mon, 20 Apr 2009 16:09:09 +0900, Walter Bright <newshound1@digitalmars.com> wrote:

>
> This is a major revision to Phobos, including Andrei's revolutionary new range support.
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.029.zip

Range is so cool!

Though...
I tried following code:

void main()
{
    writeln("Case1");
    {
        Mt19937 gen = Mt19937(0);
        writeln(gen.front);
        gen.popFront;
        writeln(gen.front);
    }
    writeln("---");
    {
        Mt19937 gen = Mt19937(0);
        advance(gen, 1);  // skip 1 element
        writeln(gen.front);
        gen.popFront;
        writeln(gen.front);
    }
    writeln("(J\(BnCase2");
    {
        Mt19937 gen;
        writeln(gen.front);
        gen.popFront;
        writeln(gen.front);
    }
    writeln("---");
    {
        Mt19937 gen;
        advance(gen, 1);  // skip 1 element
        writeln(gen.front);
        gen.popFront;
        writeln(gen.front);
    }
}

Result:

Case1
2357136044 (1)
2546248239 (2)
---
2546248239 (2)
3071714933 (3)

Case2
581869302  (1)
3890346734 (2)
---
581869302  (1)?
3890346734 (2)?

I think 'Case1' is correct, but 'Case2' is wrong.
Mt19937's bug?

-- 
tama <repeatedly@gmail.com>
http://profile.livedoor.com/repeatedly/
$B%a%s%P!<Jg=8Cf(B
http://tpf.techtalk.jp/

On Tue, Apr 21, 2009 at 8:56 PM, Don <nospam@nospam.com> wrote:
> bearophile wrote:
>>
>> Don:
>>>
>>> Yes. Actually, marking a nested function as pure doesn't make much sense.
>>> It's entirely equivalent to moving it outside the function; [...]
>>> I'm not sure that nested pure member functions should be legal.
>>
>> It's not fully equivalent to moving it out of the function because once
>> you pull it out you add a name to the outer namespace: nested functions are
>> useful to keep namespaces tidy too.
>> So I'd like to have nested pure functions too.
>>
>> pure int foo(int y) { return y + y; } // outer foo
>> pure void bar(int x) {
>>  pure int foo(int y) { return y * y; }
>>  return foo(x) * .foo(x);
>> }
>>
>> Thank you,
>> bye,
>> bearophile
>
> That's true, but it seems quite difficult to get right. A pure nested
> function can in theory access immutable members in the outer function -- but
> must not access the parameters of the outer function.
> If there are no immutable members in the outer function, the compiler would
> ideally convert it into an external pure function, so that it
> doesn't need a frame pointer to the outer function. But it would need error
> messages for any use of mutable outer function members. Etc.
> It seems quite a lot of work for something of very limited use.
> Making it into a external, private pure function is almost the same.
>
>
>

why not just make it a static pure nested function? or is that no longer proper D2 ?

Andrei Alexandrescu wrote:
> bearophile wrote:
>> Andrei Alexandrescu:
>>> If it were an error, I wouldn't let it go.
>>
>> It's an error. It will lead to troubles.
> 
> Well at most you could say it's error-prone, something that is easier to argue. The problem is that forcing it into an error makes quite a number of valid uses impossible. An example is a logging application that provides you a number of pieces of information (date, time, message, etc.) and you get to specify how they should be formatted. Oftentimes you'd choose to ignore some data.
> 
> Andrei

Fair enough.  But then let's split off a version of the function which allows unused arguments.  For most users, in most cases, unused arguments are indicative of an error.

Case in point: I have been bitten by this perhaps half a dozen times *already* porting older code.  This code used to work fine:

	writefln("The value is: %d", myVar, ".  Do something!");

Now, it interprets the trailing string as an unused argument, and ignores it (silently).  Ugh.

Ofc, looking back, I don't like that old coding style...I'm migrating back more to C-style (give the whole format string first).  But the fact that I had a *silent* error was frustrating.

Russ

On 2009-04-21 11:18:39 -0400, Don <nospam@nospam.com> said:

> Yes. Actually, marking a nested function as pure doesn't make much sense.
> It's entirely equivalent to moving it outside the function; a nested pure function shouldn't be able to access any members of the enclosing function, otherwise it's not pure. But DMD doesn't enforce that, and so it creates inefficient and possibly buggy code.

What about immutable local variables? A pure function can access immutable globals, so it should be able to access immutable locals too.

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

Michel Fortin wrote:
> On 2009-04-21 11:18:39 -0400, Don <nospam@nospam.com> said:
> 
>> Yes. Actually, marking a nested function as pure doesn't make much sense.
>> It's entirely equivalent to moving it outside the function; a nested
>> pure function shouldn't be able to access any members of the enclosing
>> function, otherwise it's not pure. But DMD doesn't enforce that, and
>> so it creates inefficient and possibly buggy code.
> 
> What about immutable local variables? A pure function can access immutable globals, so it should be able to access immutable locals too.
> 

If you treat the nested function's context pointer as a pointer to a struct matching the stack layout, then you can have pure nested functions -- they have exactly the same semantics as a pure struct member function.

  -- Daniel

Russell Lewis wrote:

...
> Case in point: I have been bitten by this perhaps half a dozen times *already* porting older code.  This code used to work fine:
> 
> 	writefln("The value is: %d", myVar, ".  Do something!");
> 
...

I bet a lot of to-be-ported D code will have this bug, I know my code will. When you want to print a format string this way - last argument(s) simply appended, it saves you two characters typing. When something saves any characters typing and produces the same result, programmers will do that.

Daniel Keep wrote:
> 
> Michel Fortin wrote:
>> On 2009-04-21 11:18:39 -0400, Don <nospam@nospam.com> said:
>>
>>> Yes. Actually, marking a nested function as pure doesn't make much sense.
>>> It's entirely equivalent to moving it outside the function; a nested
>>> pure function shouldn't be able to access any members of the enclosing
>>> function, otherwise it's not pure. But DMD doesn't enforce that, and
>>> so it creates inefficient and possibly buggy code.
>> What about immutable local variables? A pure function can access
>> immutable globals, so it should be able to access immutable locals too.
>>
> 
> If you treat the nested function's context pointer as a pointer to a
> struct matching the stack layout, then you can have pure nested
> functions -- they have exactly the same semantics as a pure struct
> member function.
> 
>   -- Daniel

True, but that would mean that it'd be pretty useless. It's almost exactly the same as not marking it pure.
pure foo(int x)
{
  int y;
  pure int bar(int z) { return z*z; }

  int a= bar(2);
  y++;
  int b = bar(2); // has to recalculate bar(2), because y has changed.
}

---
The basic issue is that the situations where marking a nested function as 'pure' is a good idea, is extremely limited.
Compared to making it an external pure private function, with any desired immutable members passed as parameters, it has these advantages and disadvantages.
+ inaccessable to other functions in the same module.
+ can access immutable members in the outer function, without passing them as parameters.
- slower, since it needs a context pointer as well as a frame pointer.

I think those benefits are pathetic.

On Tue, 21 Apr 2009 07:42:46 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

>Max Samukha wrote:
>> On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha <samukha@voliacable.com.removethis> wrote:
>> 
>>> On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright <newshound1@digitalmars.com> wrote:
>>>
>>>> This is a major revision to Phobos, including Andrei's revolutionary new range support.
>>>>
>>>> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip
>>> Wicked awesome!
>>>
>>> file:///C:/dmd/html/d/phobos/std_range.html#cons
>> http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons
>> 
>>> Looks like bug 2676 was fixed in 2.027
>
>Thanks. I uncommented the unittest, updated the doc, and checked in.
>
>Andrei

A couple more minor doc issues: http://www.digitalmars.com/d/2.0/phobos/std_range.html: instances of "the popFront" need to be corrected to "the next".

On the std.algorithm page, the examples for "map" and "filter" don't compile due to the fixed size array in equal().

The example for "bringToFront" is outdated.

The comments for "remove": "If $(s =" -> "If $(D s ="

Georg Wrede wrote:
> Walter Bright wrote:
>> Lutger wrote:
>>> what the hell...this code can't be human.
>>
>> I was replaced by Colossus years ago.
> 
> Michael A. Jackson wouldn't approve 1175 gotos in 113 files.

It'd be really funny to pass it through one of those "code quality" metrics, one of the ones with a ridiculously heavy penalty for using goto. I think it'd tell you that DMD source is almost the lowest-quality code on the planet. <g>

Actually, looking through the DMD source it becomes obvious that goto is really not a problem at all. The lack of comments is much more of a problem. (Especially with files with names like "e2ir.c". What the heck is "fltables.c", "cdxxx.c", "elxxx.c" ?). Even so, it's mostly not that difficult to understand.

Max Samukha wrote:
> On Tue, 21 Apr 2009 07:42:46 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Max Samukha wrote:
>>> On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha <samukha@voliacable.com.removethis> wrote:
>>>
>>>> On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright <newshound1@digitalmars.com> wrote:
>>>>
>>>>> This is a major revision to Phobos, including Andrei's revolutionary new range support.
>>>>>
>>>>> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip
>>>> Wicked awesome!
>>>>
>>>> file:///C:/dmd/html/d/phobos/std_range.html#cons
>>> http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons
>>>
>>>> Looks like bug 2676 was fixed in 2.027
>> Thanks. I uncommented the unittest, updated the doc, and checked in.
>>
>> Andrei
> 
> A couple more minor doc issues: http://www.digitalmars.com/d/2.0/phobos/std_range.html: instances of "the popFront" need to be corrected to "the next".
> 
> On the std.algorithm page, the examples for "map" and "filter" don't compile due to the fixed size array in equal().
> 
> The example for "bringToFront" is outdated.
> 
> The comments for "remove": "If $(s =" -> "If $(D s ="

Please file a bug report.  Posts here are are good way for issues to fall through the cracks.

Thanks,
Brad