Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uwm.edu!bionet!apple!bc
From: bc@Apple.COM (bill coderre)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Compatibility of stacks and Hypercard 2.0
Message-ID: <43578@apple.Apple.COM>
Date: 3 Aug 90 01:08:00 GMT
References: <1990Jul26.192703.894@midway.uchicago.edu> <45998@brunix.UUCP> <90213.091703SAS102@psuvm.psu.edu> <46359@brunix.UUCP> <90213.175513APPLEREP@MTUS5.BITNET>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 54

In article <90213.175513APPLEREP@MTUS5.BITNET> APPLEREP@MTUS5.BITNET writes:
|Don't forget, also, that the ability to customize an existing stack is one
|of Hypercard's greatest strenghts.  

Ahh, but commercial stack developers aren't real keen on this, because
it also allows competitors to see how their code works. Thus,
incredibly involved pipeworks of protection code.

But this is neither dross nor scoria.

The problem with compiling HC is that it is, at heart, a "late
binding" language. Consider this example:

on mouseup
  get cd fld "code"
  do it
end mouseup

Since HC has no idea what is in the field until the moment the mouse
goes up, it would have to carry around -- at the very least -- an
interpreter or compiler in EVERY compiled stack, to execute the "do."
And if HC was "nice," it would carry around all of itself in any
compiled stack, just to make sure that any valid hypertalk the user
entered could be executed. Thus compiled stacks wouldn't be able to
shrink.

Note that there are several ways around this. Many popular late
binding languages, such as Common Lisp, allow both.

1) Allow the user to specify various lumps of code that can be left
out. If HC can't "do" because of missing code, the application vomits.

2) Enforce that any compiled stack cannot contain any "do" that has a
non-constant as an argument. This allows lots of code removal, but
hinders many other HC features, such as the Message Box, and XCMDs,
which often ask HC to evaluate a line of hypertalk.

These aren't such big problems to many developers, and indeed a
campiled stack would be a wonderful thing: smaller, faster, more
secure, and easier to ship (no need to demand a certain HC version on
disk).

The only problem is simply that it is a gigantic leap in complexity,
even assuming that stack scripts are partially compiled now. Many
Lisps don't allow "application building" even though they compile all
their code. Application building is simply a huganic problem to do
"right."

This is not to say that Hypercard or Supercard shouldn't do it. It's
just to say why it isn't easy, and therefore why it tends not to be
done.

bc
consultant, not mouthpiece