From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e219d94b946dfc26 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: Ada.Command_Line and wildcards References: <45dcaed8_6@news.bluewin.ch> <1172132169.423514.271890@s48g2000cws.googlegroups.com> <545bgvF1ttrphU1@mid.individual.net> <1495406.QZvfpqijrQ@linux1.krischik.com> <6dy7mn3hhu.fsf@hod.lan.m-e-leypold.de> <1172328891.5496.62.camel@localhost.localdomain> <1173096982.3712.37.camel@localhost> <8utzwzzv0v.fsf@hod.lan.m-e-leypold.de> <1173185771.11841.69.camel@localhost> <11wk29zr0.fsf@hod.lan.m-e-leypold.de> <1173305192.29628.82.camel@localhost> <1173447204.5618.131.camel@localhost.localdomain> <8g649apcio.fsf@hod.lan.m-e-leypold.de> From: Markus E Leypold Organization: N/A Date: Sat, 10 Mar 2007 11:52:06 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:JCqbGDwr58zEuj1zYjdJohRKyt8= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.194.126 X-Trace: news.arcor-ip.de 1173523549 88.72.194.126 (10 Mar 2007 11:45:49 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news1.google.com comp.lang.ada:14457 Date: 2007-03-10T11:52:06+01:00 List-Id: "Randy Brukardt" writes: > "Markus E Leypold" > 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