Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!stanford.edu!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga.programmer Subject: Re: Hyper Functionality Message-ID: <1991Apr26.073906.10785@agate.berkeley.edu> Date: 26 Apr 91 07:39:06 GMT References: <1991Apr22.071413.22219@agate.berkeley.edu> <803@tnc.UUCP> Sender: root@agate.berkeley.edu (Charlie Root) Organization: University of California, Berkeley Lines: 30 In <803@tnc.UUCP> (25 Apr), GUY GARNETT (Wildstar) (m0154@tnc.UUCP) writes: > > It seems to me that a ARexx => ppIPC program (or even function > library) could be written fairly easily. > [.....] > The reverse should also be possible: a ppIPC => Arexx program. > > With these two modules, anything that understands Arexx could be > interfaced (with the appropriate Arexx script) to ppIPC. > I think so too. I've often toyed with the idea of doing some such, but have had too many other things to think about to actually DO anything. It would be cumbersome to have it manage ALL the options that ppIPC has, but it should suffice for most needs. Especially as I see ARexx's role as providing Command and Control functions rather than much data passing. Unlike Mike Meyer, I get a severe attack of the squirms when I think of using ARexx for data (structures) other than text strings. It's rather like returning to the bad old days of BASIC peeks and pokes: leaving manipulations with things like hex adddresses at the user-editable script level is NOT something I favour. However, it CAN be done if one is willing to accept the risk. (And it WOULD provide a convenient way of prototyping ppIPC stuff!) My goal with ppIPC, though, is to provide bulletproof applications for the (average) User. But please, I would love to see such an interface implemented. I suspect it will NEVER reach the top of my project stack (which monotonically increases) so go for it, somebody! -- Pete --