www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should GC.malloc be considered 'pure'?

reply KennyTM~ <kennytm gmail.com> writes:
Given that the 'new' expression can be used in 'pure', should it be that 
GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be 
weakly pure also? And should it apply to other managed allocators as 
well, e.g. the proposed TempAlloc?

I'm asking this as one of the specializations of std.conv.toImpl calls 
GC.malloc, which is one of the 11 causes preventing std.conv.to from 
being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity) 
are used by std.array.appender (of pure range), and appender is also a 
major reason why std.conv.to is not pure.
Jun 09 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 09 Jun 2011 13:51:31 -0400, KennyTM~ <kennytm gmail.com> wrote:

 Given that the 'new' expression can be used in 'pure', should it be that  
 GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be  
 weakly pure also?

Yes. But one of the possible issues here: weak purity is determined by the type of the parameters. GC.malloc only takes non-reference types, so marking it as pure might make the compiler actually think these are strong-pure. Don? Any ideas here? I'm thinking we might need an compiler pragma. This would be extremely seldom used.
  And should it apply to other managed allocators as well, e.g. the  
 proposed TempAlloc?

I would say yes, but I think David should have the final say. Definitely, TempAlloc cannot be pure unless GC.malloc and C's malloc are pure, since those are marked that way.
 I'm asking this as one of the specializations of std.conv.toImpl calls  
 GC.malloc, which is one of the 11 causes preventing std.conv.to from  
 being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity)  
 are used by std.array.appender (of pure range), and appender is also a  
 major reason why std.conv.to is not pure.

I think Appender should also be pure. -Steve
Jun 09 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 Don?  Any ideas here?  I'm thinking we might need an compiler pragma.   
 This would be extremely seldom used.

We're back to some concept of referential transparency of pointers/reference types, that has produced a tepid response... :-) Bye, bearophile
Jun 09 2011
prev sibling parent pillsy <pillsbury gmail.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Thu, 09 Jun 2011 13:51:31 -0400, KennyTM~ <kennytm gmail.com> wrote:
 Given that the 'new' expression can be used in 'pure', should it be that
 GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be
 weakly pure also?


 Yes.  But one of the possible issues here: weak purity is determined by
 the type of the parameters.  GC.malloc only takes non-reference types, so
 marking it as pure might make the compiler actually think these are
 strong-pure.

Would adding a third, dummy, reference-type parameter that takes a suitable default value allow you to hack around this? Cheers, Pillsy
Jun 11 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/9/11 12:51 PM, KennyTM~ wrote:
 Given that the 'new' expression can be used in 'pure', should it be that
 GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be
 weakly pure also? And should it apply to other managed allocators as
 well, e.g. the proposed TempAlloc?

 I'm asking this as one of the specializations of std.conv.toImpl calls
 GC.malloc, which is one of the 11 causes preventing std.conv.to from
 being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity)
 are used by std.array.appender (of pure range), and appender is also a
 major reason why std.conv.to is not pure.

GC.malloc is not technically pure because its result does not only depend on arguments - it's a fresh value each time. So the compiler can't apply pure reasoning to it. Andrei
Jun 09 2011
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 09 Jun 2011 16:08:33 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 6/9/11 12:51 PM, KennyTM~ wrote:
 Given that the 'new' expression can be used in 'pure', should it be that
 GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be
 weakly pure also? And should it apply to other managed allocators as
 well, e.g. the proposed TempAlloc?

 I'm asking this as one of the specializations of std.conv.toImpl calls
 GC.malloc, which is one of the 11 causes preventing std.conv.to from
 being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity)
 are used by std.array.appender (of pure range), and appender is also a
 major reason why std.conv.to is not pure.

GC.malloc is not technically pure because its result does not only depend on arguments - it's a fresh value each time. So the compiler can't apply pure reasoning to it.

It's weak-pure, not strong-pure. weak-pure functions are allowed to return different values for two different runs with the same parameters. Essentially, weak-pure functions cannot have pure reasoning applied to them, *but* they can be called from strong-pure functions. It's not technically even weak-pure because it uses global data. But because memory allocation is so important to any functional programming, it needs to be an exception. -Steve
Jun 09 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 GC.malloc is not technically pure because its result does not only 
 depend on arguments - it's a fresh value each time. So the compiler 
 can't apply pure reasoning to it.

So is the ptr field of a dynamic array allocated inside a strongly pure function. Did you miss the discussion I've had here about the trasparent? The allocation of heap memory can be considered pure if you use the allocated memory as a referentially transparent value (this means it's allowed to be used by reference, but your code is not allowed to read the value of the reference itself, so the future state of the code depends only on the contents of the referenced memory, and not the reference itself. Also, overwriting this reference is kosher still :-) Bye, bearophile
Jun 09 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 09 Jun 2011 13:51:31 -0400, KennyTM~ <kennytm gmail.com> wrote:

 Given that the 'new' expression can be used in 'pure', should it be that  
 GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be  
 weakly pure also? And should it apply to other managed allocators as  
 well, e.g. the proposed TempAlloc?

 I'm asking this as one of the specializations of std.conv.toImpl calls  
 GC.malloc, which is one of the 11 causes preventing std.conv.to from  
 being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity)  
 are used by std.array.appender (of pure range), and appender is also a  
 major reason why std.conv.to is not pure.

I think most of the GC functions should be usable in pure functions, but I don't know how we'd accomplish that from a technical perspective. Another thing to consider is whether GC.malloc should be valid during CTFE.
Jun 09 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 11 Jun 2011 14:59:55 -0400, pillsy <pillsbury gmail.com> wrote:

 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Thu, 09 Jun 2011 13:51:31 -0400, KennyTM~ <kennytm gmail.com> wrote:
 Given that the 'new' expression can be used in 'pure', should it be  

 GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be
 weakly pure also?


 Yes.  But one of the possible issues here: weak purity is determined by
 the type of the parameters.  GC.malloc only takes non-reference types,  
 so
 marking it as pure might make the compiler actually think these are
 strong-pure.

Would adding a third, dummy, reference-type parameter that takes a suitable default value allow you to hack around this? Cheers, Pillsy

Given that malloc returns a mutable pointer, I think it would/should be considered weakly-pure.
Jun 11 2011
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
On Jun 10, 11 01:51, KennyTM~ wrote:
 Given that the 'new' expression can be used in 'pure', should it be that
 GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be
 weakly pure also? And should it apply to other managed allocators as
 well, e.g. the proposed TempAlloc?

 I'm asking this as one of the specializations of std.conv.toImpl calls
 GC.malloc, which is one of the 11 causes preventing std.conv.to from
 being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity)
 are used by std.array.appender (of pure range), and appender is also a
 major reason why std.conv.to is not pure.

Thanks everyone for commenting. I've turned this into a bug 6151 (http://d.puremagic.com/issues/show_bug.cgi?id=6151) so the discussion won't be lost :).
Jun 12 2011