Re: scripting/extension language for Ada (we have an opportunity here)

["Samuel T. Harris" <samuel_t_harris@Raytheon.com>]

"Robert I. Eachus" wrote:
> 
> "Tarjei T. Jensen" wrote:
> 
> > If the Ada community can create a command interpreter which can be extended at
> > the user level without having to re-link or recompile then we have a winner.
> > Especially if it can be used embedded into applications. It will simply be too
> > conventient and powerful to ignore.
> 
>      This sounds like a not too difficult project, in fact the most
> difficult part will probably be reaching a consensus on the
> requirements.  Since I am a most intrepid sort of person, here is a
> first cut:
> 
>    Concept:  Build a special version of gnat for scripting purposes.
> The syntax will be pure Ada, while there will be some modifications to
> the semantics to account for the special purpose.  In particular, more
> implicit conversions will be allowed, and dynamic bindings to
> environment variables and executable programs.
> 
>    Requirements:
> 
>       1) The tool shall target both Unix and Windows (95,98,2000,NT
> 4.0).
> 
>       2) Procedure, function, (and entry?) calls which do not match a
> subprogram or entry declared in the script will be searched for using a
> search path.
> 
>       (Questions:  Use the externally defined path, or a local path then
> the external path?  Is there a way to call insure that a call is
> external?)

The shell engine can process the path and produce a PATH package
containing subprogram specs for everything visible. A special
classification for the required pragma interface can be used.
The engine can be configured to "know" the argument profile
of certain commands. Others can take a single string argument.

> 
>       3) Conversions between Strings, Bounded_Strings, and
> Unbounded_Strings shall be implicit.
>       (Should there be a "standard" instantiation of Bounded_Strings, or
> should it be possible to declare a variable as: Foo:
> Bounded_String(1024); or something similar?)

I'd rather see a package with a rich set of predefined "+"
operations for all th necessary conversions.

> 
>       4) Environment variables shall be treated as String
> (Unbounded_String?) variables in an outer scope, and shall be hidden by
> identically named variables in inner scopes.  (In other words, it must
> be possible to pass a modified set of environment variables to nested
> calls.)

Again, the shell engine can produce a package ENV containing
access to string variables representing the environment.
Access to the environment must also be supported by subprograms
because the environment is a dynamic association of ordered
pairs of strings and cannot be entirely captures as a list
of string variables.

> 
>       5) It shall be possible to explicitly designate executable
> programs or scripts in the environment.  (In other words it must be
> possible to bypass the search path to get to, say, /bin/sh,  pragma
> External_Name is probably the best way to do this.)

Exactly. This fits with the predefined package PATH. A pragma interface
classification will also be needed to specify the subprogram is
an external executable. I'm not sure EXTERNAL really conveys the
meaning here so other suggestions are solicited.

> 
>       6) Arguments passed to the script/program on the command line
> shall be accessable.  (Special version of Ada.Command_Line if
> necessary.)

Why should the script program be a parameterless procedure.
It can have parameters. Boolean parameters can be assumed to
be switches. Other parameters can be command-line arguments.
Named Ada notation fits nicely with UNIX switches which
require arguments. The shell engine can parse the switches
and arguments on the UNIX command line and fit them into
the script programs parameter list.

> 
>       Anything else?

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"