In reading over the Debugging draft (i.e., the future S20), I ran
across the concept of the infectious trait - that is, a trait that
doesn't just get applied to the thing to which it is explicitly
applied; rather, it tends to spread to whatever else that thing comes
in contact with.  "Taint" is the primary example of this, although not
the only one.

In reading about functional programming, I ran across the concept of
the "pure function" - i.e., a function that doesn't produce side
effects.  The article went on to say that "While most compilers for
imperative programming languages detect pure functions, and perform
common-subexpression elimination for pure function calls, they cannot
always do this for pre-compiled libraries, which generally do not
expose this information, thus preventing optimisations that involve
those external functions. Some compilers, such as gcc, add extra
keywords for a programmer to explicitly mark external functions as
pure, to enable such optimisations."

It occurred to me that this business of marking functions as pure
could be done in perl by means of traits - that is, any function might
be defined as "is pure", promising the compiler that said function is
subject to pure function optimization.  It further occurred to me that
a variation of the contagious trait concept (operating on code blocks
and their component statements instead of objects; operating at
compile time rather than run time; and spreading via "all
participants" rather than "any participant") could be used to auto-tag
new pure functions, provided that all so-called "primitive pure
functions" are properly tagged to begin with.  The compiler could then
rely on this tagging to perform appropriate optimization.

Such auto-tagging strikes me as being in keeping with Perl's virtue of
laziness: writers of new code don't have to care about tagging pure
functions (or even know that they exist) in order for the tagging to
take place, leading to a potentially more robust library of functions
overall (in the sense of "everything in the library is properly
annotated").  As well, I could see it having some additional benefits,
such as in concurrent programming: "is critical" could be similarly
infectious, in that any function that might call a critical code block
should itself be tagged as critical.  Indeed, "is critical" and "is
pure" seem to be mutually exclusive concepts: a given code block might
be critical, pure, or neither; but it should never be both.

Am I onto something, or is this meaningless drivel?

-- 
Jonathan "Dataweaver" Lang

Reply via email to