This page lists all the errors I'm aware of in the version of Learning TADS 3 that forms part of the TADS 3.0.16 distribution. Errors and corrections are listed in the order in which they appear in Learning TADS 3, along with a note of where they have been corrected in any later version. Where corrected versions exist they may either be viewed on line (for the HTML version) or downloaded (for the PDF version).
Page 12. Near the top of the page, under the first code sample, the sentence "Note that we have defined two properties of the bedroom object: name (what the room is called) and desc (its description)" should read "Note that we have defined two properties of the bedroom object: roomName (what the room is called) and desc (its description) " (that is, "name" should read "roomName").
Status: Corrected in the on-line HTML version and in the updated PDF version of 14-Jul-08.
Page 40. In the description of the SecretDoor class, "hide" should read "reveal", i.e. "for example a bookcase that can be opened to reveal a secret passage behind."
Status: Corrected in the on-line HTML version and in the updated PDF version of 08-Jan-09.
Page 94 This currently states that "We can also remap actions that take two objects (i.e. a TIAction), but some special rules apply:". The rules that follow are not entirely correct, however. Instead the text should read:
We can also remap actions that take two objects (i.e. a TIAction), but if we remap to a TIAction we should normally observe the rule that one of the objects of the remapped action should be specified as a particular object, while the other should be specified with the placeholder DirectObject or IndirectObject, meaning the direct object or indirect object of the original action.
For example, suppose we wanted put something in desk to remap to put something in drawer; we’d do it like this:
desk: Surface, Heavy 'desk*desks' 'desk'
"The desk has a single drawer. "
dobjFor(Open) remapTo(Open, drawer)
iobjFor(PutIn) remapTo(PutIn, DirectObject, drawer)
;
The rule as stated above is in fact a simplification of the actual rule enforced in the library, so that it can sometimes (but not always) be violated with impunity. The full (and more complicated) rule is that at least one of the slots in the remapped action must be specified as a particular object, and that the first concrete object must correspond to the object we’re remapping the action from. In practice this means we can safely violate the "one particular object and one placeholder" rule in remappings of the form:
dobjFor(Whatever) remapTo(WhateverElse, self, someOtherObject)
In other words, whenever we’re remapping from a dobjFor(Whatever) and self remains the direct object of the remapped command, we can put whatever we want in the indirect object slot of the remapped command.
Status: Corrected in the on-line HTML version and in the updated PDF version of 08-Jan-09.
Page 124. The clause "in practice the game will probably start grinding to a halt after a few dozen apples have been picked" is potentially misleading, so I've added the explanatory parenthesis "(not because they’re dynamically created, but because you end up with so many objects in scope at once)".
Status: Corrected in the on-line HTML version and in the updated PDF version of 08-Jan-09.
Page 299. The StringPreparser example code erroneously contains a list of arguments directly after StringPreParser. The corrected version should read:
StringPreParser
doParsing(str, which)
{
if(str.toLower.find('shit'))
{
"If you're going to use language like that I shall ignore you! ";
return nil;
}
return str;
}
;
Status: Corrected in the on-line HTML version and in the updated PDF version of 13-Apr-08.
Back to TADS 3 Resources
© 2004-2009 - Eric Eve