HyperTalk is a discontinued high-level, procedural programming language created in 1987 by Dan Winkler and used in conjunction with Apple Computer's HyperCard hypermedia program by Bill Atkinson. Because the main target audience of HyperTalk was beginning programmers, HyperTalk programmers were usually called "authors" and the process of writing programs was known as "scripting". HyperTalk scripts resembled written English and used a logical structure similar to that of the Pascal programming language. HyperTalk supported the basic control structures of procedural languages: repeat for/while/until, if/then/else, as well as function and message "handler" calls (a function handler was a subroutine and a message handler a procedure). Data types usually did not need to be specified by the programmer; conversion happened transparently in the background between strings and numbers. There were no classes or data structures in the traditional sense; in their place were special string literals, or "lists" of "items" delimited by commas (in later versions the "itemDelimiter" property allowed choosing an arbitrary character). Code execution typically began as a response to an event such as a mouse click on a UI widget. In the late 1980s, Apple considered using HyperCard's HyperTalk scripting language as the standard language across the company and within its classic Mac OS operating system, as well as for interprocess communication between Apple and non-Apple products. The company did not oppose the development of imitations like SuperCard, but it created the HyperTalk Standards Committee to avoid incompatibility between language variants. The case-insensitive language was initially interpreted, but gained just-in-time compilation with HyperCard 2.0.
Description
Fundamental operations For most basic operations including mathematical computations, HyperTalk favored natural-language ordering of predicates over the ordering used in mathematical notation. For example, in HyperTalk's put assignment command, the variable was placed at the end of the statement:
whereas in the more traditional BASIC programming language (and most others), the same would be accomplished by writing:
The HyperTalk code has the side-effect of creating the variable theResult on the fly. Scripts could assign any type or value to a variable using the put command, making HyperTalk very weakly typed. Conversions between variable types were invisible and automatic: the string "3" could be multiplied by the number 5 to produce the number 15, or the number 5 concatenated onto the string "3" to produce the string "35". HyperTalk would not complain unless the types could not be automatically converted. The language's flow control and logic were generally similar to other common languages, using an if ... then ... else ... end if structure for conditionals and supporting loops based on a flexible repeat ... end repeat syntax. Comments were prefaced with two minus signs: -- this is a comment.
Objects, containers and scripts HyperCard's primary user interface concept was the card, a display system that emulated an index card. Cards were normally used to store information, similar to a record in a conventional flat-file database. The graphical layout of the card was created using the mouse by placing various elements on the card, such as text fields and buttons. A master layout "card" known as the background was shown behind the transparent areas of each card. Objects placed on the background, such as fields and buttons, would be shared as a common layout among several cards, but with card-specific content. The collection of cards, backgrounds and the associated data stored in them were stored in a single file known as the stack (of cards). Collectively, all of these data-containing objects are referred to as containers. HyperTalk functions, or scripts, were normally stored within the script property available in many of the stack's containers. Scripts could access the properties of a container, corresponding to instance variables, using the get and set instructions. The script property held plain text and had no special properties; scripts could be placed in, and run from, any text container, including string variables, or imported from other stacks using the start using command. A script could even be user-provided text typed into an on-screen text field. Arbitrary text could be executed using the do command, in a manner similar to Dynamic SQL.
Referring to containers A key concept in HyperTalk was the way it referred to containers through a navigational system based on the visual hierarchy of the stack. Every container in the stack was given a unique ID number when created and could also be given an optional name. Scripts could refer to objects by using either of these identifiers, along with an object type specified using the of operator. This operator used a natural language syntax making for easily readable, self-documenting code. For instance, a script stored in a button on a card might wish to take user-supplied text gathered using a text field and store the text in a variable called theValue:
Various contextual aspects of statements could be inferred by the interpreter. In the statement above, for example, because the script would be running in the context of a button on a specific card, the identifier card was understood to refer to the card the user was interacting with, even though the button itself would normally be on the background. In addition, "the value" (the text submitted by the user) was assumed to be the main property and to be the target of operations if not otherwise specified. Likewise, "card field" was assumed to be the target of the command, as opposed to the background field, so that information could also be omitted. Even container types had short forms that programmers could use to save typing. Thus the code above is equivalent to the shorter form:
Objects within a given context—the card or background, for instance—were also given a runtime number based on their z-order on the screen. To assist in using their position for navigation, HyperTalk also included a variety of ordinal and cardinal referencing systems to simplify the syntax further. Assuming the field "typehere" is the only field on the card, the code above could also be written:
… excerpt ends here. Continue reading the full article.
