Path: utzoo!mnetor!uunet!oddjob!ncar!ames!oliveb!sun!hanami!landman
From: landman%hanami@Sun.COM (Howard A. Landman)
Newsgroups: comp.sys.mac.hypercard
Subject: Something HyperCard *OUGHT* to do
Message-ID: <50949@sun.uucp>
Date: 26 Apr 88 21:02:36 GMT
Sender: news@sun.uucp
Reply-To: landman@sun.UUCP (Howard A. Landman)
Distribution: comp
Organization: Sun Microsystems, Mountain View
Lines: 73

One of the most severe problems with the Mac is that every program
assumes it is interacting with a human being.  It is virtually
impossible to get two programs to communicate or cooperate in a
significant way, an ability that every UNIX-hacker takes for granted.
There is no facility in Mac-land that has anything like the power and
notational convenience of a pipe, or the flexibility of shell
programming.

A concrete example: I play the game of Go.  I have several Mac programs
which play Go.  I have a database of game records in ASCII format.  Both
of the following are desirable, and neither is possible without extremely
convoluted (probably assembly language) hacking:

1. Have two programs play each other.
2. Have a program take a list of files of incomplete games, one at a time,
   read a file in, play both sides to completion, save the result in another
   file, and then process the next incomplete game, until all games are done.

The basic problem is the use of the mouse as the primary input device,
as opposed to a keyboard.  This makes "shell scripts" unnatural.
I can do the above things AS LONG AS I AM SITTING THERE DOING THE
CLICKING, but there is no way to have them happen automatically.

HOWEVER, I think there is a way out of this problem, one which would
add immense power and flexibility to the Mac, and could be neatly
grafted onto HyperCard.  It is simply this: under MultiFinder (or
perhaps AUX, have a way for HyperCard to launch one or more applications
and KEEP RUNNING, CONTROLLING THE MOUSE AND OTHER INPUT DEVICES VIA
HYPERTALK.  Thus it would be easy to write a script that launched Dragon 2.10
(a Go program), told it to play Black, launched the Infinity Go program,
told it to play White, and then looped communicating moves from one
program to the other.

HyperCard could then become to the Mac what shells are to UNIX: a
convenient (if slightly slow) way to build useful functions from
programs that already exist, and to mimic the effects of human input.
(The UNIX "yes" program gives strong evidence that this is worthwhile.)

CAVEAT: I don't have MultiFinder.  For all I know, HyperCard might
already work this way under it.  But somehow I doubt it.

If you think about this for 30 seconds or so, I think you'll begin to
get as excited about it as I did when it first came to me.  ANY MASTER
PROGRAM WHICH INTENDS TO CONTROL MAC APPLICATIONS MUST BE ABLE TO MIMIC
ALL FORMS OF INPUT.  HyperCard already does this - the commands just
need to be made to work on sublaunched programs.  In other words, the
syntax and semantics of HyperTalk need change only slightly, and in a
logical way.

It would probably be best to maintain the present behavior for existing
scripts.  I propose the new keyword "slave" be used to distinguish the
new kind of open, as in:

	open slave "MacWrite"

In the absence of MultiFinder and AUX, this command fails.  If either
is running, then MacWrite is opened and HyperCard continues to run,
but BEHIND MacWrite, so that HyperTalk Commands are executed only when
MacWrite is idle (otherwise the script might outrun the program).
If the script says "click at theLoc", then MacWrite, not HyperCard,
receives and interprets the simulated mouse click.

Handling of tools (say, in MacPaint) could probably not be made as
transparent and convenient as it is in HyperCard, because HyperCard
would have to understand all the applications's tools.  In other words,
the "choose" command becomes useless in this context.  But tools could
be selected with "click" or "drag", if you knew where they were.

Any comments (besides "Why didn't *I* think of that?")?

	Howard A. Landman
	landman@hanami.sun.com
	UUCP: sun!hanami!landman