Re: scripting/extension ... [off topic]

["Nick Roberts" <nickroberts@callnetuk.com>]

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+