Would an *AdaScript* language be a good / bad idea?

Would an *AdaScript* language be a good / bad idea?

[James Ross]

We have JavaScript and VBScript ...

And then there is Perl, Python, ... etc.

If someone where to create a type-less and interpreted variant of the
Ada language, that for all practical purposes was Ada syntax / rules
without the strong typing -- would that be a useful or worthwhile
thing to do?  Or would it be just obfuscating what Ada is all about?

JR

Re: Would an *AdaScript* language be a good / bad idea?

[James Ross]

On Tue, 14 May 2002 04:51:51 GMT, James Ross wrote:

>If someone where to ...
Arrggg ...   ^^^ were
Syntax was correct but semantically incorrect!!  Either way, poor
English (my first language)!
JR                

Re: Would an *AdaScript* language be a good / bad idea?

[Ingo Marks]

James Ross wrote:

> We have JavaScript and VBScript ...
> 
> And then there is Perl, Python, ... etc.
> 
> If someone where to create a type-less and interpreted variant of the
> Ada language, that for all practical purposes was Ada syntax / rules
> without the strong typing -- would that be a useful or worthwhile
> thing to do?  Or would it be just obfuscating what Ada is all about?

Look at Adaed:

ftp://metalab.unc.edu/pub/Linux/devel/lang/ada

Title:          Ada/Ed
Version:        1.12
Entered-date:   28JUN99
Description:    Ada95 interpreter
Keywords:       ada interpreter
Author:         University of New York
Maintained-by:  Ragnar Hojland Espinosa (ragnar@lightside.ddns.org)
                Ragnar Hojland Espinosa (ragnar@redestb.es)
Primary-site:   metalab.unc.edu /pub/Linux/devel/lang/ada
                906kB Adaed-1.12.tar.gz
Copying-policy: GPL

Regards,
Ingo

Re: Would an *AdaScript* language be a good / bad idea?

[Preben Randhol]

On Tue, 14 May 2002 04:51:51 GMT, James Ross wrote:
> 
> If someone where to create a type-less and interpreted variant of the
> Ada language, that for all practical purposes was Ada syntax / rules
> without the strong typing -- would that be a useful or worthwhile
> thing to do?  Or would it be just obfuscating what Ada is all about?

BUSH ?
http://www.vaxxine.com/pegasoft/bush-down.html

Re: Would an *AdaScript* language be a good / bad idea?

[Robert Dewar]

James Ross <rem.jr@rem.webross.com> wrote in message news:<mr41eu4klae9knk5978o0ru89i5vjc6u2e@4ax.com>...
> We have JavaScript and VBScript ...
> 
> And then there is Perl, Python, ... etc.
> 
> If someone where to create a type-less and interpreted variant of the
> Ada language, that for all practical purposes was Ada syntax / rules
> without the strong typing -- would that be a useful or worthwhile
> thing to do?  Or would it be just obfuscating what Ada is all about?
> 
> JR

One would hazard a guess from the above that someone thinks that
JavaScript has something to do with Java. Why would anyone
possibly think that :-) :-)

At ACT we use (full) Ada as a scripting language all the time. The
advantages of strong typing etc apply perfectly well in this environment
as well. Our only problems with scripts are the old ones written in junk
untyped languages like shell scripts :-)

Re: Would an *AdaScript* language be a good / bad idea?

[Robert Dewar]

Ingo Marks <adv@region-nord.de> wrote in message news:<abqitv$qr9$03$1@news.t-online.com>...
> Look at Adaed:
> 
> ftp://metalab.unc.edu/pub/Linux/devel/lang/ada
> 
> Title:          Ada/Ed
> Version:        1.12
> Entered-date:   28JUN99
> Description:    Ada95 interpreter

This is a highly uninformed comment. For sure, the poster has not followed
his own advice (and looked at Adaed). The fact that Adaed is interpreted 
is entirely irrelevant to this discussion. Adaed is a full implementation
of Ada 83. It is not suitable for any kind of production use, and is even
less suitable as either a scripting language or the basis for a scripting
language.

The notion of high level weakly typed scripting languages and the notion
of interpretation are orthogonal.

There are fully compiled high level weakly typed language implementations
(e.g. SPITBOL/360), and fully interpreted strongly typed low level languages
(e.g. Java!)

Re: Would an *AdaScript* language be a good / bad idea?

[Larry Kilgallen]

In article <5ee5b646.0205140618.2d789fc9@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:
> James Ross <rem.jr@rem.webross.com> wrote in message news:<mr41eu4klae9knk5978o0ru89i5vjc6u2e@4ax.com>...
>> We have JavaScript and VBScript ...
>> 
>> And then there is Perl, Python, ... etc.
>> 
>> If someone where to create a type-less and interpreted variant of the
>> Ada language, that for all practical purposes was Ada syntax / rules
>> without the strong typing -- would that be a useful or worthwhile
>> thing to do?  Or would it be just obfuscating what Ada is all about?
>> 
>> JR
> 
> One would hazard a guess from the above that someone thinks that
> JavaScript has something to do with Java. Why would anyone
> possibly think that :-) :-)

Obviously they are related from my viewpoint.  Both are used in mobile
code to exploit security vulnerabilities.

Re: Would an *AdaScript* language be a good / bad idea?

[Preben Randhol]

On 14 May 2002 07:18:38 -0700, Robert Dewar wrote:
> At ACT we use (full) Ada as a scripting language all the time. The
> advantages of strong typing etc apply perfectly well in this environment
> as well. Our only problems with scripts are the old ones written in junk
> untyped languages like shell scripts :-)

See => http://www.vaxxine.com/pegasoft/bush-down.html

Preben

Re: Would an *AdaScript* language be a good / bad idea?

[Ingo Marks]

Robert Dewar wrote:

> This is a highly uninformed comment. For sure, the poster has not followed
> his own advice (and looked at Adaed). 

