On Tue, 21 Oct 2014 17:25:09 +0300
ketmar via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> On Tue, 21 Oct 2014 13:43:29 +0000
> Solomon E via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
> wrote:
> 
> > `b[0] = 8;` or `b[] = 8;` changes a. Printing the values for &a and &b shows they're different pointers, but (a is b) returns true. So I still have more to learn about how it does that.
> that's 'cause '&b' taking address of hidden "array structure", not the first array element, as in C. try 'a.ptr' and 'b.ptr' to get addresses of array elements.
p.s. '&(a[0])' and '&(b[0])' works too. parens are just for clarifying.

On Tuesday, 21 October 2014 at 08:02:52 UTC, bearophile wrote:
> Currently this code gets rejected:
>
> const int[] a = [1];
> void main() pure {
>     auto y = a[0];
> }
>
>
> test2.d(3,14): Error: pure function 'D main' cannot access mutable static data 'a'
> test2.d(3,14): Error: pure function 'D main' cannot access mutable static data 'a'
>
> But is this a good idea? Isn't it better to accept it?
>
> Bye,
> bearophile

pure functions are also supposed to don't use global variables at all, according to functional programming paradigm

On Tuesday, 21 October 2014 at 14:25:20 UTC, ketmar via Digitalmars-d-learn wrote:
> On Tue, 21 Oct 2014 13:43:29 +0000
> Solomon E via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
> wrote:
>
>> `b[0] = 8;` or `b[] = 8;` changes a. Printing the values for &a and &b shows they're different pointers, but (a is b) returns true. So I still have more to learn about how it does that.
> that's 'cause '&b' taking address of hidden "array structure", not
> the first array element, as in C. try 'a.ptr' and 'b.ptr' to get
> addresses of array elements.

Thanks, that's what I was looking for, in order to understand what's going on. I Googled for it on this site, but without remembering the keyword ptr, I didn't find anything relevant.

After I put printouts of .ptr in my test program, I figured out how to get the same result by unsafe pointer arithmetic. Apparently, for an array a, a.ptr == *(cast(ulong*) &a + 1). That's unsafe because the implementation might change, and pointer arithmetic is unsafe in general.

On Tuesday, October 21, 2014 08:02:50 bearophile via Digitalmars-d-learn
wrote:
> Currently this code gets rejected:
>
> const int[] a = [1];
> void main() pure {
>      auto y = a[0];
> }
>
>
> test2.d(3,14): Error: pure function 'D main' cannot access
> mutable static data 'a'
> test2.d(3,14): Error: pure function 'D main' cannot access
> mutable static data 'a'
>
> But is this a good idea? Isn't it better to accept it?

In principle, it should be fine, but because it's using const, it won't work.
global or static variables which are directly initialized with values that
cannot possibly have mutable references elsewhere in the code are the only
case where accessing const variables from outside a pure function like this
could work - i.e. the cases where immutable and const are essentially
identical (the only real difference being that if the variable is a reference
type, if it's immutable, it's also shared, whereas if it's const, it's
thread-local). So, I don't think that it's at all surprising that the compiler
rejects it. It should probably be made smarter so that it doesn't reject it,
but because you can just as easily make the variable immutable, you're not
losing any real functionality in the interim.

- Jonathan M Davis

On Tuesday, 21 October 2014 at 15:51:27 UTC, MachineCode wrote:
...
...
>
> pure functions are also supposed to don't use global variables at all, according to functional programming paradigm

Pure functions are immutables (constants but not "const" in the D or C++ senses) and can use other immutables, even if they're global immutables. (I guess it would be better though always to have a named top scope instead of everyone in the world having the same global scope :-)

On Tue, 21 Oct 2014 16:47:04 +0000
Solomon E via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> That's unsafe because the implementation might change, and pointer arithmetic is unsafe in general.
sure, ponter casting is implementation-dependend. but .ptr is guaranteed to work as expected. 'a' is just a `struct { size_t length; void* ptr }` now, but this representation is implementation detail, not a convention.

On Tuesday, 21 October 2014 at 16:56:06 UTC, Solomon E wrote:
> On Tuesday, 21 October 2014 at 15:51:27 UTC, MachineCode wrote:
> ...
> ...
>>
>> pure functions are also supposed to don't use global variables at all, according to functional programming paradigm
>
> Pure functions are immutables (constants but not "const" in the D or C++ senses) and can use other immutables, even if they're global immutables. (I guess it would be better though always to have a named top scope instead of everyone in the world having the same global scope :-)

You *do* have a named top scope, the module name (which is accessible with prefixing a symbol with ., i.e., .x refers to the symbol x at module scope). There is no such thing as global scope in D.

On Tuesday, 21 October 2014 at 15:51:27 UTC, MachineCode wrote:
> pure functions are also supposed to don't use global variables at all, according to functional programming paradigm

The functional programming paradigm is kind of irrelevant to D's pure, which should really be something more like @global. D's pure makes it so that a function cannot directly access global, mutable state - i.e. no mutable global or static variables which can ever be mutated by anything in the program. So, pure functions can access immutable global and static variables, because their state can never change, and in principle, they could access const variables that were directly initialized, e.g.

const int i = 7;

However, apparently, the compiler won't do that with arrays right now, as Bearophile has found. Accessing global or static variables that can never change once they're initialized does not violate the guarantees that D's pure makes, because the value is fixed and as such is essentially the same as hard-coding the value in the function directly. It's just those that can change which are a problem (which does potentially include global, const arrays if they were initialized via a static constructor).

Now, while D's pure really doesn't directly have anything to do with functional purity (_all_ it does is restrict access to global or static variables which can be mutated - either directly or indirectly), it _is_ a vital building block for functional purity, because if the function parameters are immutable or implicitly convertible to immutable, then the compiler knows that multiple calls to the function with the same arguments will always return the same result, because the function can't access any mutable globals to get at anything different to produce a different result. And even if the parameters aren't immutable or implicitly convertible to immutable, if the parameter types and return type are unrelated, the compiler can also know that the return value was not passed into the function (since it had nowhere else to get it from), so it knows that it's unique and can do stuff like implicitly convert that value to immutable safely.

So, with pure, the compiler can recognize actual, functional purity and other useful attributes and take advantage of them, but you're probably better off if you don't think of D's pure as being functionally pure, because there are quite a few things that D's pure functions can do which functionally pure functions can't do (like mutate their arguments if they're mutable).

A good article on D's pure: http://klickverbot.at/blog/2012/05/purity-in-d/

On Tuesday, 21 October 2014 at 17:00:49 UTC, Meta wrote:
> There is no such thing as global scope in D.

While that's technically true (and very good for avoiding symbol conflicts), modules at the module level are still typically referred to as global variables.