HyperTalk scripts resembled written English and used a logical structure similar to that of the Pascal programming language.
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.
The company did not oppose the development of imitations like SuperCard, but it created the HyperTalk Standards Committee to avoid incompatibility between language variants.
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.
[3] A key concept in HyperTalk was the way it referred to containers through a navigational system based on the visual hierarchy of the stack.
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.
Many examples of this sort of syntactic sugar were found in HyperTalk, in order to simplify the syntax and improve readability of common code.
For instance, while parsing a space-delimited data file, one might want to extract the third column, like this: This syntax allowed the script to "walk" down the text to find particular data, as in this example: This process of treating text as a container was known as "chunking", and the functions as "chunk expressions".
For instance, the position of objects on the screen was defined by a pair of numbers representing the X and Y coordinates relative to the upper left corner.
The following code creates a variable called pos that holds a coordinate pair, and then manipulates this to re-position all of the buttons on a card in a diagonal from top-left to bottom-right: The item chunking expression was originally based on a comma delimiter, but later versions of HyperCard changed this to the value of itemDelimiter, offering the ability to parse arbitrary lists and structures.
Unlike general rapid application development platforms, HyperCard stacks always looked like stacks - the menu bar was HyperCard's and not the programmer's (by default—scripting could add, delete and modify menus), the single window was a fixed size (in early versions), and in certain cases, commands that were central to the operation were part of the application itself, and not directly available in HyperTalk itself.
A good example of this was the creation of new cards, which was part of the application, not directly accessible from the HyperTalk language itself.
For example: or While the end result felt similar to scripters as a Bash script's expansion of variables before parsing, this was special-case syntax and did not have the pitfalls where data would be evaluated as code.
So for example, all of the following are syntax errors in the melody, not function calls: Although the HyperTalk language languished just like HyperCard itself, it interest was revived through its plugin protocol, so-called External Commands (XCMDs) and External Functions (XFCNs), which were native code containers attached to stacks (as Macintosh-specific resources) with a single entry point and return value.
Some XCMD authors added advanced features like full color support (ColorizeHC, HyperTint, AddColor), multiple special-purpose windows (Prompt, Tabloid, Textoid, Listoid, ShowDialog, MegaWindows), drag and drop support and various hardware interfaces to the language.
[6] Although Asymetrix ToolBook is often also considered a HyperCard clone, its scripting language apparently bears little resemblance to HyperTalk.