robison@m.cs.uiuc.edu (01/31/89)
A theme of the past decade in language design has been simplicity.
Instead of adding features to a language, what restrictions can
we remove to make it more powerful, or what feature can we
add that subsumes other features? Are there features that
combine two useful features, and can we gain power by separating
these features? I believe HyperTalk is already overly complex.
Less restrictions and not more features would make HyperTalk more
powerful. Furthermore, the programmer would have less to learn and
remember.
For an example in another language, the Scheme language allows procedures
to be values. This removal of a restriction allows record structures,
user-defined control structures, and message-passing style programming
without having to add any new features to the language. For another example,
control structures and boolean operations in Smalltalk are not primitives,
but defined via inheritance.
I've listed seven suggestions for HyperTalk simplifications below.
Most of these simplifications are not backwards compatible; I consider
them suggestions for future hypertext systems. All of them involve
removing a feature, or removing a restriction. My apology if some of
these already exist and I just overlooked them. I invite criticisms or
additions to the list.
1. The syntactic and semantic distinctions between functions and
messages should be removed. Messages should just be functions
that return a constant. I've already run into a problem with the
message/function dichotomy. I wanted to send a function 'f'
to another card (and its inheritance hierarchy), but the "send"
command works only for messages, not functions. Infinite tail-recursion
should be allowed.
2. Button and field numbers should be abolished. They are like
to absolute memory addresses in assembly code --- cryptic
and unnecessary for the programmer to know about since buttons and
fields already have symbolic names.
3. Cards, buttons, and fields should be first-class objects.
I should be able to store them in variables, and pass them
as parameters. This is different from passing references,
i.e. ids, which is the current way of doing things.
Using push/pop to save/restore cards instead of variables
is reminiscent of machine language.
4. Visual effects should be first class.
5. The limitation of background/foreground to just two layers should
be removed. The limitation violates the `zero-one-infinity principle'
which states that the user should never have to remember special
numbers for features. A feature should be disallowed, allowed once,
or allowed in unlimited quantity. I would have a 'card' just be
a collection of 'transparencies'. The inheritance structure should
be extended to handle these multiple layers. Buttons and fields
should just be special cases of these layers. The issue of 'instance
of something' versus 'reference to something' needs to be clarified.
6. The 'find' command contains two features which should be separated.
The two features are displaying a card, and searching for a card.
The 'display' feature is redundant, the language already has 'go'
to do that. The 'search' feature should be generalized to
a function 'search <predicate>', and return the collection of cards
for which the predicate is true. If efficiency is a real concern,
perhaps a 'search first <predicate>' could be added. The current
hack of pushing the current card, finding, and then checking the result
variable is just that, a hack. It is easier for the user to combine
than pick apart two features.
7. Remove most side-effects. This last suggestion is most definitely not
backwards compatible. HyperTalk is a very side-effect driven language.
E.g. the ubiquitous 'it' and 'result' variables. I think a declarative
language, or at least a language with a useful declarative subset might
be more suitable. While declarative languages might be slower for
professional programmers, I'll bet they are frequently faster for
amateur programmers when implemented cleverly (e.g. applicative caches).
Professional programmers seem to end up using XCMDs outside HyperTalk
anyway.
In summary, I believe that HyperTalk is the PL/I of Hypertext.
(Its imitators will no doubt be the Ada's of Hypertext.)
We should be looking for smaller and more elegant languages
in which to write hypertext.
Arch D. Robison
University of Illinois at Urbana-Champaign
CSNET: robison@UIUC.CSNET
UUCP: {pur-ee,convex}!uiucdcs!robison
ARPA: robison@CS.UIUC.EDU (robison@UIUC.ARPA)dan@Apple.COM (Dan Allen) (02/04/89)
Interesting comments about keeping the language simple. As you pointed out, such language innovations are not backwards compatible, so for this incarnation of HyperCard, I doubt you will see your suggestions implemented. HyperTalk was meant to be somewhat like English. There is a lot of redundancy built into English as well as HyperTalk. The goal of HyperTalk was to make programming accessible to people that have not programmed before. I believe it has met its goal very well. For serious programming perhaps there should be a way of downshifting into HyperC or somesuch language that is a more formal language. I think such a language would be neat myself, but it would scare off the average never-having-programmed type of people. Keep up the good comments and ideas! Dan Allen ** dan@apple.COM (Unix mail) Software Explorer ** ALLEN.DAN (AppleLink) HyperCard Team ** 20525 Mariani Ave. MS 22AE Apple Computer ** Cupertino, CA 95014 *********************************************************** ** Sam: "You know what they say, 'You can catch more ** ** flys with honey than with vinegar.'" ** ** Woody: "I don't mean to butt in, but you can catch ** ** the most with dead squirrels." ** ***********************************************************