Grafting Functional Support on Top of an Imperative Language

[Sean Kelly]

== Quote from Craig Black (craigblack2 at cox.net)'s article
> > I suspect that ultimately, a go-between "possibly pure"* qualifier for
> > functions will be desirable, just as const acts as "possibly invariant".
> > But that's just a hunch.
> >
> > *an amoral function -- pure if used in pure surroundings, impure if
> > surrounded in bad company. <g>
> Huh?  Is this just a joke or are you being serious?  Are you talking about a
> templated function?  I don't see the point of "possibly pure".

With the const design, functional code can call imperative code and vice-
versa.  ie. a functional routine could pass its invariant data to an imperative
routine accepting const parameters, and an imperative routine could .idup
or whatever to call a functional routine.  But 'pure' is currently a one-way
street.  Imperative code could call pure code, but the reverse is not true.
Don's "possibly pure" was a way to allow things to work in the opposite
direction, much like 'const' does.


Sean