From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!lll-winken!ames!ncar!gatech!hubcap!billwolf From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.lang.ada Subject: Re: Procedure types and dynamic binding Message-ID: <4055@hubcap.UUCP> Date: 10 Jan 89 03:01:32 GMT References: <5804@medusa.cs.purdue.edu> Sender: news@hubcap.UUCP Reply-To: billwolf@hubcap.clemson.edu List-Id: >From article <5804@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway): >> In more complicated examples parameterizable operations for each Adt >> instance could simplify the program considerably, such as by avoiding >> nested case statements. >> >>> [...] we must provide MAKE_*_PRINT, where * represents an indefinite set >>> of cases. We now see that our old friend, the case statement, is >>> not gone; it has simply taken on a new form. > > This is not entirely correct, since I commented another more general solution. Then let's have a concrete example of this other, more general solution. Be generous with the comments. % Also, it appears unrestricted pointers to subprograms, if thats what % you propose, would provide dynamically checked operations at runtime. % This mechanism is more powerful than statically checked procedural % variables. No, I haven't yet been convinced that subprograms should constitute a separate type; my current position is that subprograms should only be a means by which ADTs and tasks (think of a "main program" as an isolated task...) can be specified. If you can convince us that there is a legitimate need for a subprogram type, then variables of the type and pointers to objects of the type will follow automatically. > Mats Weber writes: >>I think there is one good reason why procedure types should not be included in >>the Ada language: A secure implementation of procedure types must restrict >>their use to global procedures (that is, procedures that are not nested in >>other procedures or tasks), as is the case in Modula-2. Quick question: assuming the idea of a specification is expanded to include all externally accessible objects, what is the source of the insecurity? % Graphical environments provide one example where dynamically parameterizable % objects can be of great assistance. One could parameterize graphical objects % with operations for displaying output, windows, etc., with each instance using % the correct subprogram to implement its display operations. Specific examples, please... Bill Wolfe wtwolfe@hubcap.clemson.edu