Why should I? I am not interested in an Ada 95 interpreter. The LSM file 
claims Ada/Ed to be Ada 95 standard, so the previous poster can simply take 
a look at it and check if it is suitable for him or not. Where is the 
problem?

Re: Would an *AdaScript* language be a good / bad idea?

[Robert Dewar]

Ingo Marks <adv@region-nord.de> wrote in message news:<abro8l$lnp$04$1@news.t-online.com>...
> Robert Dewar wrote:
> 
> > This is a highly uninformed comment. For sure, the poster has not followed
> > his own advice (and looked at Adaed). 
> 
> Why should I? I am not interested in an Ada 95 interpreter. The LSM file 
> claims Ada/Ed to be Ada 95 standard, so the previous poster can simply take 
> a look at it and check if it is suitable for him or not. Where is the 
> problem?

No problem. It is just that

a) AdaEd is completely irrelevant
b) there is no reason to think it might be relevant

The point is that whether the implementation tecnique is compilation or
interpretation is 100% irrelevant to this discussion.

Re: Would an *AdaScript* language be a good / bad idea?

[Per Sandbergs]

 > See => http://www.vaxxine.com/pegasoft/bush-down.html
>
> Preben
Bush i looks good if you are on an Linux/Unix platform but if it is for true
multi platform useI wolud prefer plain compiled Ada with the GNAT-libraries
which is safe and and easy to write portable among platforms.

We have tried evrything (having projects that lasts for 10 or more years)
and the only two things that survives for a while is Ada-code provided that
ther is a consistent set of libraries and while on the same platform the
native shell which in the Win32 case happend to be ".bat" files or on AIX
korrn-shell.

This means that we are looking more and more on Ada as long term "scripting"
language.

/Per Sandberg

Re: Would an *AdaScript* language be a good / bad idea?

[Preben Randhol]

On Wed, 15 May 2002 08:33:02 +0200, Per Sandbergs wrote:
> 
> This means that we are looking more and more on Ada as long term "scripting"
> language.

I agree. A friend asked if I could help him analyse some logs and I
ended up writing a small program in Ada to do the task. It was much
faster than starting to learn awk or other similar tools to do it.

Preben

Re: Would an *AdaScript* language be a good / bad idea?

[Marc A. Criley]

Per Sandbergs wrote:
> 
> We have tried evrything (having projects that lasts for 10 or more years)
> and the only two things that survives for a while is Ada-code provided that
> ther is a consistent set of libraries and while on the same platform the
> native shell which in the Win32 case happend to be ".bat" files or on AIX
> korrn-shell.
> 
> This means that we are looking more and more on Ada as long term "scripting"
> language.

I've used Ada as a scripting language on more than one occasion as
well.  One tool I found invaluable in support of this is James Rogers'
Ada binding to pipes (http://www.adapower.com/reuse/pipes.html).  At its
simplest, you can use it to execute a system command, then read in and
process the result of executing that command as if it were a text file. 
Makes Ada-based scripting very simple (and Pipes works on both Unix and
Windows).

Marc A. Criley
Consultant
Quadrus Corporation
www.quadruscorp.com

Re: Would an *AdaScript* language be a good / bad idea?

[Bill Tate]

James Ross <rem.jr@rem.webross.com> wrote in message news:<mr41eu4klae9knk5978o0ru89i5vjc6u2e@4ax.com>...
> We have JavaScript and VBScript ...
> 
> And then there is Perl, Python, ... etc.
> 
> If someone where to create a type-less and interpreted variant of the
> Ada language, that for all practical purposes was Ada syntax / rules
> without the strong typing -- would that be a useful or worthwhile
> thing to do?  Or would it be just obfuscating what Ada is all about?
> 
> JR

Perhaps http://pyada.sourceforge.net/ would be of some interest. 
Gerhard Haring's page is still available on-line. While its not
currently being maintained, I don't imagine there would be a
resistance to someone pursuing it further.  As to whether it would be
worthwhile or not - others are better suited to answering that
question.

Re: Would an *AdaScript* language be a good / bad idea?

[Steve Doiel]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0205140618.2d789fc9@posting.google.com...
[snip]
>
> At ACT we use (full) Ada as a scripting language all the time. The
> advantages of strong typing etc apply perfectly well in this environment
> as well. Our only problems with scripts are the old ones written in junk
> untyped languages like shell scripts :-)

Your definition of "scripting language" is certainly different from mine.  I
did a google search to find a definition and found:
http://hotwired.lycos.com/webmonkey/glossary/scripting.html
 which is consistant with how I would describe a scripting language.

While I agree that anything that may be done with a scripting language may
also be done with a general purpose compiled language, IMHO they are not the
same thing.

SteveD

Re: Would an *AdaScript* language be a good / bad idea?

[Preben Randhol]

On Wed, 15 May 2002 12:56:39 GMT, Steve Doiel wrote:
> "Robert Dewar" <dewar@gnat.com> wrote in message
> news:5ee5b646.0205140618.2d789fc9@posting.google.com...
> [snip]
>>
>> At ACT we use (full) Ada as a scripting language all the time. The
                            ^^^^

> Your definition of "scripting language" is certainly different from mine.  I
> did a google search to find a definition and found:
> http://hotwired.lycos.com/webmonkey/glossary/scripting.html
>  which is consistant with how I would describe a scripting language.
> 
> While I agree that anything that may be done with a scripting language may
> also be done with a general purpose compiled language, IMHO they are not the
> same thing.

I don't think he said that either.

Preben

Re: Would an *AdaScript* language be a good / bad idea?

[Robert Dewar]

"Steve Doiel" <nospam_steved94@attbi.com> wrote in message news:<bWsE8.34889$UV4.7322@rwcrnsc54>...
> "Robert Dewar" <dewar@gnat.com> wrote in message
> news:5ee5b646.0205140618.2d789fc9@posting.google.com...

> Your definition of "scripting language" is certainly different from mine.  I
> did a google search to find a definition and found:
> http://hotwired.lycos.com/webmonkey/glossary/scripting.html
>  which is consistant with how I would describe a scripting language.

