Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Pascal Martin <pascal.martin@iname.com.nospam>]

In article <wccwvoe3tzw.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote:
>> As Robert A Duff said :
>> "Scripting languages should encourage programs that are easy to
>> write, easy to understand, and easy to change."
> 
> I don't think *I* said that.  In fact, my opinion is that "easy to
> write" not important; the other two goals I agree with.


It seems to me that everytime I chose to use a scripting rather than
a compiled language, it was for a subset of the following reasons:

1- Execution speed is less important than development comfort.
2- Very flexible string manipulation is highly important, which means
     support for transparent string resizing, concatenation and data-
     driven split (for example, split a string into a list of words).
3- Easy to use regular expression engine. The drawback is that it
     seems there is no such engine that is also easy to debug with,
     including expect.
4- System operations must be easy: execute a program, retrieve its
     output, control its input.
5- Symbolic indexing (aka strings indexes, or hash tables).
6- Dynamic table resizing.
7- Very portable. Which means that the components of the environment
     must be available on all platforms. Not so easy when considering
     item 4, or when using commercial packages.
8- Include a GUI toolkit. We are in 2000: echo "Please enter..."/read
     don't cut it anymore. But the GUI must be optional.

All these features must be 100% interoperable, of course. Which
mandates using the same basic dynamic string package all over.

Garbage collection is basically mandatory. I am sure there are ways to 
implement a dynamic string package in Ada, it just appears that putting 
togethers many packages from separate sources is always complicated, 
because it is frequent that these packages do not define compatible types.
Using generic packages is somewhat incompatible with development comfort,
because you have to do the package integration work all by yourself. 
So, all the environment support should come as one single set.

Among the scripting languages/interpreters I have used:

the ugliest: command.com
the slowest: sh
the most confusing: perl
the most difficult to debug: Tcl (still using it, through, because of Tk :-)
the most obscure: VAX/VMS DCL (all these optional parameters.. )
the worst limitations: Microsoft Basic on TRS80 (I liked it at the time)

------------------------------------------------------------------
Pascal F. Martin.