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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fa2cc518ef3b992c X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: scripting/extension ... [off topic] Date: 2000/02/16 Message-ID: <38a9fdb8@eeyore.callnetuk.com> X-Deja-AN: 586342144 References: <389207CC.C16D80E8@averstar.com> <38971028.BB16D8A2@earthlink.net> <3899F757.FAE131B3@free.fr> <389D43A6.786C7B79@free.fr> <880gpk$fv04@ftp.kvaerner.com> <38A47E5A.42406034@earthlink.net> <38A6F3D6.2D9C7296@earthlink.net> X-Original-NNTP-Posting-Host: da130d53.dialup.callnetuk.com X-Trace: 16 Feb 2000 01:30:32 GMT, da130d53.dialup.callnetuk.com X-MSMail-Priority: Normal X-Priority: 3 Newsgroups: comp.lang.ada X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Date: 2000-02-16T00:00:00+00:00 List-Id: I sent this (warning: highly discursive) post to Pascal as an e-mail by accident (instead of to the group), which very likely bewildered him entirely. I've got no reply from him, anyway! The kind of 'Ada interpreter' suggested has existed for a long time, albeit in a form that (to my knowledge) was never really finished off. It was called 'ACE' (the Ada Command Executive), and was was one of the (numerous) developments under the STARS programme. I have a copy of the source code and docs (somewhere on my hard disk, I think!), if anyone's interested. I think it was a nice idea, but surely the amount of typing you have to do to do something 'simple' would come a screaming culture shock to anyone used to the 'sh' family. I have invented, pretty well in my head, an Application eXtension System: AXS (pron. 'axis'). It's not a language. The idea is that every element that would make up a traditional script program (large or small) is replaced, in essence, by a dialog box, that garners the necessary information for the element, and which simply invokes further dialogs for component elements. For example, a sequence of actions would be entered in a dialog box that displayed the actions in a 'list box'; there would be a button to add a new action, one to insert an action, one to delete an action, and one to edit an action. Actions could be rearranged by drag-and-drop (or by two arrow buttons). Editing an action would pop up a dialog for that purpose; of course, one of the options would be another (nested) sequence. I shan't get deeply into the details, but I think I've dealt with the various problems associated with doing this sort of thing. AXS seems to be a great way of programming GUIs a la RAD. The main advantages of AXS could be set out as below. 1. No language has to remembered by the 'programmer'. Syntax errors are not generally possible. Selecting actions is generally a matter of 'point and click'. 2. Each dialog box ensures that all the necessary parameters are filled in, and can be validated (to some extent) at entry time. Entry of values can generally be made very easy (e.g. a calendar for dates). Variables can be selected by 'point and click'. 3. No distinction is made between actions and data values. This has the double advantage of making activity easily data-directed, and of making it particularly easy to program the automated manipulation (and construction) of procedures. 4. Certain data that would be difficult or impossible to encode in textual script language can be straightforwardly dealt with by AXS (until it comes to manifesting it in XML, of course). For example, in AXS, an icon could be entered by simply popping up an 'icon editor' dialog box, without the programmer having to deal with files or filenames in any way. The downside (there always is one :-) is that programming the sub-AXS modules is relatively elaborate. I don't think this is too much of a problem, so long as most modules have a reasonable expectation of a high level of re-use. Undoubtedly there will be some constructs that will actually be more easily entered and edited as text than by dialogs, e.g. complicated mathematical expressions. However, a textual alternative could always be offered by a dialog (further complicating the implementation, of course). An AXS procedure could be manifested in XML, if necessary. E.g. (I've used square instead of angle brackets here, so as not to confuse certain viewing software): [procedure] [identifier]activate_ppp[/identifier] [name]Activate a PPP session on a modem[/name] [desc]This procedure causes a modem to dial up an external ...[/desc] [help]/usr/axs/doc/ppp/activate_ppp.html[/help] [option] [identifier]debug[/identifier] [actuals][input][identifier]level[/identifier][value]3[/value][/input][/actu als] [/option] [parameters] [input] [type]string[/type] [identifier]phone_number[/identifier] [name]Telephone number to dial[/name] [desc]This is the telephone number the modem is to dial to get ...[/desc] [/input] ... [/parameters] [action] [sequence] [call] [identifier]reset_modem[/identifier] [name]Reset a modem to a known state[/name] [actuals] Okay, I've stopped there, but you get the flavour. I think I'm touching on something that Dr Robert Leif has being saying recently (about XML having great importance for the future of programming languages). There are some well-argued advantages to using XML for this sort of purpose (one of the most obvious being the flexibility in formatting and presenting printouts, but it goes much deeper than that). However, touching on the mention of Scheme in this thread (am I imagining that?), it seems to me that languages such as LISP and Prolog could be very readily used in place of 'traditional' script languages. Prolog could offer particularly powerful facilities when it comes to pattern-matching. If external procedures were to be provided such as env:obj(Obj) to instantiate with every object in the 'current object' (i.e. every file in the current directory), env:attr(Name,Attr) to instantiate with object attributes (e.g. "name", "mime-type", "mdate", etc.), and env:value(Obj,Attr,Val) to instantiate with the value of an attribute for an object, some pretty sophisticated searches could be programmed very concisely: mail_me_my_files(CO) :- my_email(Me), my_initials(Init), Search = "Author: "//Init, env:within(CO, ( env:attr("name",NameAttr), env:obj(Obj), env:value(Obj,NameAttr,Name), env:run("search",[Search,Name],0), Subj = "Found my file: "//Name, env:run("sendmail",["-s",Subj,Me,Name],0) ) ). A really good debugging environment would be important. Fifth generation languages like these could very aptly be used for implementing AXS. The potential exists for some rather 'intelligent' things to be done with software that isn't frozen in brick. It's strange, but I'm beginning to get a more concrete sensation that the days of 'programming', as such, are not so far from being over as many of us would prefer to think. It's an old idea (dating back to the sixties); computers are nearly getting to the point where they are actually powerful enough (while remaining affordable) to realise the dream. Maybe the little chip in The Terminator's* head isn't all that far away after all :-o -- Nick Roberts http://www.adapower.com/lab/adaos *TM Carolco, 1984+