Darren Duncan wrote: > There are ways to get what you want if you're willing to trade for more > restrictiveness in the relevant contexts. > > If we have a way of marking types/values and routines somehow as being pure, > in the types case marking it as consisting of just immutable values, and in > the routines case marking it as having no side effects, then we are telling > the compiler that it needs to examine these type/routine definitions and > check that all other types and routines invoked by these are also marked as > being pure, recursively down to the system-defined ones that are also marked > as being pure. > > Entities defined as being pure would be restricted in that they may not > invoke any other entities unless those are also defined as being pure. This > may mean that certain Perl features are off-limits to this code. For > example, you can invoke system-defined numeric or string etc operators like > add, multiply, catenate etc, but you can't invoke anything that uses > external resources such as check the current time or get a truly random > number. The latter would have to be fetched first by an impure routine and > be given as a then pure value to your pure routine to work with. Also, pure > routines can't update or better yet can't even read non-lexical variables. > > If it is possible with all of Perl's flexibility to make it restrictive of > certain features' use within certain contexts, then we can make this work.
True. In effect, this would be a sort of design-by-contract: by applying the "is pure" trait to an object or function, you're guaranteeing that it will conform to the behaviors and properties associated with pure functions and immutable values. A programmer who chooses to restrict himself to functions and values thus tagged would, in effect, be using a "functional programming dialect" of Perl 6, and would gain all of the optimization benefits that are thus entailed. It would also help the compiler to produce more efficient executable code more easily, since (barring a module writer who mislabels something impure as pure) it would be able to simply check for the purity trait to decide whether or not functional programming optimization can be tried. If the purity tag is absent, a whole segment of optimization attempts could be bypassed. As well, my original suggestion concerning the auto-tagging of pure functions was never intended as a means of tagging _everything_ that's pure; rather, the goal was to set things up in such a way that if it can easily be determined that thus-and-such a function is pure, it should be auto-tagged as such (to relieve module writers of the burdon of having to do so manually); but if there's any doubt about the matter (e.g., conclusively proving or disproving purity would be NP-complete or a halting problem), then the auto-tagging process leaves the function in question untagged, and the purity tag would have to be added in by the module writer. This is still a valid idea so long as the population of autotaggable pure functions (and, with Darren's suggestions, truly invariant objects, etc.) is usefully large. In short, I don't want the perfect to be the enemy of the good. Set up a good first approximation of purity (one that errs on the side of false negatives), and then let the coder tweak it from there. > Now Perl in general would be different, with the majority of a typical Perl > program probably impure without problems, but I think it is possible and > ideal for users to be able to construct a reasonably sizeable pure sandbox > of sorts within their program, where it can be easier to get correct results > without errors and better performing auto-threading etc code by default. By > allowing certain markings and restrictions as I mention, this can work in > Perl. Exactly what I was thinking. The key is that we're not trying to force programmers to use the pure sandbox if they don't want to; rather, we're trying to delineate the pure sandbox so that if they want to work entirely within it, they'll have a better idea of what they have to work with. -- Jonathan "Dataweaver" Lang
