Should text be pure?

I have multiple enforce statements of the form:

      enforce(0 == _history.length ||
              !binaryFun!(orderingPred)(additional, _history[$-1]),
              text(V.stringof, " must be added in chronological order, but ",
                   additional, " comes before ", _history[$-1]));

and I was hoping that statement would not be the reason for keeping the containing function from being pure.

Is there a simple work around?

Regarding pure in general:

  - Is there a global list of standard functions that are in the queue for this designation? (or is every function taking a separate issue)
  - Where does (or should) purity fall in terms of priority?
  - Isn't it the case that unnecessary, forced impurity is like a plague, once it starts the spread is rapid. In general, have most developers given up on its benefit in their code now preferring /* pure */?

Thanks
Dan

On Wednesday, 23 October 2013 at 19:55:26 UTC, Daniel Davidson wrote:
> Should text be pure?

It's pure in 2.064, the upcoming release.

On Wednesday, 23 October 2013 at 19:56:26 UTC, Andrej Mitrovic wrote:
> On Wednesday, 23 October 2013 at 19:55:26 UTC, Daniel Davidson wrote:
>> Should text be pure?
>
> It's pure in 2.064, the upcoming release.

Great, thanks. What is the best way to get on that version for the Mac (pointer to instructions)?

Thanks
Dan

On 10/23/13, Daniel Davidson <nospam@spam.com> wrote:
> Great, thanks. What is the best way to get on that version for
> the Mac (pointer to instructions)?

You can download the beta here: http://forum.dlang.org/thread/52605C84.6010109@walterbright.com

On Wednesday, 23 October 2013 at 20:18:39 UTC, Andrej Mitrovic wrote:
> On 10/23/13, Daniel Davidson <nospam@spam.com> wrote:
>> Great, thanks. What is the best way to get on that version for
>> the Mac (pointer to instructions)?
>
> You can download the beta here:
> http://forum.dlang.org/thread/52605C84.6010109@walterbright.com

Thanks for pointer. I am using it and the file conv.d has:

string text(T...)(T args) { return textImpl!string(args); }


So, when you say it is pure, what are you referring to. I think pure could be specified as a block, but when I search up the next prior pure occurrence is:
  @safe pure unittest

So I don't think it is in a pure block. Also I still get:

Error: pure function 'plus.utils.history.History!(const(S), "a.date < b.date").History.opOpAssign!("~", S).opOpAssign' cannot call impure function 'std.conv.text!(string, string, const(S), string, const(S)).text'

So, I am still looking for workaround if possible and answers to the general questions on pure.

Thanks
Dan

On 10/23/2013 02:17 PM, Daniel Davidson wrote:
> On Wednesday, 23 October 2013 at 20:18:39 UTC, Andrej Mitrovic wrote:
>> On 10/23/13, Daniel Davidson <nospam@spam.com> wrote:
>>> Great, thanks. What is the best way to get on that version for
>>> the Mac (pointer to instructions)?
>>
>> You can download the beta here:
>> http://forum.dlang.org/thread/52605C84.6010109@walterbright.com
>
> Thanks for pointer. I am using it and the file conv.d has:
>
> string text(T...)(T args) { return textImpl!string(args); }
>
>
> So, when you say it is pure, what are you referring to. I think pure
> could be specified as a block, but when I search up the next prior pure
> occurrence is:
>    @safe pure unittest
>
> So I don't think it is in a pure block. Also I still get:
>
> Error: pure function 'plus.utils.history.History!(const(S), "a.date <
> b.date").History.opOpAssign!("~", S).opOpAssign' cannot call impure
> function 'std.conv.text!(string, string, const(S), string, const(S)).text'
>
> So, I am still looking for workaround if possible and answers to the
> general questions on pure.
>
> Thanks
> Dan

Perhaps it missed the beta cut. The following compiles with git head (or at least with v2.064-devel-b12d171):

import std.conv;
import std.exception;

void foo(int i) pure
{
    enforce (i == 42, i.text);
}

void main()
{
    foo(42);
}

Ali

On Wed, Oct 23, 2013 at 11:17:30PM +0200, Daniel Davidson wrote:
> On Wednesday, 23 October 2013 at 20:18:39 UTC, Andrej Mitrovic wrote:
> >On 10/23/13, Daniel Davidson <nospam@spam.com> wrote:
> >>Great, thanks. What is the best way to get on that version for the
> >>Mac (pointer to instructions)?
> >
> >You can download the beta here: http://forum.dlang.org/thread/52605C84.6010109@walterbright.com
> 
> Thanks for pointer. I am using it and the file conv.d has:
> 
> string text(T...)(T args) { return textImpl!string(args); }
> 
> 
> So, when you say it is pure, what are you referring to. I think pure
> could be specified as a block, but when I search up the next prior
> pure occurrence is:
>   @safe pure unittest

No, pure can't be specified as a block. You can only mark a function as pure.

Furthermore, the above function is a template function, which means the compiler will perform attribute inference on it. So provided textImpl has no impure operations, it should be inferred as pure, unless args has some impure methods in it that's being used by textImpl.