Here is the quote in question:

 A scripting language is a simple programming language used to write
an
 executable list of commands, called a script. A scripting language is
a high-
 level command language that is interpreted rather than compiled, and
is
 translated on the fly rather than first translated entirely.
JavaScript,
 Perl, VBscript, and AppleScript are scripting languages rather than
general-
 purpose programming languages. 

I find this definition silly. All these languages can perfectly well
be compiled, and any general purpose programming language can be
interpreted.
The difference between interpretetation and compilation is an
implementation
detail that has nothing whatever to do with the language.

For the most part, the distinction between scripting languages and
general
purpose programming languages is bogus (and ends up being an excuse
for some
extraordinarily poor language design flying under the "scripting
language"
banner).

When I say that we use Ada "as a" scripting language, what I mean is
that we
use Ada as a (perfectly satisfactory) language for achieving the kind
of thing
that is often done in a scripting language (by the way such languages
often
come along not only with bad designs, but bad software practices,
including
sloppy design and lack of proper documentation). 

To the extent that scripting language means very-high-level-language
in the
sense of SETL or SNOBOL4 or other garbage collected dynamic languages
with
complex data structures, then that's interesting, but such features
are by
no means essential for writing an "executable series of commands".

P.S. If you disagree with the claim that these languages can be
compiled, please first read my article in SP&E 1977 on SNOBOL-4
implementation.

> While I agree that anything that may be done with a scripting language may
> also be done with a general purpose compiled language, IMHO they are not the
> same thing.

If you want to adopt the above definition, then the main thing that
makes an
important difference to you is that the language must be interpreted.
But how
can this possibly per se be an advantage. You might want fast
compilation,
but that's certainly possible (SPTIBOL/370 compiles at tens of
millions of
lines a minute, essentially instantaneous, even for quite complex
operations).
You might want high level language features (but that's achievable in
compiled
implementations. Perhaps you want very slow execution -- true, that is
harder
to achieve without inefficient interpretation :-) :-)

Re: Would an *AdaScript* language be a good / bad idea?

[Darren New]

Robert Dewar wrote:
> I find this definition silly. All these languages can perfectly well
> be compiled,

Errr, I don't know about applescript of vbscript, but both Perl and
Python (and Tcl and ...) have operators that run code that has been
generated at runtime. So while it's possible to compile the code, you
can't (for example) eliminate the compiler from the runtime.

> and any general purpose programming language can be
> interpreted.

True.

> The difference between interpretetation and compilation is an
> implementation
> detail that has nothing whatever to do with the language.

Well, some people look at a language and say "there has never been a
compiled version of this", and from that describe it as "an interpreted
language", for example. Even tho it is theoretically possible to compile
the language, if nobody ever did, then it's not all that silly to say
"it's an interpreted language."

If you're talking about "AdaScript" as an untyped version of Ada, why
would you even consider such a thing unless the point was to make it
easier to interpret? I mean, there's already Ada compilers out there.
What would be the advantage of making a compiler for an Ada-like
language, but not as good?

> For the most part, the distinction between scripting languages and
> general
> purpose programming languages is bogus (and ends up being an excuse

Another definition often used is that scripting languages are "glue"
languages, and stand poorly on their own. You wouldn't write a video
driver or windowing system in Perl, nor an SQL engine, but you'd
certainly write the thing that glues the windowing system to the SQL
engine in Perl.  You *would* write the SQL engine and video driver in
Ada, but maybe not the rapidly-changing-don't-know-what-I-want part in
Ada. You wouldn't write something that renders HTML or reads the mouse
port in Javascript, but you would deal with the interactions between
those two.

Another feature of scripting languages is the almost casual use of
dynamically loaded code. It's not uncommon at all to calculate at run
time what executable code will be loaded, for example. (Think "java
applets" if you aren't familiar with programming other scripting
languages.) I think this is fairly difficult to do in Ada.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Would an *AdaScript* language be a good / bad idea?

[Wes Groleau]

> Errr, I don't know about applescript of vbscript, but both Perl and
> Python (and Tcl and ...) have operators that run code that has been
> generated at runtime. So while it's possible to compile the code, you
> can't (for example) eliminate the compiler from the runtime......
> 
> Another feature of scripting languages is the almost casual use of
> dynamically loaded code. It's not uncommon at all to calculate at run
> time what executable code will be loaded, for example. (Think "java
> applets" if you aren't familiar with programming other scripting
> languages.) I think this is fairly difficult to do in Ada.

Many Ada implementations already have a way to execute
outside commands.  Not necessarily what I'd recommend,
but an Ada program can write a program with Text_IO,
call the compilers, and then call the new program.

Self-modifying code?  Write a replacement for one of your
own modules, compile it, link a new version of yourself,
save state to a file, call the new version, and exit.

Kludgey, but it can be done.  And it wouldn't be difficult.

I once talked someone out of translating into
Pascal a BASIC program that did stuff like that.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Would an *AdaScript* language be a good / bad idea?

[Darren New]

Wes Groleau wrote:
> > languages.) I think this is fairly difficult to do in Ada.

> Kludgey, but it can be done.  And it wouldn't be difficult.

Errr, well, being used to scripting languages, I'd call both of these
"difficult" compared to what you typically do with a scripting language.
Obviously it's not impossible, or you wouldn't be able to write an OS in
Ada, but it's certainly a lot easier to say something like

  source $name_of_file

or 

  MyClass x = new CodeLoader("xyz.class");

or something like that than it is to write the support code it would
take to find an arbitrary Ada source, compile it in a cross-platform
way, write out all your state, invoke the compiled program, and then
somehow clean up all that afterwards, taking care to catch any errors.

Sure, you *can* do it. But how many people *have* done
dynamically-loaded code under Ada, compared to the number of people who
use Tcl or Python or etc, all of which have dynamically-loaded code as
the fundamental way of running a program? Note that in Tcl and Python,
the equivalent of "with" is to dynamically load sources, so it's
happening *all the time*. :-)

