Should GC.malloc be considered 'pure'?
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.
Re: Should GC.malloc be considered 'pure'?
On Thu, 09 Jun 2011 13:51:31 -0400, 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? 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
Re: Should GC.malloc be considered 'pure'?
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
Re: Should GC.malloc be considered 'pure'?
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
Re: Should GC.malloc be considered 'pure'?
On Thu, 09 Jun 2011 16:08:33 -0400, Andrei Alexandrescu 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
Re: Should GC.malloc be considered 'pure'?
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
Re: Should GC.malloc be considered 'pure'?
On Thu, 09 Jun 2011 13:51:31 -0400, 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. 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.
Re: Should GC.malloc be considered 'pure'?
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.
Re: Should GC.malloc be considered 'pure'?
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
Re: Should GC.malloc be considered 'pure'?
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article > On Thu, 09 Jun 2011 13:51:31 -0400, 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? > 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
Re: Should GC.malloc be considered 'pure'?
On Sat, 11 Jun 2011 14:59:55 -0400, pillsy wrote: == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Thu, 09 Jun 2011 13:51:31 -0400, 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? 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.
Re: Should GC.malloc be considered 'pure'?
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 :).
