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

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

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