emery@MITRE-BEDFORD.ARPA (Emery) (09/16/87)
It should be clear that passing <subprogram>'address to X windows is at best non-portable. (A bit of history: subprogram variables are expressly forbidden by the language requirements, Steelman Paragraph 5D. Don't blame Ada the language for implementing Steelman the Requirements...) There are some significant potential problems in using <subprogram>'address for 'callback'. I've used this trick on Verdix, and noted it as non-portable, but I have found some (perfectly reasonable) problems. In some instances, when procedure foo is invoked by C, I get program_error, due to the elaboration check. In general, an Ada program is responsible for insuring that subprograms get elaborated before they are executed, and the language requires this check. C, or some other non-Ada language, doesn't know how to play this game, and therefore when the C program invoked the Ada subprogram, I got the exception, because the C program didn't know how to tell the Ada program that it had been elaborated. In my instance, I was able to swear on a stack of Ada reference manuals that the subprogram had been elaborated before it was called by C, and applied "pragma suppress(elaboration_check);" to the subprogram, and everything worked ok. The moral of the story is that if you do something non-portable (and possibly erroneous) in Ada, you are not guaranteed that it will always work. For a (potential) standard, such as X windows binding, relying on such tricks as passing <subprogram>'address is clearly unacceptable, due to the portability problems, and some of the other similar problems with the Ada semantics, such as elaboration checks. dave emery MITRE Ada Skills Center emery@mitre-bedford.arpa
4526P@NAVPGS.BITNET ("LT Scott A. Norton, USN") (09/16/87)
( Please excuse me if I have a Pascal accent; I still can't write
Ada without the book open in my lap. )
The disscussion on X-windows, particularly callbacks, has
reawakend my interest in one of the design decisions from
Steelman. The particular feature of Ada that caught my eye, when
I first was learning the language, was that a procedure could not
have a function or another procedure as a formal parameter. I
don't think that "integrate( f, a, b )" is poor software
engineering, but you can't do that directly in Ada. The Ada
solution I saw in one text for integrating a function involved
generics, but that seem kludgy to me. So, I'm asking:
1. Why does Ada not permit functions as formal parameters?
2. Is there some other clean way to model functionals ( functions of
functions ) besides instantionating a generic for each pair of
functional and its argument function?
I realize that sometimes, a programming model that works well in
one context produces serious inconsistancies in another. And so,
we don't see Algol-60 call by name anymore.
LT Scott A. Norton, USN
Naval Postgraduate School
Monterey, CA 93943-5018
4526P@NavPGS.BITNETMFELDMAN@GWUVM.BITNET (Mike Feldman) (09/17/87)
About a year ago there was a _long_ discussion on this forum regarding procedures as parameters in Ada. I don't have the space to archive all of it - did someone else? It was very interesting, sometimes quite theoretical. I hope we don't go through it all again, though...