Re: In a Pascal-like language, would being able to declare a subroutine as "purely functional" be of any value?

Srinivas Nayak <sinu.nayak2001@gmail.com> wrote:
> True,


> Programmer promises...


> Compilers will not be able to restrict a out-of-scope variable.
> Because, programmer may have many levels of indirection to a out-of-
> scope variable.


I believe for Fortran, it can restrict all access to out-of-scope
variables. No static (SAVEd), no COMMON, no module variables, no host
association. Also, PURE routines are only allowed to call other PURE
routines.


The actual (summary) wording for Fortran 2003 is:


    "The above constraints are designed to guarantee that a pure
      procedure is free from side effects (modifications of data visible
      outside the procedure), which means that it is safe to reference
      it in constructs such as a FORALL assignment-stmt where there
      is no explicit order of evaluation. The constraints on pure
      subprograms may appear complicated, but it is not necessary
      for a programmer to be intimately familiar with them. From the
      programmer's point of view, these constraints can be summarized
      as follows: a pure subprogram shall not contain any operation
      that could conceivably result in an assignment or pointer
      assignment to a common variable, a variable accessed by use
      or host association, or an INTENT (IN) dummy argument; nor shall
      a pure subprogram contain any operation that could conceivably
      perform any external file input/output or STOP operation.
      Note the use of the word conceivably; it is not sufficient for
      a pure subprogram merely to be sideffect free in practice.
      For example, a function that contains an assignment to a
      global variable but in a block that is not executed in any
      invocation of the function is nevertheless not a pure function.
      The exclusion of functions of this nature is required if strict
      compile-time checking is to be used."


On most systems, that leaves one loophole: If you lie and tell the
compiler that the called routine is PURE, but later supply a non-PURE
routine to the linker, then in most cases you get away with it. With
name-mangling, one could probably plug that hole.


> How far compiler shall check them?
> For C++ also const things can be unconst...
> So, seems, compilers will be hopeless about it.


For C and C++, as with Fortran, separate compilation leaves a hole.


If it didn't, one could use an assembly language routine to get around
it. For that matter, one could rewrite the compiler to ignore PURE.


-- glen

Return to the comp.compilers page.
Search the comp.compilers archives again.