Again, this isn't a cut on Ada in any sense. Just pointing out some of
the features of "scripting languages" that aren't well-supported in Ada.
 
-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Would an *AdaScript* language be a good / bad idea?

[Wes Groleau]

> Errr, well, being used to scripting languages, I'd call both of these
> "difficult" compared to what you typically do with a scripting language.
> Obviously it's not impossible, or you wouldn't be able to write an OS in
> Ada, but it's certainly a lot easier to say something like
> 
>   source $name_of_file
> 
> or
> 
>   MyClass x = new CodeLoader("xyz.class");
> 
> or something like that than it is to write the support code it would
> take to find an arbitrary Ada source, compile it in a cross-platform
> way, write out all your state, invoke the compiled program, and then
> somehow clean up all that afterwards, taking care to catch any errors.

You listed five steps, but your examples
only do one of the steps--invoke.

And I don't see either example as being more difficult than

  Invoke (Name_Of_File);

Sure, someone had to write

  procedure Invoke (Command : String);
  pragma Import (C, Invoke, "exec");
  -- this won't work, it's merely illustrative

but as I said, many implementations are sold
with the equivalent already built-in.

What about the other steps?  Is either incredibly harder
than the other?

Building:

   print OUTPUT ("$Var = \$Var + \$Latest;\n");  # perl ?

   Put_Line (Output, "Var := Var + Latest;" );   # Ada

Compile and link:

   # scripts don't need it, so penalize compilers one point

   Invoke (Make_Command & " " & Source_File_Name);   # Ada
   -- not platform independent, so another one in favor of
   -- interpreters or JIT compilers.

Run:

   source New_Script_Name                       # csh

   Invoke (Exec_Name_Rule (Source_File_Name));  # Ada

Saving state:

   No example--it varies in difficulty according to
   the application, not the language.  Also, it's not
   necessary unless you are "modifying" the currently
   running program.

Cleaning up:

   rm $scratchpad

   Invoke ("rm Scratchpad_Name");

   (Actually, difficulty of--or need for--cleanup
   depends on the application, not the language.)

Error handling:

   No scripting example, because it's too much work to write
   the equivalent of

   exception

      when E : others =>

   Not to mention the code to detect the errors!


Summary (higher means harder):

Task                  Compiled Ada   Interpreted shell
------------------    ------------   -----------------
Building:                   1               1
Compile and link:           2               0
Run:                        1               1
Saving state:               *               *
Cleaning up:                *               *
Error handling:             1               2-5**
===============           ====            ========
TOTAL                       5               4-9

* neither a language issue nor a compiler/interpreter issue

** a language issue, but not a compiler/interpreter issue

So, I'm not saying one _should_ use Ada for stuff like this,
I'm just saying it's NOT difficult.  Long post for two lines, eh?


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Would an *AdaScript* language be a good / bad idea?

[Darren New]

Wes Groleau wrote:
> You listed five steps, but your examples
> only do one of the steps--invoke.

Because I don't need those other four steps in Ada.
 
> And I don't see either example as being more difficult than 
>   Invoke (Name_Of_File);

Um.... But that doesn't do the same thing. What do you think the semantics
of "Invoke" are? Compiling a program and executing it? 

Note that both of my examples are basically the equivalent of "with" in Ada,
not "system()" in C.

> Sure, someone had to write
> 
>   procedure Invoke (Command : String);
>   pragma Import (C, Invoke, "exec");
>   -- this won't work, it's merely illustrative
> 
> but as I said, many implementations are sold
> with the equivalent already built-in.
> 
> What about the other steps?  Is either incredibly harder
> than the other?

Yes, because it doesn't do the same thing.

> Saving state:
> 
>    No example--it varies in difficulty according to
>    the application, not the language.  Also, it's not
>    necessary unless you are "modifying" the currently
>    running program.

Well, my point is all these things modify the currently-running program, so
yeah, it is a lot harder. If you haven't done a lot of work with this type
of scripting language, then I suspect you aren't really following what I'm
saying here.
 
The rest snipped, because I'm not sure you're making any sense.

> So, I'm not saying one _should_ use Ada for stuff like this,
> I'm just saying it's NOT difficult.  Long post for two lines, eh?

I disagree. Write a piece of Ada code that declares a new type at run-time
based on a user's input, perhaps a derived type of a tagged type, and loads
it into the currently running program, instantiates it, and sticks it into
an array of heterogenous objects all derived from that type, dynamically
dispatching to them. Note that "stop everything, rewrite the program,
recompile, and start up again" is not acceptable. 

In scripting languages, this is done all the time. Roll-overs in Javascript
get dynamically loaded into your web browser to pop up annoying windows. Tcl
applications load the code for building database queries by querying the
database and reading the code therefrom. Java interpreters suck new classes
over the net.

How would you do it in Ada? I don't believe that "save the state of the
currently running program and invoke a new program so it starts up in the
same place as the old one" can be made an Ada library. If it can, that would
be really cool, because it would solve a problem I've been thinking about
for a while in an unrelated field. But I haven't figured out any way of
doing that without knowing what part of the program constitutes the "current
state".

There's a tremendous difference between linking to DLLs, generating code on
the fly, and the "exec" system call.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Would an *AdaScript* language be a good / bad idea?

[Darren New]

Darren New wrote:
> 
> Wes Groleau wrote:
> > You listed five steps, but your examples
> > only do one of the steps--invoke.
> 
> Because I don't need those other four steps in Ada.

Sorry. Of course I meant, I don't need those other four steps except in Ada.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Would an *AdaScript* language be a good / bad idea?

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> <snip> Write a piece of Ada code that declares a new type at run-time
> based on a user's input, perhaps a derived type of a tagged type, and loads
> it into the currently running program, instantiates it, and sticks it into
> an array of heterogenous objects all derived from that type, dynamically
> dispatching to them. Note that "stop everything, rewrite the program,
> recompile, and start up again" is not acceptable. 