> So I don't think it is in a pure block. Also I still get:
> 
> Error: pure function 'plus.utils.history.History!(const(S), "a.date
> < b.date").History.opOpAssign!("~", S).opOpAssign' cannot call
> impure function 'std.conv.text!(string, string, const(S), string,
> const(S)).text'
> 
> So, I am still looking for workaround if possible and answers to the general questions on pure.
[...]

OK, I'm looking at the implementation of textImpl in std/conv.d, and it seems that the only thing it does is to call to!string(...) on each of its arguments, and append the result to a local variable called 'result'. Since array appending is pure (otherwise we have major problems with D purity), the only culprit seems to be the calls to to!string().

What arguments are you passing to text()? Do all of them have toString methods that are marked pure? Keep in mind that the default toString implementation (e.g. inherited from Object) may not necessarily be marked pure, so that could be the cause of your problems here.

It would be nice if you could provide a suitably minimized version of your code that exhibits this purity issue, so that we can track it down. It's kinda hard to figure out what's wrong based on verbal descriptions alone. (I apologize if you've already posted said code; I've been too busy to keep up with every post in this forum.)


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley

On 10/23/13, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> Furthermore, the above function is a template function, which means the compiler will perform attribute inference on it. So provided textImpl has no impure operations, it should be inferred as pure, unless args has some impure methods in it that's being used by textImpl.

Yeah that may just be the issue.

The reason I mentioned 2.064 is because std.conv.to and std.string.format are now pure, and text() likely uses these in one way or another.

On Wednesday, 23 October 2013 at 21:17:31 UTC, Daniel Davidson wrote:
> const(S))

make sure your struct's toString are all marked pure too.

On Wednesday, 23 October 2013 at 21:37:25 UTC, H. S. Teoh wrote:
> On Wed, Oct 23, 2013 at 11:17:30PM +0200, Daniel Davidson wrote:
>> On Wednesday, 23 October 2013 at 20:18:39 UTC, Andrej Mitrovic
>> wrote:
>> >On 10/23/13, Daniel Davidson <nospam@spam.com> wrote:
>> >>Great, thanks. What is the best way to get on that version for the
>> >>Mac (pointer to instructions)?
>> >
>> >You can download the beta here:
>> >http://forum.dlang.org/thread/52605C84.6010109@walterbright.com
>> 
>> Thanks for pointer. I am using it and the file conv.d has:
>> 
>> string text(T...)(T args) { return textImpl!string(args); }
>> 
>> 
>> So, when you say it is pure, what are you referring to. I think pure
>> could be specified as a block, but when I search up the next prior
>> pure occurrence is:
>>   @safe pure unittest
>
> No, pure can't be specified as a block. You can only mark a function as
> pure.
>

I think that is not correct. Consider:

int x = 3;
struct S {
  pure {
    void foo() {
      //x = 4;
    }
  }
}

pure blocks seem to have the effect you would expect. In fact it seems like you can stream them together to make code more pleasant:

const pure ... { ... }



> Furthermore, the above function is a template function, which means the
> compiler will perform attribute inference on it. So provided textImpl
> has no impure operations, it should be inferred as pure, unless args has
> some impure methods in it that's being used by textImpl.
>
>
>> So I don't think it is in a pure block. Also I still get:
>> 
>> Error: pure function 'plus.utils.history.History!(const(S), "a.date
>> < b.date").History.opOpAssign!("~", S).opOpAssign' cannot call
>> impure function 'std.conv.text!(string, string, const(S), string,
>> const(S)).text'
>> 
>> So, I am still looking for workaround if possible and answers to the
>> general questions on pure.
> [...]
>
> OK, I'm looking at the implementation of textImpl in std/conv.d, and it
> seems that the only thing it does is to call to!string(...) on each of
> its arguments, and append the result to a local variable called
> 'result'. Since array appending is pure (otherwise we have major
> problems with D purity), the only culprit seems to be the calls to
> to!string().
>
> What arguments are you passing to text()? Do all of them have toString
> methods that are marked pure? Keep in mind that the default toString
> implementation (e.g. inherited from Object) may not necessarily be
> marked pure, so that could be the cause of your problems here.
>
> It would be nice if you could provide a suitably minimized version of
> your code that exhibits this purity issue, so that we can track it down.
> It's kinda hard to figure out what's wrong based on verbal descriptions
> alone. (I apologize if you've already posted said code; I've been too
> busy to keep up with every post in this forum.)
>
>

Here is the self-contained code (I hope) that you can see it happening in:
http://pastebin.com/hb0Dz50r

BTW: any and all constructive criticism on any aspect of code is welcome.

I have not previously posted this code, but per your request on a previous thread (http://forum.dlang.org/post/xvymqxecgmkyvpvegird@forum.dlang.org) I did post sample code of struggles with immutable members. I've since mostly given up on immutable members (partially on your explanations and reasoning) and therefore immutable in general and so I find it's presence in the language like grapes to Tantalus. Not sure why I'm even fighting for purity since my main purpose for it originally was to allow for easy creation of immutable(T).

Thanks
Dan