• Sean Reque <seanthenewt yahoo.com> Aug 01 2008

Sean Reque <seanthenewt yahoo.com> writes:

mort Wrote:

 I'm not an expert on D, but it looks like a pretty nice language.  While
reading about 'pure' recently, however, I found what appeared to be pretty
major usability problems with the idea as it was presented:
 
 - Pure functions can have local mutable state, but aren't allowed to factor
the logic for manipulating that state out into functions (since such a function
would be non-pure).
 
 - Pure functions can't be applied to mutable data.  So you potentially need a
mutable non-pure version of each pure function.
 
 An elegant solution to both of these problems would seem to be the one
proposed in this thread - get rid of the requirement that parameters be
invariant.  The first problem above is solved by pure functions with mutable
parameters, and the second by pure functions with const parameters.
 
 Special optimizations that require purity and parameter invariance can always
be done by creating a specialized version of each pure function that's invoked
when the arguments are known to be invariant.  Let the compiler handle the
duplication - don't make the programmer copy/paste.
 
 Thanks
 
 


I agree with you completely, and was planning on making an similar post about
the subject.

Take one of the string functions, for instance, countchars. It has the
following signature:

 size_t countchars(string s, string pattern);
  
This function etiher is or could be pure. However, the function would work just
as well when operating on const (char)[] data, which is potentially mutable, or
char[] data, which is explicitly mutable. Being able to have a conditionally
pure function, one that was pure if its arguments were invariant and not pure
if they were not, would allow this function to work for both mutable and
immutable data, and gain all the optimization benefits of a pure function if
its parameters were indeed invariant.

There are of course occasions where functions might need to act differently
based on the invariance of its parameters. string.split, for instance, would
probably want to copy the data it returns if its parameters were not invariant.
However, I think differences like these could easily be handled with D's
compile-time reflection abilities.

Lastly, I never thought about the case where a pure function would need to call
another function to operate on explicitly mutable but temporary local data. It
would be nice to have that handled as well! It seems like the more you dig in
to pure functions, the more you realize that the compiler needs to be able to
be very smart to make the concept usable for programmers. As it stands now, it
seems difficult for pure functions to interact with the rest of D.