Right, Ada is not designed for this. Although the distributed annex
comes close; you could change out a partition without restarting the
other partitions.

You can also get close via DLLs on Windows (and shared libraries on
other OS's?), but not with full dispatching.

> In scripting languages, this is done all the time. 

Perhaps there is a better term for this than "scripting language". For
example, Java has this capability, and it is _not_ a "scripting
language" by your definition (at least, I don't think it is :). Lisp
has this feature; is that a "scripting language"?

And Ada compiled to the JVM would have this capability; that would be
interesting to play with.

Perhaps "dynamic code loading" is a good phrase for this feature.

> How would you do it in Ada? I don't believe that "save the state of the
> currently running program and invoke a new program so it starts up in the
> same place as the old one" can be made an Ada library. 

For some set of Ada programs, you can clearly do this. Not for an
arbitrary one. Perhaps not for interesting programs :).

> If it can, that would be really cool, because it would solve a
> problem I've been thinking about for a while in an unrelated field.
> But I haven't figured out any way of doing that without knowing what
> part of the program constitutes the "current state".

I gather you want the "save the state" operation to be provided by the
compiler, not by the programmer. I guess that is true in the languages
that have "dynamic code loading". Clearly, if the user provides it,
you can solve a wider range of problems.

> There's a tremendous difference between linking to DLLs, generating
> code on the fly, and the "exec" system call.

Agreed.

-- 
-- Stephe

Re: Would an *AdaScript* language be a good / bad idea?

[Darren New]

Stephen Leake wrote:
> Perhaps there is a better term for this than "scripting language". For
> example, Java has this capability, and it is _not_ a "scripting
> language" by your definition (at least, I don't think it is :). Lisp
> has this feature; is that a "scripting language"?

I don't think "scripting language" is sufficiently precise a term that you
can draw a circle that encompasses all and only scripting languages. I don't
think there's any one feature that defines what is and is not a scripting
language. Clearly, Ada is not. Clearly, /bin/bash is. Lisp and Java probably
fall in the middle somewhere. I was just saying that the glue orientation,
the dynamic code loading, and a few other features are generally usually
found in scripting languages and usually not in non-scripting languages. The
idea of "adascript" being just like Ada only without the type declarations
or just like Ada only interpreted wouldn't necessarily be a scripting
language.

My point was that I don't think an AdaScript that's the same as Ada only
without any type declarations makes sense. If you managed to make it make
sense, it wouldn't be useful, because people don't use scripting languages
solely because of weak typing. (And many languages that could arguably be
called scripting languages or close to it are strongly typed, such as Java,
Python, Smalltalk, etc.) The point of having the weak typing is to (a) make
the source smaller so it loads faster over the net, and (b) to build in all
kinds of things that don't make sense in a general-purpose language.
Consider elisp's access to buffers and such, and javascript's access to the
current web page, and etc.

If you want to consider "AdaScript", I'd suggest first ask "what would I add
to make it attractive as a scripting language", rather than asking "what
need I take away from Ada."  Once you decide what features you want to add,
you can ask what features of Ada make those new features unusually difficult
to implement.

> > If it can, that would be really cool, because it would solve a
> > problem I've been thinking about for a while in an unrelated field.
> > But I haven't figured out any way of doing that without knowing what
> > part of the program constitutes the "current state".
> 
> I gather you want the "save the state" operation to be provided by the
> compiler, not by the programmer. I guess that is true in the languages
> that have "dynamic code loading".

No. The state doesn't get saved in that case, because you're not starting a
new program. You're just adding new code to the current program. You don't
need to "save the state" of a program loading new code in Tcl or Java any
more than you need to 'save the state" of a program before loading a DLL in
Windows or before opening a data file in Ada.

> Although the distributed annex
> comes close; you could change out a partition without restarting the
> other partitions.

I'm curious how you would do this. Is it actually possible to do this within
the language, or would one have to (for example, in GNAT) sigkill the
process running the part you want to change or something? In other words,
from my very limited understanding, it seems like the distributed annex is
more about distribution and less about dynamic interconnection. I may have
just not played with it enough to get the "aha" there.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Would an *AdaScript* language be a good / bad idea?

[Pascal Obry]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> Darren New <dnew@san.rr.com> writes:
> 
> > <snip> Write a piece of Ada code that declares a new type at run-time
> > based on a user's input, perhaps a derived type of a tagged type, and loads
> > it into the currently running program, instantiates it, and sticks it into
> > an array of heterogenous objects all derived from that type, dynamically
> > dispatching to them. Note that "stop everything, rewrite the program,
> > recompile, and start up again" is not acceptable. 
> 
> Right, Ada is not designed for this. Although the distributed annex
> comes close; you could change out a partition without restarting the
> other partitions.

I'm not sure this is true. To use this object the type must be known at
_compile_ time. Darren said "a new type at run-time", and to this question
I would answer no. The distributed annexe does not help here.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Would an *AdaScript* language be a good / bad idea?

[Darren New]

Pascal Obry wrote:
> > Right, Ada is not designed for this. Although the distributed annex
> > comes close; you could change out a partition without restarting the
> > other partitions.
> 
> I'm not sure this is true. To use this object the type must be known at
> _compile_ time. Darren said "a new type at run-time", and to this question
> I would answer no. The distributed annexe does not help here.

Well, think of how Java does it. Your partition could define a tagged type
called Transaction, and you could load up different partitions with derived
types called AddTransaction, RemoveTransaction, etc as you develop them.

Still messier than just sourcing an additional file, mind. I do things all
the time like
  Read the name of the requested transaction.
  See if the file "trans-$name.tcl" exists.
  If not, return an error.
  Otherwise, load trans-$name.tcl and invoke the trans_$name procedure,
    passing all the arguments from the transaction.

I don't have to change anything to add a transaction. Just put the file in
the code directory. :-) *That* is the sort of thing people do with scripting
languages. 

