🚀 go-pugleaf

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 .... 
<
<It would? I think it rather depends on what you call 'properly designed'. To
<me, that means that it can handle everything that is currently available, with
<provision for allowing it to handle whatever comes along next, and do it in a
<consistent manner. 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?

<It works that way now.  If it happens to be a C source code file,
<ARexx will figure it out pretty quick, just as it does now.  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.

<#    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.

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.  However,
that ignores the more important problem - that ARexx expects a wider
communications path to the invoking program than Execute provides. I
don't see an easy solution to that, other than leaving the ARexx
method as an alternative. In which case, making the ARexx method
subsume the BSD method should be given a serious look. And you
probably want to do that to begin with, as the results might be better
than going the other way.

	<mike
--
Tried to amend my carnivorous habits			Mike Meyer
Made it nearly seventy days				mwm@berkeley.edu
Loosing weight without speed				ucbvax!mwm
Eatin' sunflower seeds					mwm@ucbjade.BITNET