🚀 go-pugleaf

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