But you could do a similar thing with the distributed annex. Recompile the
"handle transaction" code to add the new transaction and add it to the
name->access_to_procedure table, and then at the end of the current
transaction, kill the old partition and start the new partition and somehow
get them hooked up again. Not sure how you'd actually do this, using (say)
GNAT, tho.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Would an *AdaScript* language be a good / bad idea?

[Pascal Obry]

Darren New <dnew@san.rr.com> writes:

> Pascal Obry wrote:
> > I'm not sure this is true. To use this object the type must be known at
> > _compile_ time. Darren said "a new type at run-time", and to this question
> > I would answer no. The distributed annexe does not help here.
> 
> Well, think of how Java does it. Your partition could define a tagged type
> called Transaction, and you could load up different partitions with derived
> types called AddTransaction, RemoveTransaction, etc as you develop them.

In Java of course, since precisely, it is possible to load dynamically new
classes.

> I don't have to change anything to add a transaction. Just put the file in
> the code directory. :-) *That* is the sort of thing people do with scripting
> languages. 

I have no problem with scripting languages, this was not my point :)

> But you could do a similar thing with the distributed annex. Recompile the
                                                               ^^^^^^^^

Ok "recompile", but this is not at runtime :) So I think we are on the same
wavelength.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Would an *AdaScript* language be a good / bad idea?

[Gerhard Häring]

Bill Tate wrote in comp.lang.ada:
> James Ross <rem.jr@rem.webross.com> wrote in message news:<mr41eu4klae9knk5978o0ru89i5vjc6u2e@4ax.com>...
>> We have JavaScript and VBScript ...
>> 
>> And then there is Perl, Python, ... etc.
>> 
>> If someone where to create a type-less and interpreted variant of the
>> Ada language, that for all practical purposes was Ada syntax / rules
>> without the strong typing -- would that be a useful or worthwhile
>> thing to do?  Or would it be just obfuscating what Ada is all about?
>> 
>> JR
> 
> Perhaps http://pyada.sourceforge.net/ would be of some interest. 
> Gerhard Haring's page is still available on-line. While its not
> currently being maintained, I don't imagine there would be a
> resistance to someone pursuing it further.

If anybody wants to pursue this and has any questions, don't hesitate
to email me directly. I'm currently not following c.l.a.

> As to whether it would be worthwhile or not - others are better
> suited to answering that question.

Depends on what you type of scripting you want, something like pyAda
is certainly great for embedding Python/Tcl/.. as a scripting language
into your application.

But if you want to call external programs or manipulate files, that's
where the well-known scripting languages are IMO far better suited
than strongly typed languages like Ada, which also have inferior
library support for these kind of tasks (only considering what
standard Ada provides).

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: Would an *AdaScript* language be a good / bad idea?

[Wes Groleau]

> > And I don't see either example as being more difficult than
> >   Invoke (Name_Of_File);
> 
> Um.... But that doesn't do the same thing. What do you think the semantics

If Name_Of_File identifies the linked program, it does the same thing.

> of "Invoke" are? Compiling a program and executing it?

No, just what I said they are:

> >   procedure Invoke (Command : String);
> >   pragma Import (C, Invoke, "exec");
> >   -- this won't work, it's merely illustrative


> Well, my point is all these things modify the currently-running program, so
> yeah, it is a lot harder. If you haven't done a lot of work with this type
> of scripting language, then I suspect you aren't really following what I'm
> saying here.

After 10-15 years of Ada and other languages, including the usual
incidental scripting, and having (unfortunately) for the last
three having ksh, perl, and TCL be 75% of my job, I suspect I'm not
is ignorant as you think.

> The rest snipped, because I'm not sure you're making any sense.

Maybe you need to read a little more carefully.

> There's a tremendous difference between linking to DLLs, generating code on
> the fly, and the "exec" system call.

It's certainly true that the extreme case I snipped
is not appropriate for Ada.  That doesn't make the
lesser cases in the previous posts difficult.

Arguing with you is aiming at a rapidly moving target.

"There's a tremendous difference between" the

  source $Filename

that I challenged two posts back and the

> ... declares a new type at run-time
> based on a user's input, perhaps a derived type of a tagged type, and loads
> it into the currently running program, instantiates it, and sticks it into
> an array of heterogenous objects all derived from that type, dynamically
> dispatching to them. ...

of the last post.  Although I could do that in Ada,
too--but again, I would not recommend it.  Because
when you go that far, you ARE getting quite difficult.
And quite inefficient.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Would an *AdaScript* language be a good / bad idea?

[Wes Groleau]

> > Because I don't need those other four steps in Ada.
> 
> Sorry. Of course I meant, I don't need those other four steps except in Ada.

If your script didn't write the script you are sourcing,
then your Ada program doesn't need to write the program
it invokes.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Would an *AdaScript* language be a good / bad idea?

[Darren New]

Wes Groleau wrote:
> 
> > > Because I don't need those other four steps in Ada.
> >
> > Sorry. Of course I meant, I don't need those other four steps except in Ada.
> 
> If your script didn't write the script you are sourcing,
> then your Ada program doesn't need to write the program
> it invokes.

Um, right. If you look, I didn't say you did.

> > take to find an arbitrary Ada source, compile it in a cross-platform
> > way, write out all your state, invoke the compiled program, and then
> > somehow clean up all that afterwards, taking care to catch any errors.

I didn't say anything about creating the source there.

> You listed five steps, but your examples
> only do one of the steps--invoke.

That's because what you need to do in Ada is incomparible to the ease with
which you can do it in a typical scripting language. In Tcl, Perl, and
Python, for example, there's no need to write out the state, compile the
program, invoke a program, or clean up, because you don't need to do that to
add executable code to a process at runtime.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Would an *AdaScript* language be a good / bad idea?

[Darren New]

Wes Groleau wrote:
> 
> > > And I don't see either example as being more difficult than
> > >   Invoke (Name_Of_File);
> >
> > Um.... But that doesn't do the same thing. What do you think the semantics
> 
> If Name_Of_File identifies the linked program, it does the same thing.

