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

["Tarjei Tj�stheim Jensen" <tarjei@online.no>]

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.
>

You have started in the wrong direction. Such an interpreter should have an Ada-ish
look and feel, but it should not be Ada. E.g. I strongly believe that it should use
"[" and "]" for arrays. There should be reasonable defaults.

The attribute system as found in ada should be simplified. It should be possible to
write a := a'succ; or something similar and short.

s1 : string; -- unbounded string
s2 : string[5]; -- string of maximum length 5, but dynamically sizeable

I think one should aim for to make it an integration tool. In windows it should use
dcom, in Unix something else (or create something). If we get a way of letting
scripts have dde/dcom/ole functionality I don't think we could be stopped in a Unix
environment. Especially if it was inherently multithreaded. If it can be used to
extend the desktop we have it made.

The theory is that in such an environment people would want to use ada for the
following reasons
  1 in order to create extension modules
  2 understand what it does
  3 use its complementary library to get access to its services.

It would be nice if it were possible to compile a script into Ada.

>    Requirements:
>
>       1) The tool shall target both Unix and Windows (95,98,2000,NT
> 4.0).

I think the primary target should be Unix with a bias towards making it windows
compatible.

>       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?)

It should be possible to specify how to treat certain names and how to search. E.g.
it should be possible to specify that if a command has a given name, then a given
command should be executed as in alias in a bash/korn shell. It should be possible
to specify that if a program cannot be found in a search path, then one should
search for e.g. program.ksh, program.sh, program.pl, program.py, etc. in the path.


>       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?)

See above.

>       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.)

It would be nice to be able to have drives like we have in VMS. E.g. define
ada_config as /etc/ada and refer to files there with ada_config:global_setup.conf. I
think it is better than ${ada_config}/global_setup.conf.

These drives should be available as global environment variables.  It would be very
nice if these variables were available through a different mechanism than
environment variables, so that changes affect all instantly. In VMS these variables
are on several levels. They form a hierachy. Which level is the inquiry about a
variable can be specified.

One would have to decide whether these should be persistent or whether they should
die when the system go down. If they are persistent, then we have a registry.
Perhaps such a thing should be in a database to get access control and sql.

>       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.)
>
>       6) Arguments passed to the script/program on the command line
> shall be accessable.  (Special version of Ada.Command_Line if
> necessary.)

It should be possible to script enable programs. It should not be neccessary to link
in the interpreter. Script enabled programs should not need to have file names
expanded on the command line. They should be able to obtain these as needed by
feeding the file specification to a file name generator service.

The interpreter should be internationalized from the beginning.


BTW Anybody contemplating on writing an command interpreter should

1. get a few books on script programs and make a list of the best features. E.g.
books on the Korn shell or Bash, awk, rexx, perl, tcl and python (zope).

2. Decide on syntax.

3. Write scripts and see whether it works and looks right

4. repeat 1 .. 3 as neccessary

Then you can design and code the interpreter.

Greetings,