Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!tektronix!percival!qiclab!m2xenix!randy
From: randy@m2xenix.UUCP (Randy Bush)
Newsgroups: comp.lang.modula2
Subject: Re: Are procedure types breaking modules?
Message-ID: <222@m2xenix.UUCP>
Date: 25 Apr 89 02:25:47 GMT
Reply-To: randy@m2xenix.UUCP (Randy Bush)
Organization: Oregon Software, Portland Oregon US
Lines: 26

In article <688@tuvie> ulrich@vip.UUCP (Ulrich Neumerkel) writes:

> When considering 6.8 of the Modula-2 report only procedures local to other
> procedures and standard procedures are forbidden to be assigned to a variable
> of a procedure type.  This means that it is possible to call a procedure which
> is not exported from another module, when you pass the procedure dynamically.
> I do not believe that this feature is really undesirable, however was it
> really intended?  The problem that might arise here is that there might be
> introduced invisible dependencies.  The alternative would be a complicated
> dataflow analysis or even a runtime check.
> o Is this a desirable feature, have you used it in "real" programs?
> o Are there any alternatives to it?

I have used this extensively.  When two modules have a server/client
relationship, one would not wish the server to 'know' the client.  But, one
may wish the server to manipulate an internal object of the client.  So, the
client passes a procedure to the server, who may then call it to manipulate
the client's object(s).

A degenerate example being the Sort module being passed the importer's
Compare procedure.  Possibly more common is the one discussed here recently:
    DEFINITION MODULE TerminationHandler;
    PROCEDURE SetTermProc ( p : PROC );
    END TerminationHandler.
-- 
{ mcvax!uunet!oresoft, tektronix!percival!qiclab } !m2xenix!randy  Randy Bush