Uh, no. Your "invoke" replaces the currently executing program with a new
one. Tcl's "source" doesn't. 

> > Well, my point is all these things modify the currently-running program, so
> > yeah, it is a lot harder. If you haven't done a lot of work with this type
> > of scripting language, then I suspect you aren't really following what I'm
> > saying here.
> 
> After 10-15 years of Ada and other languages, including the usual
> incidental scripting, and having (unfortunately) for the last
> three having ksh, perl, and TCL be 75% of my job, I suspect I'm not
> is ignorant as you think.

I didn't say you were. I said "if". Now I'm trying to figure out why, if
you've used Tcl as extensively as you claim, you don't understand the
difference between Tcl's [source] command and Tcl's [exec] command.

> > The rest snipped, because I'm not sure you're making any sense.
> Maybe you need to read a little more carefully.

Then maybe you can explain why exec() is at all like [source].  

You're saying "it's simple to compile an Ada program and invoke it from
inside another Ada program", which I'm not arguing. I'm not discussing that
at all. I'm discussing adding code to the currently running process.
 
> > There's a tremendous difference between linking to DLLs, generating code on
> > the fly, and the "exec" system call.
> 
> It's certainly true that the extreme case I snipped
> is not appropriate for Ada.  That doesn't make the
> lesser cases in the previous posts difficult.

No, agreed. 

> Arguing with you is aiming at a rapidly moving target.

Actually, I think it's more like I make a statement, you interpret it thru
an Ada filter, and then say I'm wrong. When I clarify why what you're saying
isn't what I'm saying, you think I'm changing what I said.

For example, my comment that started this whole bit was 
> Another feature of scripting languages is the almost casual use of
> dynamically loaded code. It's not uncommon at all to calculate at run
> time what executable code will be loaded, for example. (Think "java
> applets" if you aren't familiar with programming other scripting
> languages.) I think this is fairly difficult to do in Ada.

Dynamically loaded code isn't "exec". I don't expect to restart my browser
every time I go to a different web page that has an applet on it. Where you
go from "dynamically loaded code" to "this is easy, just use exec" I'm not
sure.

 
> "There's a tremendous difference between" the
> 
>   source $Filename
> 
> that I challenged two posts back and the
> 
> > ... declares a new type at run-time
> > based on a user's input, perhaps a derived type of a tagged type, and loads
> > it into the currently running program, instantiates it, and sticks it into
> > an array of heterogenous objects all derived from that type, dynamically
> > dispatching to them. ...
> 
> of the last post. 

Errr, no. There's not. What do you think [package require] does?

> Although I could do that in Ada,
> too--but again, I would not recommend it.  Because
> when you go that far, you ARE getting quite difficult.
> And quite inefficient.

Except the exact same mechanism does both, in many scripting languages.

Nuff said. This is getting silly.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Would an *AdaScript* language be a good / bad idea?

[Robert Dewar]

Darren New <dnew@san.rr.com> wrote in message news:<3CE3D8B4.C272C737@san.rr.com>...
> Robert Dewar wrote:
> > I find this definition silly. All these languages can perfectly well
> > be compiled,
> 
> Errr, I don't know about applescript of vbscript, but both Perl and
> Python (and Tcl and ...) have operators that run code that has been
> generated at runtime. So while it's possible to compile the code, you
> can't (for example) eliminate the compiler from the runtime.

Of course! In SPITBOL, the compiler is of course around at runtime
to implement the CODE and EVAL functions. So what? In SPITBOL/370,
these functions result in the dynamic creation of compiled executable
garbage collectable code that wanders around in the heap :-)

Re: Would an *AdaScript* language be a good / bad idea?

[Robert Dewar]

Darren New <dnew@san.rr.com> wrote in message news:<3CE3D8B4.C272C737@san.rr.com>...

> Another feature of scripting languages is the almost casual use of
> dynamically loaded code. It's not uncommon at all to calculate at run
> time what executable code will be loaded, for example. (Think "java
> applets" if you aren't familiar with programming other scripting
> languages.) I think this is fairly difficult to do in Ada.

Again, this is just a particular feature of languages, that some languages
have and others don't. COBOL for example has dynamic binding of all procedure
calls, and dynamic loading of code, and always has, and it is routine in the
COBOL world to add new modules dynamically to a running program without
stopping it. But most people would hardly consider COBOL to be a scripting
language.

I still find the term very dubious and not particularly useful.

Re: Would an *AdaScript* language be a good / bad idea?

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> At ACT we use (full) Ada as a scripting language all the time. The
> advantages of strong typing etc apply perfectly well in this environment
> as well. Our only problems with scripts are the old ones written in junk
> untyped languages like shell scripts :-)

Hmm, what about SPITBOL? ;-)

Re: Would an *AdaScript* language be a good / bad idea?

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> For the most part, the distinction between scripting languages and
> general purpose programming languages is bogus (and ends up being an
> excuse for some extraordinarily poor language design flying under
> the "scripting language" banner).

;-)

As a rule of thumb, most people consider something to be a scripting
language if it fulfills one or more of the following criteria:

  - You can run the script as if no compilation is necessary.

  - It is not feasible to implement the run-time environment mostly in
    the language itself (either due to language constraints or
    performance).

  - There is no proper specification of the language.

  - There is only one widely accepted implementation, which mostly
    avoids compatibility problems.

  - The language evolves constantly, often losing backwards
    compatibility.

  - It is possible to embed a language implementation in other, "real"
    programs.

  - There is no such thing as erroneous execution.

Of course, these rules are completely bogus, too, but I think those
rules catch the spirit of scripting languages rather well.

> When I say that we use Ada "as a" scripting language, what I mean is
> that we use Ada as a (perfectly satisfactory) language for achieving
> the kind of thing that is often done in a scripting language (by the
> way such languages often come along not only with bad designs, but
> bad software practices, including sloppy design and lack of proper
> documentation).

