Misplaced Pages

#690309

48-434: 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

96-413: A mouseUp message when it was released while still on top of that container, and a script could capture these events like this: Messages for events were first sent to the script in the object that created the event, for instance, if the user clicked on a button the mouseUp message was first sent to that button. If the button's script object did not have a mouseUp handler (or no script at all), it

144-587: 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

192-433: A HyperCard stack, as well as user input ( keyDown , functionKey , ...), and system events. As far as the scripters were concerned, there were no main event loops like in other procedural programming languages. 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),

240-449: A combination of both styles. It is common for input/output code in functional languages to be written in a procedural style. There do exist a few esoteric functional languages (like Unlambda ) that eschew structured programming precepts for the sake of being difficult to program in (and therefore challenging). These languages are the exception to the common ground between procedural and functional languages. In logic programming ,

288-427: A flexible repeat ... end repeat syntax. Comments were prefaced with two minus signs: -- this is a comment . 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

336-498: A phrase in a human language which reflects the symbol's meaning, such as article.numberOfWords or TryOpen . The code must also have a clear and clean structure so that a human reader can easily understand the algorithm used. There are certain practical considerations that influence whether and how well the objectives for a self-documenting system can be realized. Below is a very simple example of self-documenting C code, using naming conventions in place of explicit comments to make

384-419: A program implementation into objects that expose behavior (methods) and data (members) via a well-defined interface. In contrast, procedural programming is about dividing the program implementation into variables , data structures , and subroutines . An important distinction is that while procedural involves procedures to operate on data structures, OOP bundles the two together. An object is a data structure and

432-442: A program is a set of premises, and computation is performed by attempting to prove candidate theorems. From this point of view, logic programs are declarative , focusing on what the problem is, rather than on how to solve it. However, the backward reasoning technique, implemented by SLD resolution , used to solve problems in logic programming languages such as Prolog , treats programs as goal-reduction procedures. Thus clauses of

480-412: A set of file management functions. The following code opens a known file, reads from it, extracts data, and then closes the file: HyperTalk also included functions for chunking strings using a substring-find operation using the in operator. The following code finds all examples of a given pattern using the in as part of the repeat loop, while offset finds the location of that pattern within

528-523: A single entry point and return value. XCMDs and XFCNs could be called just like regular message and function handlers from HyperTalk scripts, and were also able to send messages back to the HyperCard application. 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

SECTION 10

#1732776583691

576-578: 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

624-421: 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: or: The choice of addressing style was left to the programmer; often different styles were used in different statements depending on the style of the surrounding code in order to make the code more readable. HyperTalk included

672-505: Is a series of steps that forms a hierarchy of calls to its constituent procedures. The first major procedural programming languages appeared c.  1957 –1964, including Fortran , ALGOL , COBOL , PL/I and BASIC . Pascal and C were published c.  1970 –1972. Computer processors provide hardware support for procedural programming through a stack register and instructions for calling procedures and returning from them. Hardware support for other types of programming

720-476: Is exactly equivalent to set the visible of field i to false . A similar example was the lock screen command that stopped visual updating, which was a short form for set the lockscreen to true , where lockscreen is a property of HyperCard itself—also a container. Many examples of this sort of syntactic sugar were found in HyperTalk, in order to simplify the syntax and improve readability of common code. In HyperCard 2.2 and later,

768-418: Is possible, like Lisp machines or Java processors , but no attempt was commercially successful. Certain software development practices are often employed with procedural programming in order to enhance quality and lower development and maintenance costs. Modularity is about organizing the procedures of a program into separate modules—each of which has a specific and understandable purpose. Minimizing

816-433: The me container which acted in the same fashion as the self qualifier found in most object-oriented languages , allowing simple access to the current container object. Less common was the it variable, which held the value of the last operation for certain built-in operators. For example: This example uses the ask command to display a dialog box and capture the text typed into an accompanying text field; when

864-414: 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

912-547: The onmouseup event handler in JavaScript. Although Asymetrix ToolBook is often also considered a HyperCard clone, its scripting language apparently bears little resemblance to HyperTalk. Procedural programming language Procedural programming is a programming paradigm , classified as imperative programming , that involves implementing the behavior of a computer program as procedures (a.k.a. functions, subroutines) that call each other. The resulting program

960-568: 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. 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

1008-457: The scope of variables and procedures can enhance software quality by reducing the cognitive load of procedures and modules. A program lacking modularity or wide scoping tends to have procedures that consume many variables that other procedures also consume. The resulting code is relatively hard to understand and to maintain. Since a procedure can specify a well-defined interface and be self-contained it supports code reuse —in particular via

SECTION 20

#1732776583691

1056-678: The software library . Procedural programming is classified as an imperative programming , because it involves direct command of execution. Procedural is a sub-class of imperative since procedural includes block and scope concepts, whereas imperative describes a more general concept that does not require such features. Procedural languages generally use reserved words that define blocks, such as if , while , and for , to implement control flow , whereas non-structured imperative languages (i.e. assembly language ) use goto and branch tables for this purpose. Also classified as imperative, object-oriented programming (OOP) involves dividing

1104-569: 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

1152-585: The Copy menu item was selected, one would place a script in the stack using the on doMenu itemName handler, and then examine itemName to see if it was "Copy". HyperTalk also provided script control over the built-in drawing tools, simply by scripting the needed changes in paint tools and simulating mouse movements using the drag from start to end and the click at position commands. One unique distinction between HyperCard's programming language HyperTalk and seemingly similar languages like AppleScript

