Grafting Functional Support on Top of an Imperative Language
Sean Kelly
sean at invisibleduck.org
Sat Apr 5 08:38:09 PDT 2008
== 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
More information about the Digitalmars-d
mailing list