One nice thing about those scripting languages is the lack of
erroneous execution.  For example, I'm quite confident that the dozens
of Emacs Lisp packages I use do not crash Emacs.  I might lose some
data in the current buffer if I use them, but unless the package is
extremely poorly written, I won't lose an important message I'm typing
in another buffer.

That's why I think that dynamically loading, say, Ada code in an
editor instead of using a scripting language is not advantageous per
se.

Re: Would an *AdaScript* language be a good / bad idea?

[Preben Randhol]

On Tue, 21 May 2002 22:48:39 +0200, Florian Weimer wrote:
> As a rule of thumb, most people consider something to be a scripting
> language if it fulfills one or more of the following criteria:

Agreeing with your point I would say that using Ada as a "scripting
language" is when you write write-once-never-read hacks to do a simple
task like manipulating some text or other. I have done this several
times and surprisingly it is very easy to do fast and
correctly in Ada.


-- 
Preben

Re: Would an *AdaScript* language be a good / bad idea?

[Pascal Obry]

Preben Randhol <randhol+abuse@pvv.org> writes:

> Agreeing with your point I would say that using Ada as a "scripting
> language" is when you write write-once-never-read hacks to do a simple
> task like manipulating some text or other. I have done this several
> times and surprisingly it is very easy to do fast and
> correctly in Ada.

In Ada maybe, with GNAT for sure with:

        GNAT.Command_Line
        GNAT.Directory_Operations
        GNAT.Directory_Operations.Iteration
        GNAT.Dynamic_Tables
        GNAT.Regexp
        GNAT.Regpat
        GNAT.Spitbol
        GNAT.AWK
        GNAT.Expect

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Would an *AdaScript* language be a good / bad idea?

[Preben Randhol]

On 22 May 2002 09:17:14 +0200, Pascal Obry wrote:
> In Ada maybe, with GNAT for sure with:
> 
>         GNAT.Command_Line
>         GNAT.Directory_Operations
>         GNAT.Directory_Operations.Iteration
>         GNAT.Dynamic_Tables
>         GNAT.Regexp
>         GNAT.Regpat
>         GNAT.Spitbol
>         GNAT.AWK
>         GNAT.Expect

Yes :-)

Preben

Re: Would an *AdaScript* language be a good / bad idea?

[David Thompson]

Robert Dewar <dewar@gnat.com> wrote :
> Darren New <dnew@san.rr.com> wrote in message
news:<3CE3D8B4.C272C737@san.rr.com>...
>
> > Another feature of scripting languages is the almost casual use of
> > dynamically loaded code. It's not uncommon at all to calculate at run
> > time what executable code will be loaded, for example. ...

> Again, this is just a particular feature of languages, that some languages
> have and others don't. COBOL for example has dynamic binding of all procedure
> calls, and dynamic loading of code, and always has, and it is routine in the
> COBOL world to add new modules dynamically to a running program without
> stopping it. But most people would hardly consider COBOL to be a scripting
> language.
>
COBOL-the-language has provision for overlay linking/loading
(segments), and call to name-chosen-at-runtime program-unit
(= procedure, COBOL doesn't have user-written value-returning
functions, at least not yet), although I don't recall (and no longer
have the books available to check) if these are in the base
conformance level or optional.

But to my knowledge only CICS, and Tandem's roughly similar
but much less known PATHWAY, support(ed) adding new modules
transparently to a running program in the fashion of Java or
AIUI Erlang or explicit DLL/so's, much less direct source execution
like shells and awk/perl/etc.  (Admittedly CICS may be or have been
the environment for more COBOL code than any single alternative.)

Some OSes (also) support extralingual dynamic loading and/or calling,
which can apply to any supported language, at least any compiled
in the normal way, but perhaps somewhat more easily to COBOL
because it has just about the simplest possible calling convention.

--
- David.Thompson 1 now at worldnet.att.net

Re: Would an *AdaScript* language be a good / bad idea?

[Robert Dewar]

"David Thompson" <david.thompson1@worldnet.att.net> wrote in message 

> But to my knowledge only CICS, and Tandem's roughly similar
> but much less known PATHWAY, support(ed) adding new modules
> transparently to a running program in the fashion of Java or
> AIUI Erlang or explicit DLL/so's, much less direct source execution
> like shells and awk/perl/etc.  (Admittedly CICS may be or have been
> the environment for more COBOL code than any single alternative.)

Well who knows what "in the fashion of Java" might mean. But it has
been standard in COBOL programs for many years, including those 
running on IBM mainframes, to add new modules dynamically at runtime.
Typically you have a file that contains a list of valid transaction
names. Then if a transaction name is validated against this list,
you simply do the CALL to process it. The form of CALL is

  CALL xxx USING yyy

where xxx is a dataname (variable) containing the name of the procedure
to call, and yyy are the parameters. The module containing the code for
xxx is loaded dynamically and the call made.

Now to add a new module to a running program without stopping it, we

a) compile and link the code for the new transaction

b) install the load module in the appropriate place where it can be located

c) update the file with the list of valid transactions to enable access to
the new transaction.

This is standard COBOL stuff and must work on any ANSI standard conforming
COBOL compiler.

Now of course, though semantically, all binding to subroutines (called
confusingly programs in COBOL, the term run unit being used to describe
what others call a program), is dynamic at runtime, in practice most
calls look like:

  CALL "STANDARD-ROUTINE" USING ...

So that the name is known at compile time, and typical COBOL systems provide
for static linking in cases like this (though of course this is outside
the standard in any case).

Off topic for Ada, sure, but it is always interesting to be aware of what
capabilities other languages have. I was demonstrating Realia COBOL and
its visual debugger to Jean Ichbiah and showing him how the debugger handled
this kind of dynamic linkage, and he was quite surprised to find that COBOL
had that feature (as are many others in the programming language field,
who seem to share a lack of knowledge of COBOL in common :-)