brock@tuvie (Inst.f.Prakt.Info 1802) (04/22/89)
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? Just to cite Wirth (3rd ed. p84) [...checking no absoulte safeguard...] >After all, it [module concept] concerns formal, syntactic aspects only; it >does not cover the semantics. <Well, we are here on the razors egde...> Ulrich (ulrich@vip.at UUCP: ...!mcvax!tuvie!vip!ulrich)
fransvo@htsa.uucp (Frans van Otten) (04/24/89)
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? It probably was not intended. I think Wirth thinks of a lot of nice features for a programming language, but doesn't consider all consequences before publishing. The fact that he manages to write a lot of contradictionary things (even within one book) supports this. 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 ? >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? You could call a procedure which is exported from another module. When calling it you give a parameter indicating which (unexported) function should be called. Then, using a case statement or an array of which the component is of the procedure type, you have (almost) the same result. >Just to cite Wirth (3rd ed. p84) [...checking no absoulte safeguard...] >>After all, it [module concept] concerns formal, syntactic aspects only; it >>does not cover the semantics. <Well, we are here on the razors egde...> Don't use single quotes of Wirth ! That is highly dangerous ! Read all of what he writes, then try to figure out what he might have meant using your imagination and logics ! -- Frans van Otten Don't blame me, I'm Algemene Hogeschool Amsterdam just another Modula 2 Technische en Maritieme Faculteit compiler writer ! fransvo@htsa.uucp
randy@m2xenix.UUCP (Randy Bush) (04/25/89)
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
brock@tuvie (Inst.f.Prakt.Info 1802) (04/25/89)
In article <849@htsa.uucp> fransvo@htsa.UUCP (Frans van Otten) writes: >[my remark...] >>you pass the procedure dynamically. I do not believe that this >>feature is really undesirable, however was it really intended? > >It probably was not intended. I think Wirth thinks of a lot of >nice features for a programming language, but doesn't consider >all consequences before publishing. The fact that he manages >to write a lot of contradictionary things (even within one book) can You justify this?? ^^^^^^^^^^^^^^^^^^^^^^ >supports this. 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 ? This is absolutely clear: a local procedure has possibly a scope that globals have not. Why can't a standard >procedure be assigned to a procedure variable ? Because some of them are _generic_. It would really exceed the aim of Modula to allow generic procs in general. Take for example SIZE if You assign SIZE to a procedure variable, which is already typed, the result would be already fixed. Well it would make some sense, but not very much at all... > Ulrich
hal@pur-phy (Hal Chambers) (04/25/89)
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
hoelzle@polya.Stanford.EDU (Urs Hoelzle) (04/25/89)
>are not allowed. Why is it that you are not allowed to assign a >local procedure to a procedure variable ? If you assign a local procedure to a procedure variable and if this procedure accesses (local) variables of the enclosing procedure(s), you will get into trouble when calling it because the activation records of the enclosing procedures do not exist. -Urs
fransvo@htsa.uucp (Frans van Otten) (05/02/89)
Brock@tuvie (Inst.f.Prakt.Info 1802) writes: >Frans van Otten writes: > >>The fact that he manages to write a lot of contradictionary >>things (even within one book)... > >Can You justify this?? I'm not sure if I can justify it. Maybe I put it a bit hard. But fact is that in some stages of the project (building a Modula-2 compiler) I really didn't understand what Wirth meant with some things he wrote (as compared to other things he wrote in the same book). >>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 ? > >This is absolutely clear: a local procedure has possibly a scope >that globals have not. So what ? From within a local procedure it is perfectly possible to call the procedure it is local to, even if this is a local procedure. Within its scope it should be assignable and callable. >>Why can't a standard procedure be assigned to a procedure variable ? > >Because some of them are _generic_. It would really exceed the >aim of Modula to allow generic procs in general. Take for >example SIZE if You assign SIZE to a procedure variable, which >is already typed, the result would be already fixed. Well it >would make some sense, but not very much at all... It does make some sense. And as Wirth didn't make it easy for compiler writers anyway, I don't understand why he makes it (a bit) easier here. -- Frans van Otten Algemene Hogeschool Amsterdam Technische en Maritieme Faculteit fransvo@htsa.uucp