Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!pur-ee!pur-phy!hal
From: hal@pur-phy (Hal Chambers)
Newsgroups: comp.lang.modula2
Subject: Re: Are procedure types breaking modules?
Keywords: procedure types, modules
Message-ID: <2190@pur-phy>
Date: 25 Apr 89 12:31:35 GMT
References: <688@tuvie> <849@htsa.uucp>
Reply-To: hal@newton.physics.purdue.edu.UUCP (Hal Chambers)
Organization: Purdue Univ. Physics Dept., W. Lafayette, IN
Lines: 37

In article <849@htsa.uucp> fransvo@htsa.UUCP (Frans van Otten) writes:

>....  Also, he is not clear on why some things are or
>are not allowed.  Why is it that you are not allowed to assign a
>local procedure to a procedure variable ?  Why can't a standard
>procedure be assigned to a procedure variable ?

I'll take a crack at this.

1. assigning local procedure to a procedure variable.
This would require saving the static scoping of the local procedure
in the procedure variable as well.  The dynamic environment must be
passed into an external module if the procedure variable is passed
to another routine.  It gets very messy, for both the implementation
and for understanding the program which uses it.

2. assinging standard procedures to procedure variable.
Many standard procedure are not implemented as procedures but as
in-line code (compiler macros).  Think about INC, TRUNC, ODD, etc.
There is nothing messy in principle about this; it's just to make
it easier to implement the compiler.

Neither of these restrictions is actually very restrictive in practice.
You can always write a global procedure to call a standard procedure
and assign that to the procedure variable.

Also, any procedure suitable for dynamic assignment is probably a general
"toolbox" type of procedure (or there wouldn't be multiple uses for it).
If this is the case then the procedure should be visible just about
everywhere (like INC, ODD, CHAR, ...) and not local to another procedure.
If it appeared that I needed to use a local procedure in this way I would
re-examine my program to see if there was a better way to partition it.

-- 
Hal Chambers
hal@newton.physics.purdue.edu
hal@physics-newton.arpa