Is this function pure?

Robert Fraser fraserofthenight at gmail.com
Wed Sep 19 11:50:33 PDT 2007


Heh, never knew that; that's good news. Thanks for brightening up my day!

Brad Roberts Wrote:

> Yes you can.  The malloc subsystem out of practical necessity is 
> internally thread safe and can be used concurrently without concern.
> 
> Robert Fraser wrote:
> > Someone probably already mentioned this, but you can't (easily, i.e. maybe some sort of heap partitioning could do it but you'd need OS support for that) automatically parallelize functions that allocate memory (since the heap is a shared resource), which was one of the big selling points of "pure". So I'm assuming that allocations are out of the equation. And since exceptions are most often paired up with an allocation (although not necessarily), those might be out, too. Not totally sure about that one.
> > 
> > There's no reason stack-allocated/scope classes couldn't be used, though.
> > 
> > Janice Caron Wrote:
> > 
> >> On 9/19/07, Nathan Reed <nathaniel.reed at gmail.com> wrote:
> >>> CTFE is
> >>> basically like running an interpreter, right?
> >> I presume that stands for Compile Time Function Execution and not
> >> chlorotrifluoroethylene, right? :-)
> >>
> >> My feeling is that Ingo is basically right, in that Walter needs to
> >> assume that new can never fail - that it can successfully allocate
> >> infinite amounts of memory without causing trouble. If that assumption
> >> holds (...obviously it doesn't, but bear with me...) then new is
> >> allowed. Otherwise the simplest things would be banned: a function
> >> which does toString (e.g. that turns 42 into "42") would be banned; a
> >> function which adds a passed-in element to a passed-in associative
> >> array would be banned, and so on. I guess it just has to be allowed.
> >>
> >> But I still have a problem with it, because such a program is only
> >> "logically pure", not "physically pure". And I have to wonder, will be
> >> be allowed to write our own "logically pure" functions and declare
> >> them pure?
> >>
> >> How will custom allocators for "new" fit into the picture? A custom
> >> allocator must surely access global state? A custom allocator could be
> >> written to be (logically) pure, or it could be decidedly impure (for
> >> example by initialising the created variables with rand()).
> >>
> >> Will purity be transitive and as strictly enforced as const? Will we
> >> be able to cast away purity when we need to?
> >>
> >> I guess we'll wait and see, but I would surely like to know.
> 




More information about the Digitalmars-d mailing list