Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!gatech!cwjcc!hal!nic.MR.NET!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!mcvax!enea!sommar From: sommar@enea.se (Erland Sommarskog) Newsgroups: comp.lang.misc Subject: Re: Call by string (was: B&D) Summary: The answer Message-ID: <4279@enea.se> Date: 29 Jan 89 23:36:46 GMT Organization: ENEA DATA AB, Sweden Lines: 102 It's possible I have missed some responses to my previous article, news flow seems to have been incomplete last week, so there is a risk someone has said what I wanted to hear. Anyway, this article tells how the menu handler I talked of actually was implemented. Some replay for newcomers: In the discussion about Bondage & Discipline langauges I said that a lanaguge like C was a B&D language if I want to call a routine by its name which I have in a string. As an example I gave a menu handler that should be reusable, and with knowledge of the routines in the application within its code, but in a user-loaded database. But before I give the final clues and reveal the answer some comments to other people comments. Beside the articles, I got some mail too. Obviously it would be trivial to implement the menu handler (at least the calling part of it) in Lisp, Scheme and PS-Algol. Then there was a discussion of C. And, yes, in every practical case, we can implement the handler in C. Either we could ship the menu handler with a program that reads the database and from that generates the code that loads a function table. This generated module would then be linked with the system and called at startup. (Or be the startup program itself.) Another solution if you are on Unix if to use nlist(3) that someone pointed out to me. This may not be portable, though. So we can use C, yes, but with a lot of work and inconvenince. Clearly a case of B&D it seems to me. In Modula which has initiation parts in the module we could require that each menu-selection routine loads itself in the initiation part. However, we run the risk theat the application programmer is messing things up. (Typically one such routine is in a module of its, since it more or less an independent program.) It works, but it's still B&D. One language that hasn't been mentioned is MUMPS. In MUMPS you have XECUTE, which simple executes its string argument. (This is an interpreted langauge, so it's easy.) The string could of course be a procedure call as anything else. I thought this could be common in some BASICs too, that's why I originally mentioned BASIC. As a whole such constructs are easy to implement in interpreted langauges. Not so easy in compiled ones. (DEC editor langauge VAXTPU is an example, though.) But the manu handler I talked of is more than just a theoretical idea. It exists. Not written by me, but by the people I currently work with. What language did they use? Clue 1: It hasn't been mentioned in the call-by-string discussion so far, possibly in the previous B&D language, as an example of a B&D langauge. Clue 2: It doesn't have a newsgroup of its own on the net. Some obscure langauge that no one has heard of? Not really. In fact, Clue 3: There is an ANSI standard for it. Latest revision in 1985. Clue 4: The previous ANSI standard is from 1974. Clue 5: (Now it's getting easy.) It's probably the world's most commonly used programming langauge. Answer: COBOL. It's very simple. The construct is: CALL Nisse USING Parameter1, Parameter2.... where Nisse is a string variable. (PIC X(32) or so.) If Nisse is the name of a routine you want to call, you use quotes: CALL "Nisse" USING Parameter1, Parameter2... Compare this with loading function tables and I don't know what in C! Then on the other hand, there are of course things that are simpler to carry out in C. So that's the point: what's is B&D depends on what you want to do. Or in clear text: This talk of B&D is just rubbish. It's interesting to the see in this company of bright people, no one mentions Cobol. Reveales that the net community is maybe not perfectly representable for the programmer community at large. But don't feel ashamed. I didn't know this capability in Cobol a year ago. Addendum on the menu handler: Since I have mentioned it, some more details could be of interest to you. First, it is not written in Cobol, only the routine that calls the application routine is. The rest is in VAX-Pascal. And since our application also is in VAX-Pascal, every application routine needs a little link program in Cobol, since there is a restriction with the CALL identifier construct, saying that the called routine must be another Cobol routine. Actually, we are about to abandon the Cobol solution. The reason is that with Cobol we must link all routines into one image and it gets large, 9000+ blocks. (A block = 512 bytes.) So we're aiming at shareable images instead, which would mean LIB$Find_image_symbol. What we hope to do, but don't know the performance penalty for it yet, is to have every application routine as a shareable image (there are around 200 of them currently), which would mean a fix in such a program can be delivered instantly. And not only the menu handler's code will be application independent, but also the its executeable will be. Talk about modular software! (And before someone ask: yes we will put common routines in shareable images a la run-time libraries as well.) Ahum, if you follow up on this addendum, it's probably not a langauge issue, so look for another newsgroup. -- Erland Sommarskog ENEA Data, Stockholm This signature is not to be quoted. sommar@enea.se