Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!van-bc!
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Dealing with multiple scripting languages
Message-ID: <724@lpami.wimsey.bc.ca>
Date: 28 Aug 89 14:10:41 GMT
Lines: 87
Return-Path: <lpami!lphillips>
To: van-bc!rnews

In <1989Aug29.031707.9022@agate.uucp>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:
>In article <721@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
><In <1989Aug27.034146.27086@agate.uucp>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:
><> It would also eliminate the ability to use ARexx
><>as macro langauge in a properly designed shell .... 
>< All that is neded to allow ARexx to run properly is to look
><for the first two non-whitespace characters in the file. If they are '/*', pass
><it to ARexx.
>
>Yes, but you can't just "hand it" to ARexx. ARexx gets passed a packet
>with the file name in it, and a port to send commands (those generated
>in the process of "macro expansion") to. There are problems with
>getting Execute to do this - like, where does it find the port to put
>into that packet?

Since ARexx will be the 'native' script interpreter in 1.4 (with Amigados
script capability retained, most likely), it would seem to me that this is not
a hurdle at all. I can see it would be if implemented before 1.4 arrives.

Perhaps we are talking about different things here. I am speaking in terms of
what could be implemented in a future (perhaps 1.4) release, with the hooks
built in to the system for allowing a variety of interpreted languages to
coexist peacefully.

>< We just have to reserve '/*' as the magic cookie for ARexx.  No big deal.
>
>Yes, it's a big deal. It defeats the point of the system. If you have
>to reserve a different magic number for each interpreted langauge,
>then the user can't get a new interpreter and have it's source files
>work as executables - not unless things have been arranged so the user
>can change the list of magic cookies.

Isn't that what the 'generic, named interpreter' is for? ie. the magic number
specifies that the rest of the line names the interpreter. Perhaps the answer
is to remove the magic number to somewhere else, like the file header, so that
the interpreter doesn't actually get it as part of the file.

><#    is the '# any uglier than
><//   any other comment
><REM  delimiter?
>
>No - but having to add it to both languages regardless of what it's
>otherwise used for is ugly.

I'll agree wholeheartedly with that.

>Fixing the recognition problem isn't hard - you just have to find a
>method that doesn't break Rexx (Rexx exists elsewhere - CLI scripts
>are pretty much Amiga specific, so breaking those is somewhat
>acceptable), which means working with multiple different comment
>methods, doesn't die if you feed it an arbitrary binary (for instance,
>by looking for some character that may never occur), and can't
>possibly collide with any existing thing Execute recognizes.

I don't mind if Amigados scripts get broken, as long as there is a way to tell
when they are broken because of the changes. That would entail an error message
to the effect: 'No magic number'. It would be a small price to pay for the
transition, and would be relatively easy to fix. We might even end up with
someone writing a utility to make Amigados scripts into ARex scripts. (Hmm...
that would be a good utility now, even)

I don't see arbitrary binaries as a problem. The rule would be to look at the
first non-whitespace character(s). If they happen to be something used by an
interpreter, what are the chances that the rest of the passed file will be a
legal interpreter program?

> However, that ignores the more important problem - that ARexx expects a wider
>communications path to the invoking program than Execute provides.

Yes, and that's now, as things stand under the current rev of the OS. I think
you'll find that there are sufficient hooks coming to fill the requirements of
ARexx, and that many of the problems will disappar entirely. My main concern is
that we have a method to allow virtually unlimited capability to add
interpreted languages transparently, and in a manner consistent with each
language's implementation.

Thanks for pointing out the pitfalls.

-larry

--
The Mac? Oh, that's just like a computer, only slower.
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+