Re: Ada.Command_Line and wildcards

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Markus E Leypold"
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in
> message news:8g649apcio.fsf@hod.lan.m-e-leypold.de...
> ...
>> I wouldn't want to use Ada as an interactive command language.
>
> Well, I would. Down with all non-Ada syntaxes!! ;-)

I admit I was rather interested in Tash also, for some time, but
actually more as a scripting tool.

>
> Seriously, we did in fact design an Ada command language for our debugger.
> It works quite well. (I think others have done similar things.) Of course,
> it's neither full Ada and it allows leaving out "noise" characters. And I
> believe we required one statement per line (that allows a lot more
> abbreviations). You can type:
>
>    Step_Line (Count => 20);
>
> or
>
>    sl 20
> (abbreviated command name; unneeded parens and semicolon omitted)
> Of course, if something is ambiguous, you have to use a longer form.

I think that might work with a debugger. For a shell I'd like to have
a "powerful" mechanism to combine / chain / compose operations and I
think that will become a nuisance with Ada syntax, especially when one
tries to build the shell expression incrementally.

> We originally did this because we wanted the macro language for the debugger
> to be as close to Ada as possible - that makes the macros readable and
> maintanable. Usually, you use shorter forms from the command line (typing
> too much is awful).

I think your design makes a lot of sense. But I'm certain you don't
require the user to declare all variables at the interactive prompt or
want them to open a new declare/begin block when introducing a new
variable. I often use

 > T="$( some_command ... )"

 > echo $T # convince myself that I have all data I want

 > for i in $T; do ... done  # do something

 > SUF=".txt"

 > for i in $T; do ... done  # do something else with $SUF


With strict Ada this style would becomes (IMHO) quickly tedious.

A certain amount of sloppiness in the interactive shell, that is my
point, of furthers usability.

A just "pascalish/adaish" syntax of course is not a problem and indeed
I'm preaching exactly that when I suggest to use a only slightly
modified OCaml toplevel as a shell: Strings are properly quotes, one
has functions and nesting parenthesis etc. It is well typed. And the
major feature in my eyes is would be type inference (as with the
"normal" shells one wouldn't have to provide type information). 

This is still mostly SF though.

Regards -- Markus