• KennyTM~ (9/9) Jun 09 2011 Given that the 'new' expression can be used in 'pure', should it be that...
• Steven Schveighoffer (12/22) Jun 09 2011 Yes. But one of the possible issues here: weak purity is determined by ...
• bearophile (4/6) Jun 09 2011 We're back to some concept of referential transparency of pointers/refer...
• pillsy (5/13) Jun 11 2011 Would adding a third, dummy, reference-type parameter that takes a suita...
• Robert Jacques (3/19) Jun 11 2011 Given that malloc returns a mutable pointer, I think it would/should be ...
• Andrei Alexandrescu (5/14) Jun 09 2011 GC.malloc is not technically pure because its result does not only
• Steven Schveighoffer (10/24) Jun 09 2011 It's weak-pure, not strong-pure. weak-pure functions are allowed to
• bearophile (5/8) Jun 09 2011 So is the ptr field of a dynamic array allocated inside a strongly pure ...
• Robert Jacques (4/13) Jun 09 2011 I think most of the GC functions should be usable in pure functions, but...
• Kagamin (2/3) Jun 09 2011 Won't this pollute everything with @trasparent annotations, because code...
• bearophile (4/5) Jun 11 2011 Probably some compromise is better, that allows you to drop this annotat...
• KennyTM~ (4/13) Jun 12 2011 Thanks everyone for commenting. I've turned this into a bug 6151

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.

"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

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

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

"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  

 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

Given that malloc returns a mutable pointer, I think it would/should be  
considered weakly-pure.

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

"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

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

"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.

Kagamin <spam here.lot> writes:

bearophile Wrote:

 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.

Won't this pollute everything with  trasparent annotations, because code
usually doesn't depend on pointer value so it would want to work on transparent
pointers.

bearophile <bearophileHUGS lycos.com> writes:

Kagamin:

 Won't this pollute everything with  trasparent annotations, because code
usually doesn't depend on pointer value so it would want to work on transparent
pointers.

Probably some compromise is better, that allows you to drop this annotation in
most situations where it's not necessary... I am not sure I am intelligent and
expert enough to design this yet. I am learning, but it's not easy stuff. A
brainstorm-style design may be needed :-)

Bye,
bearophile

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 :).