1200-423: 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

1248-410: The ability to parse arbitrary lists and structures. HyperTalk used an object-oriented concept for calling scripts, with objects in the stack sending "events" as messages that would be processed by handlers that declared their interest in receiving the events using the on syntax. For instance, most GUI containers would send the mouseDown message when the mouse button was clicked down, and then

1296-455: The behavior associated with that data structure. Some OOP languages support the class concept which allows for creating an object based on a definition. Nomenclature varies between the two, although they have similar semantics: The principles of modularity and code reuse in functional languages are fundamentally the same as in procedural languages, since they both stem from structured programming . For example: The main difference between

1344-408: 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

1392-469: The collection of collections was also available as a container's parts . This allowed a script to address all of the objects in a container with a single iterator. A notable feature of the HyperTalk container model was its handling of text. Every collection of text, whether a literal string in a program or text typed into a text field, was itself considered a container with multiple collections of containers within it. This allowed scripts to parse text using

1440-650: 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. For most basic operations including mathematical computations, HyperTalk favored natural-language ordering of predicates over

1488-437: The container holding that handler's code: Combining HyperTalk's string processing with the do command allowed for the construction of interactive interpreters by placing a text field on a card and then placing this code in the field's script: clickLine is a global property that returns the name and line number of the last field clicked, in a form like line 10 of card field 4 . This code first selects all of

HyperTalk - Misplaced Pages Continue

1536-490: The dialog is completed by hitting Return or clicking OK , the value is assigned to the it pseudo-variable. The second line then copies that value into a card field using the put assignment operator. Containers of a given type were also available as collections with a pluralized version of that container type as its name—the collection of the fields on a card was card fields . These collections were themselves containers with their own properties. Key among these

1584-408: The example code above within a button handler in this fashion: In the case where code was being called from multiple locations, or it was being used as a global handler for an event, the script could determine the original sender of the event using the target function. Likewise, scripts could send events to other containers using the send command and then using the navigational code to refer to

1632-514: The form: have a dual interpretation, both as procedures and as logical implications: A skilled logic programmer uses the procedural interpretation to write programs that are effective and efficient, and uses the declarative interpretation to help ensure that programs are correct. Self-documenting code In computer programming , self-documenting (or self-describing ) source code and user interfaces follow naming conventions and structured programming conventions that enable use of

1680-611: The language. Various scripting languages have implemented a superset of HyperTalk (collectively known as xTalk ): These clones and dialects (commonly referred to under the moniker of xTalk-languages) added various features to the language that are expected from a modern programming language, like exception handling, user-defined object properties, timers, multi-threading and even user-defined objects. There are also languages whose syntax and structure show influences from HyperTalk, such as: Many method names first popularized by HyperTalk have been incorporated into later languages, such as

1728-411: 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

1776-464: The same navigational commands as any other container. 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". These same sorts of expressions were used to handle file manipulation, along with

1824-414: 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 "

1872-654: 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. A new card could only be created using the New Card menu item, which could be simulated in code using doMenu "New Card" . While HyperTalk called into menu commands, menu commands also invoked handlers in HyperTalk. To run custom code when

1920-409: The string: HyperTalk used the same chunking system to produce structures like arrays or lists. Such a structure would be created by placing multiple data items in a variable, separated by commas. Various types of data could be imported into a HyperTalk script using strings that would get parsed as required. For instance, the position of objects on the screen was defined by a pair of numbers representing

1968-458: The styles is that functional programming languages remove or at least deemphasize the imperative elements of procedural programming. The feature set of functional languages is therefore designed to support writing programs as much as possible in terms of pure functions : Many functional languages, however, are in fact impurely functional and offer imperative/procedural constructs that allow the programmer to write programs in procedural style, or in

HyperTalk - Misplaced Pages Continue

2016-417: The system without prior specific knowledge. In web development , self-documenting refers to a website that exposes the entire process of its creation through public documentation, and whose public documentation is part of the development process. Commonly stated objectives for self-documenting systems include: Self-documenting code is ostensibly written using human-readable names, typically consisting of

2064-469: The text on the clicked line, then extracts the line number into a local variable, then uses do to run the text as a HyperCard script. The mouseDown message was sent to a button when the user clicked it, and mouseUp was sent when the user released the mouse inside it to trigger its action. Similarly, HyperCard sent periodic idle message, mouseEnter , mouseLeave , ... and various other messages related to navigation between different cards in

2112-418: 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

2160-475: 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

2208-437: Was that HyperTalk scripts were more lenient in what input they accepted. Apart from the above implicit declaration of variables when a value was assigned to them, and the way values were implicitly converted between types (allowing you to e.g. ask for character 2 of 1234 ), HyperCard would also recognize certain expressions and extract sub-values from them. For example: or While the end result felt similar to scripters as

2256-455: Was the number property which was widely used during iterations and similar tasks. For instance, if one wanted to hide all the fields on a card, this could be accomplished with this code: This code exposes another common feature of HyperTalk: that a property might have several names and operators. In this case the hide command, and the associated show , act by setting the value of the container's visible property. Thus hide field i

2304-425: Was then passed to the card, the background, the stack, any stacks whose scripts had been explicitly imported using the start using command, the "home stack" (a user-selected always-open HyperCard stack), and finally to the HyperCard application itself. For many simple events like mouse clicks on buttons the script would be placed directly within the object in question, the button itself. For instance, one might use

#690309