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

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Sat, 19 Mar 2011 05:20:13 +0000 (UTC)

          From comp.compilers

Related articles
[6 earlier articles]
Re: In a Pascal-like language, would being able to declare a subroutin mcr@wildcard.demon.co.uk (Martin Rodgers) (2011-03-12)
Re: In a Pascal-like language, would being able to declare a subroutin noitalmost@cox.net (noitalmost) (2011-03-15)
Re: In a Pascal-like language, would being able to declare a subroutin wclodius@los-alamos.net (2011-03-15)
Re: In a Pascal-like language, would being able to declare a subroutin mcr@wildcard.demon.co.uk (Martin Rodgers) (2011-03-16)
Re: In a Pascal-like language, would being able to declare a subroutin sinu.nayak2001@gmail.com (Srinivas Nayak) (2011-03-16)
Re: In a Pascal-like language, would being able to declare a subroutin massimo_dentico@hotmail.com (Massimo A. Dentico) (2011-03-18)
Re: In a Pascal-like language, would being able to declare a subroutin gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-03-19)
Re: In a Pascal-like language, would being able to declare a subroutin sinu.nayak2001@gmail.com (Srinivas Nayak) (2011-03-21)
Re: Fortran PURE routines, was In a Pascal-like language, gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-03-24)
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Sat, 19 Mar 2011 05:20:13 +0000 (UTC)
Organization: A noiseless patient Spider
References: 11-03-032 11-03-040 11-03-043 11-03-044
Keywords: analysis, optimize
Posted-Date: 20 Mar 2011 18:50:20 EDT

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



Post a followup to this message

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