telescript language reference

8/8/2019 Telescript Language Reference

1/229

Telescript Language Reference

October 1995

Gene ral Magic , Inc.420 North Mary Avenu e

Su nn yva le, CA 94086


2/229

The Telescript Language Reference

1991 - 1995 General Magic, Inc.All rights reserved

Copyright and Trademark

The general idea of a remote programming language is in the public domain. Anyone is freeto form ulate his or her own expression of this idea by devising a un ique language structu re,syntax and vocabulary. H owever, G eneral M agic exercised a great deal of originalexpression when choosing th e structure, syntax an d vocabulary of the T elescript language.T herefore, G eneral Magic believes that it own s the copyright in t he structu re, syntax andvocabulary of the Telescript programming language. General Magic believes that no oneelse can create a Telescript language interpreter without violating its copyright. GeneralMagic is also seeking patent protection on some of the novel inventions in the Telescriptarchitecture and software agent functionality. Finally, General Magic owns the trademarkTelescript, which has been registered in the U.S. and many other jurisdictions. GeneralM agic uses the Telescript trad emark t o iden tify General M agics T elescript software.

General Magic wants to promote the use of the Telescript language as an enablingtechnology for creating smart networks. Therefore, we have an open, non-discriminatorypolicy on licensing our Telescript software for research and development, and commercial

purp oses. W e also encourage you to write programs in the T elescript language. Feel free toincorporate any of the sample programs contained in this document into your programs.

G eneral Magic, the General Magic logo, the M agic Cap logo, the T elescript logo, M agicCap, T elescript, and the rabbit-from -a-hat logo are tradem arks of G eneral M agic, andmay be registered in certain jur isdictions. All oth er tradem arks and service marks are theprop erty of th eir respective owners.

Limit of Liability/D isclaimer of W arrantyTH IS BOO K IS PROVIDED TO YO U AS IS. Even though General Magic hasreviewed this book in detail, GEN ERAL MAGIC M AKES N O REPRESEN TATIO NO R WARRAN TIES, EITH ER EXPRESS OR IMPLIED, WIT H RESPECT T O TH EAC C UR AC Y OR C OM PLETENESS OF TH E C O NT ENTS OF T H IS B OOK.GEN ERAL MAGIC SPECIFICALLY D ISCLAIMS ANY IMPLIED WARRAN TIESO R M ERCH AN TABILITY OR FITN ESS FOR ANY PARTICU LAR PURPO SEAND SHALL IN N O EVENT BE LIABLE FOR ANY LO SS O F PRO FIT O R AN YO T H E R C O M M E RC I AL D AM A G E, I N C LU D I N G B U T N O T LI M I T ED T OSPECIAL, INC IDENT AL, CON SEQ UEN TIAL, OR O TH ER DAMAGES, EVEN IFMAGIC KNO WS OR SHO ULD KNO W O F TH E POSSIBILITY O F SUCHDAMAGES . Some states do not allow for the exclusion or limitation of impliedwarranties or incidental or consequential damage. So, the exclusions in this paragraph mightnot apply to you. T his warranty gives you specific legal rights. You may also have other r ightswhich vary from state to state.

Important to SomeoneRestricted Rights. For defense agencies: Use, dup lication, or d isclosure is subject to therestrictions set forth in subparagraph (c)(1)(ii) of DFAR section 252.227-7013 and itssuccessors. For civilian agencies: U se, duplication, or d isclosure is subject t o t he restrictionsset forth in subparagraphs (a) through (d) of FAR section 52.227-19 and its successors.

U npu blished rights reserved un der the copyright laws of the U nited States.

G eneral Magic, Inc.420 North Mary AvenueSunnyvale, CA 94086 USA

Tel.: 408 774 4000Fax: 408 774 4010E-mail: [email protected]: h ttp:// www.genmagic.com/

Patent PendingPortions of the Magic Cap software and the Telescript software are patent pending in theUn ited States and oth er countries.

ii General Magic, Inc. Telescript Language Reference. TDE 1_0 Alphaii


3/229

Table of Contents

Table of Contents

Preface.... . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . xi

Introduction........................................................................ 1About the technology............................ ................................. ................ 1

Telescr ipt model 1Telescr ipt la nguage 2Telescr ipt engine 3Telesph er e 4

About this manual................................................................................... 4Au dien ce 4Infor ma l con ven t ions 5Formal conven t ions 5Referen ces 5

Part OneLanguage Concepts......................................... 7

Object composition.... ............. ............. ............. ............. ........ 8Operations............................................................................................. 8

Th e oper a t ion con cept 8Defin ing a n oper a t ions in t er fa ce 8Defin ing an opera t ions implement a t ion 9Implement ing a method with a block 9Main ta in ing loca l var iables 10

Attributes............................................................................................. 10Th e a t t r ibu t e con cept 10Defin ing a n a t t r ibu t es in t er fa ce 10Defin ing a n a t t r ibu t es implement a t ion 11Ma in ta in ing proper t ies 11

Constraints........................................................................................... 11Th e con st r a in t con cept 11

Defin ing a const r a in t s t ype 12Defin ing a const ra in t s passa ge 12Specifying a class 12Searching for a class 13

Object manipulation..... .............. .............. ............. .............. . 14Object references................................................................................. 14

Th e r eference con cept 14Acquir in g a prot ect ed r eferen ce 14Acquir ing a voided r eference 14Pr ot ect in g object s 15

Object manipulation.............................................................................. 15Copying a n object 15Dest r oying a n object 16

Object ownership. .................................... .................................... ........ 16

Th e owner sh ip concept 16Isola t in g a n object 17Lockin g a n object 17Fr eezin g a n object 17Th a win g a n object 18Transfer r ing owner sh ip 18

Object aggregation..... .............. .............. .............. .............. .. 19Class definitions................................................................................... 19

The class concept 19The class family concept 19

General Magic, Inc. Telescript Language Reference. TDE 1_0 Alpha iii


4/229


Specifying a classs in ter face 19Specifying a classs implementa t ion 20Ela bor a t ing upon inh er it a n ce 20

Class relationships................................................................................ 21Rela t in g on e fla vor t o a n ot h er 21Rela t in g on e mix-in t o a n ot h er 21Rela t ing one cla ss t o a n ot h er 22

Order ing a class and it s superclasses 22Search ing a class and it s superclasses 22

The constructor............. ................................................................ ....... 23Th e const r uct or concept 23Deciding the const ructors formal a rguments 23Deciding t he const ruct or s a ctu a l a rgument s 23Per forming th e const ruct or 24

Object terminology............... .......... ........... .......... .......... ...... 25

Part TwoLanguage..................................................... 27

Basic constructs ..... ..... ..... ..... .... ..... ..... ..... .... ..... ..... ..... .... ... 28Statements and expressions................................................................. 28Operation and cascade requests........................................................... 28Objects and their identifiers................................................................... 28Global variables..................................................................................... 29

Definitions........................................................................ 30Module definitions................................................ ................................ 30Interface definitions.............................................................................. 30Class definitions................................................................................... 31

Defin ing a class 31Defining a classs formal parameters 31Defining a classs immediate superclasses 32Defin ing a classs fea tu res 32Defin ing fea t u res r equester s 32Defin ing fea tu res r esponder s 33

Defin ing a t t r ibu tes or proper t ies 33Defin in g opera t ions 33Sea ling fea t u res 33

Attribute definitions........................ .................................. .................... 34Defin in g a n a t t r ibu t e 34Defin ing a n a t t r ibu t es signa t u r e 34Defin in g a n a t t r ibu t es get t er or set t er 35

Operation definitions......................................... ................................... 35Defin ing a n opera t ion 35Defin ing a n oper a t ions s igna t u re 35Defin ing an opera t ions expected a r gumen ts 36Defining an opera t ions named a rguments 36Defin ing an opera t ions unn amed a rguments 37Defin ing an opera t ion s met hod 37Defin ing a block 38

Constraint definitions............................................................................ 38Defin ing a con st r a in t 38Defin ing a const r a in t s t ype 38Defin ing a const ra in t s passa ge 39Defining a class specifier 39

Statements........................................................................ 40Basic statements.................................................................................. 40

Using an expression as a st a t ement 40The do st a t ement 40The if s t a t emen t 40

iv General Magic, Inc. Telescript Language Reference. TDE 1_0 Alphaiv


5/229


6/229


Object programs................................................................................... 62

Part ThreePredefined Class Concepts.......................... 63

Places.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Organizing the telesphere..................................................................... 64

Orga n izing a r egion 64Or ga n izing a n en gine 64

Addressing a place............................................................................... 65Specifying a r egion 65Specifying a place 65Specifyin g rou t in g advice 65

Managing occupants............................................................................. 65Ent er in g a pla ce 65Exit ing a pla ce 66Keepin g t r ack of occupan t s 66

Agents... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Traveling to other places....................................................................... 67

Con st r u ct in g a t icket 67

Sa t isfying a t icket 68Receiving a t icket st u b 68Goin g t o a n ot h er pla ce 68Sen din g clon es t o ot h er pla ces 68

Selecting a route.......................................... ........................................ 69En su r in g a rou t e 69Using reservable means 69Using exist ing con nect ion mean s 69

Meeting other agents............................................................................ 70Const ru ct in g a pet it ion 70Sat isfying a pet it ion 70

Managing meetings........................... ................................................... 71Beginn in g a meet ing 71Ending a meet in g 71Keeping t r ack of a cqua in ta nces 71

Processes.... . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 72Defining a process................................................................................ 72

Branding a process 72Phasing a process 72Act iva t ing a process 72Pr ior it izing a process 73Termina t ing a process 73

Naming a process................................................................................. 73Specifyin g a n a u th or it y 74Specifying a process 74

Contacting a process through an operation............................................ 74Contacting a process through a package................................................ 74

Offer ing packages 74Search ing packages for object s 75

Contacting a process through an event.................................................. 75Ca t egor izin g a n even t 75Sen ding a signa l 76Ena bling or disa bling a signa l 76Receiving a signa l 76

Contacting a process through a resource............................................... 76Using a r esource 77Using a r esource exclusively 77Using a r esource condit iona lly 77

Losing contact with a process................................................................ 77

vi General Magic, Inc. Telescript Language Reference. TDE 1_0 Alphavi


7/229

Table of Contents

Permits........... . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 78Defining a permit................................................................................... 78

Gra nt in g a n act ion 78Gr an t ing a r esour ce 78Gr an t ing a form of r ecogn it ion 79

Receiving a permit................................................................................ 79Receiving a na t ive permit 79

Receiving a r egiona l permit 80Receiving a loca l permit 80Receiving a t emporary permit 80

Reconciling permits................................................................... ........... 81In ter sect ing t wo permit s 81Order ing two permit s 81Order ing two capabilit ies 81Increa sing or decreasing a capabilit y 81

Enforcing the current permit.................................................................. 81Det er min ing t he cur ren t permit 82Viola t in g t he cu r ren t per mit 82Exh a ust in g t he cur ren t per mit 82

Patterns........... . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 83Defining and using a pattern.................................................................. 83

Defin ing a pa t t ern 83Using a pa t t ern 83

Requiring a match................................................................................. 83Requir ing a match 84Requir ing a n a nchored ma t ch 84Requir ing successive mat ches 84Requir ing a r epea ted ma tch 84Requir ing a sin gle match 84

Requiring a character............................................................................ 85Requir ing a cha ra ct er wit h cer t a in a t t r ibu t es 85Requ ir ing a cha ra ct er in a cer t a in list 85Requir ing a ch a ra ct er n ot in a cer t a in lis t 86Requir ing a cha ra ct er in a cer t a in in ter va l 86Requir ing a ch ara ct er wit h a cer t a in na me 86Requir ing a cha ra ct er 86

Calendar times................................................................... 87Defining a calendar time........................................................................ 87Accessing a calendar time..................................................................... 87

Accessing the t ime 87Accessing t he da t e 87

Normalizing a calendar time.................................................................... 88Normalizing the t ime 88Normalizing the da te 88

Part FourPredefined Classes....................................... 91

Legend................................................................................................ 92

Agent........... . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 93Authenticator..................................................................... 95Bit.......... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Bit String.............. ........... ........... ........... ........... ........... .... 97Boolean............ . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . 98Calendar Time ..... ..... ..... ..... ..... ..... ..... ..... ..... .... ..... ..... ..... ... 99Cased ........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Character ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... 103Class........... . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 105

General Magic, Inc. Telescript Language Reference. TDE 1_0 Alpha vii


8/229


Class Exception............ ........... .......... .......... .......... .......... .. 107Class Name ...... ...... ....... ...... ...... ...... ...... ...... ....... ...... ...... . 108Collection........................................................................ 109Collection Exception........................................... ................ 112Compared....................................................................... 113Death Event ...... ...... ....... ...... ...... ...... ...... ...... ....... ...... ...... . 114

Dictionary ...... ...... ...... ...... ...... ...... ....... ...... ...... ...... ...... .... 115Engine Place ...... ...... ...... ...... ...... ....... ...... ...... ...... ...... ...... . 118Equal........... . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 120Event........... . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 121Event Process................................................................... 122Exception........................................................................ 124Execution Exception .... ... ... .... ... ... .... ... ... .... ... ... .... ... ... .... ... .. 125Existing Connection Means........... ......... .......... ......... .......... .. 127Exit Event ...... ...... ...... ...... ...... ...... ....... ...... ...... ...... ...... .... 128Identifier......................................................................... 129Integer ........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Iterator........................................................................... 132Kernel Exception............. .......... .......... .......... .......... .......... 133

List.......... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Means........... . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . 139Meeting Agent ...... ...... ...... ....... ...... ...... ...... ....... ...... ...... .... 140Meeting Exception.............................................. ................ 141Meeting Place................................................................... 142Miscellaneous Exception .. ... .. .. ... .. .. ... .. .. ... .. ... .. .. ... .. .. ... .. .. ... .. 144Named............ . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 145Nil........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Number........... .. . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . 147Object............................................................................ 150Octet.............................................................................. 154Octet String...................................................................... 155Ordered.......................................................................... 157Package.......................................................................... 158Package Process................................................................ 160Part Event ...... ...... ...... ...... ...... ...... ....... ...... ...... ...... ...... .... 163Pattern ........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Permit............................................................................ 166Permit Process.................................................................. 169Petition........................................................................... 172Place ........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Primitive......................................................................... 177Primitive Exception ... ... .... ... ... .... ... ... .... ... ... ... .... ... ... .... ... ... . 178Process ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... .. 1 79Process Event................................................................... 182

Process Exception................ ............ ........... ............ ........... 183Programming Exception....................................................... 185Protected......................................................................... 186Real........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Reservable Means............ .......... .......... .......... ........... ......... 188Resource......................................................................... 189Same............ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Set........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Stack............ . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 194String ..... ...... ...... ...... ...... ...... ...... ...... ..... ...... ...... ...... ...... 196

viii General Magic, Inc. Telescript Language Reference. TDE 1_0 Alphaviii


9/229

Table of Contents

Teleaddress...................................................................... 198Telename ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... 199Ticket ..... ...... ...... ...... ...... ...... ...... ...... ..... ...... ...... ...... ...... 200Ticket Stub.............................................................. ........ 202Time............ . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . 203Trip Exception.................................................................. 205

Uncopied........................................................................ 207Unmoved........................................................................ 208Verified.......................................................................... 209Way............ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Appendix: Safety weaknesses .... .... ..... .... .... .... .... ..... .... .. 211

Masquerade....................................................................................... 211Leakage or loss of data........................................................................ 211Denial of service................................................................................. 211Other weaknesses.............................................................................. 212

Index.......................................................................... 213

General Magic, Inc. Telescript Language Reference. TDE 1_0 Alpha ix


10/229


x General Magic, Inc. Telescript Language Reference. TDE 1_0 Alphax


11/229

Preface

Preface

The personal comput er h as flourished becaus e it is a n open platform. Ontha t plat form th ousan ds of independent softwar e developers h ave built awealth of sta nda lone app licat ions. Because of th eir work, anyoneengineer,

mathematician, financier, writer, or musiciancan find applications thatmake t he personal comput er a n indispensa ble tool.

The same cannot be said of networks. Rath er th an a wealth of distribut ed,or commun icat ing, applicat ions, one finds for th e most pa rt only the familiarremote filing, remote prin tin g, electr onic ma il, an d dat aba se applications.

Todays net worksespecially public net workspose an insu rm ount ablebarr ier t o the development of commun icat ing applications. Su ch a pplicat ionshave a functional n eed to distribute th emselves among the comput ers ofindividual users a nd th ose tha t u sers sha re, the servers. However, suchdistr ibution is impossible for reas ons of logistics, port ability, and s afety.

Genera l Magic ha s developed a softwa re t echn ology tha t r emoves th e barr ier

to developing communicating applications. Conceived for a new breed ofconsumer electr onics pr oduct, th e personal intelligent communicator,Telescript technology enables a new breed of network, a network that is ahighway for mobil e agentsan d th ereby an open plat form for developers.

The economic and social consequ ences of public net works t ha t a re pla tform spotentia lly dwarf th ose of the per sonal compu ter . A net work equipped formobile agents makes possible an electronic marketplace in which the agentsof providers an d consu mer s of goods a nd ser vices can find an d int era ct wit heach other. New forms of electronic commerce and community will result.

General Magic, Inc. Telescript Language Reference. TDE 1_0 Alpha xi


12/229


xii General Magic, Inc. Telescript Language Reference. TDE 1_0 Alphaxii


13/229

Introduction

Introduction

Telescript technology int egrat es an electr onic world of computer s an d th enetworks th at link them. This world is filled with Telescript places tha t a reoccupied by Telescript agents . Each place or agent in t he electronic world

represents an individual or organization in t he physical world, its aut hority.

Both agents and places a re softwar e objects. A place is st at iona ry, but anagent can tr avel from place to place at will. The agent can do th is wheth erth e two places are in th e same compu ter or in different compu ter s. If th ey arein different comput ers, a network is involved.

The electr onic world of Telescript techn ology can be called an electronicmarketplacebecause within it the agents of providers and consumers ofgoods and services can find an d inter act with one an other. Thu s Telescripttechnology makes possible a new generation of electronic commerce.

Note. For a fuller exploration of the applications of Telescript technology, see theGeneral Magic white paper , Telescript Technology: Mobi le Agents.

About the technology

This section describes the Telescript m odel; the Telescript lan guage, whichimplements the model; the Telescript engine, which implements thelanguage; and t he t elesphere, which links engines.

Telescript model

Th e Telescript model is th e view of computer s a nd compu ter commu nicationsuggested earlier and illustrated herethat is, an electronic world composedofplaces, each occupied by agents, which can travel from place to place.

The power repr esent ed by an agent s mobility is counter balan ced by permits,which a program mer or adm inistrat or can u se to grant only particularcapabilities to part icular agent s or places on par ticular occasions.

A places or agents authorityin t he physical world is r evealed by itstelename, which it can neit her falsify nor with hold from an other place oragent. A place, but n ot an a gent, also has a teleaddress, which designat es itslocat ion in th e electr onic world a nd r eveals the a ut hority of th e individual ororganization t hat is operat ing the comput er in which t he place exists.

As in the pr evious illust ra tion, the t ypical place is perma nent ly occupied byan agent of th e places au th ority, and is t emporar ily occupied, or visited, byagents of other aut horities. For example, a t heater ticketing place might be

General Magic, Inc. Telescript Language Reference. TDE 1_0 Alpha 1


14/229


occupied by a ticketing agent that provides information about theater events,and sells t ickets to them as well. Agents of oth er a uth orities would visit t heticketing place to use th e services th e ticketing agent offers.

The typical agent tr avels to obta in a service offered remotely. For exam ple,an a gent might go from a place in a us ers persona l commun icat or to theticketing place to obta in th eater tickets from the ticketing agent. In genera l,

an agent tr avels to meet and int eract with a remote agent. The agentsinter act pr ogram mat ically, using object-orient ed techniques.

Because agents dont intera ct at a distance, the m odel employs remoteprogra mming (RP ) ra th er th an r emote procedur e calling (RP C ). RP improvesupon RP C by ena bling computer s to intera ct with out commun icat ing; th isimproves th e perform an ce of their int eractions by reducing th eir lat ency. RPalso lets comput ers customize one another by stat ioning th eir own a gentsan d th us in effect t hems elvesin each others domains.

Note. In fact , the need for a place to be perman ently occupied by an agent of th eplaces a ut hority is so common t hat the model lets this one agents functionali tybe incorporat ed in the place, so tha t a sepa ra te agent isn t requir ed.

Telescript languageTh e Telescript languageisan object-orient ed r emoteprogramming language. Itsupplements, rather t hanreplaces, system sprogramming languageslike C an d C++. Asillust rat ed, only the part sof an a pplication t hat movefrom place to place (th e agent s) or h ost visiting agent s (the pla ces) arewritten in t his language.

The langu age has th e following cha ra cter istics:

Safety. The language prevents an agent from directly manipulat ing itshost comput er, exceeding its per mit, or int era cting with oth er agent swithout t heir appr oval. This helps prevent t he sprea d of virus es.

Portability. The language ma kes no concessions to th e ha rdwar e orsoftware constraints or peculiarities of a particular computer. Thismeans t hat an a gent or place can be executed an ywhere in a network.

Extendability. The lan guage gives to classes of inform at ion object th at

th e programm er defines the sta tu re of classes tha t ar e built int o thelanguage. This lets th e language be extended for part icular purposes.

Elevation. The langua ge makes no distinction between volatile andnonvolatile st orage. Every inform at ion object is per sisten t. This in crea sesan a gents level of abst ra ction an d decreases it s size.

The Telescript langua ge is communication-centric. Just as PostScript isdesigned for describing complex images, an d Mat hema tica for perform ingcomplex math emat ics, th e Telescript langua ge is designed for doing complexnetworking tasks such as navigation, tran sport at ion, and aut hent ication.

2 General Magic, Inc. Telescript Language Reference. TDE 1_0 Alpha2


15/229

Introduction

The languages go operat ion lets an agent t ravel. The agent m erely presentsa ticket, which identifies its destination. An agent executes the go operationwhen it n eeds to get from one place to an other. The next inst ru ction in t heagents pr ogram is execut ed at the agents destina tion, not at its origin. In asense, the language reduces networking to one program instruction.

The languages meet operat ion lets two agents meet. One agent pr esents a

petition, which ident ifies the other a gent, which must agree to a meetin g. Anagent executes the meet operat ion when it needs assist ance from anotheragent. By meeting, th e two agents r eceive referencesto one an oth er. Thereferences let th e agents int era ct as peers, using object-orient ed techniques.

Notes.

Because i t is for r emote program ming, the language includes concepts th at

span the r ealms of languages, operating systems, an d networks.Convent ional ly separate , in th is language these ar eas ar e brought together .

Often, a s above, th e term languagerefers broadly to both t he Telescript

programm ing langua ge and th e Telescript predefined classes, which providemu ch of th e techn ologys fun ctionality (for exa mple, t he go operation).Sometimes th e term refers n arr owly to the programm ing language alone.

Telescript engine

A Telescript engineis a compu ter program th at execut es th e langua ges objectprogram s. An a gent or place is powerless with out an engine. An engine canexecut e two or m oretypically man yobject program s concur ren tly.

As illust ra ted, an en gine designed for port ability draws u pon the r esources ofits comput er via applicat ion pr ogra mmin g interfaces (API s). A storage APIprovides a ccess t o the compu ter s n onvolatile st orage, which t he en gine usesto preserve places an d agents in case of a crash. A tr ansport API providesaccess to th e computer s comm un icat ion media , which t he engine us es tosend agent s to, and receive agents from, oth er engines. An extern alapplications API lets th e par ts of an applicat ion writ ten, for example, in Ccreat e and intera ct with t he part s written in t he Telescript language.



16/229


An engine designed to support t he places an d agents of many au thoritiesimplement s privileged escapes from th e langua ge, which mak e possible theconstruction of operational, administrative, and managerial (OAM) toolsexterna l to the engine. Such tools ar e importa nt to the s uccess of large-scalecommun icat ion systems for example, th ose offered as public services.

Telesphere

Th e telesphereis composed of one or more int erconnected en gines, each ofwhich provides places between wh ich a gents can tr avel, subject t o accesscontrols. This requirement makes the telesphere homogeneous with respectto the pr ocessing as well as th e str uctur e of inform at ion.

As illust rat ed, engines are interconnected so tha t t hey can t ran sport agentsbetween th em whenever the agents request t he go operat ion. An agent istr ansported a s a n octet str ing using su itable commu nication protocols. Thesending engine encodes th e agent t o produce the octet str ing. Encoding theagent ent ails encoding th e lesser objects of which th e agent is const ru cted.The r eceiving engine decodes th e octet s tr ing to reconst ru ct t he agent . Allengines encode, decode, an d execut e agent s in th e sam e way.

About this manual

This section pr ovides context for t he ma nu al.

Audience

This ma nu al is two books under one cover, both wr itt en for t he Telescriptprogram mer . The first defines t he Telescript lan guage itself. The second bookdefines the Telescript pr edefined classes. Thus t he ma nua l has four par ts:

Par t OneLanguage Concepts

Pa rt TwoLangua ge

Par t ThreePredefined Class Concepts



17/229

Introduction

Par t F our Predefined Classes

The man ual a lso has an a ppendix which lists the k nown shortcomings ofthis version of the language and its predefined classes from a safetystandpoint.

This reference manua l demands mu ch of the r eader. A book th at m akes th e

technology more widely accessible is being written.

Informal conventions

This m an ua l observes th e following inform al convent ions:

A clas s is den oted by it s iden tifier (Boolean ). If its sever al words

(MeetingPlace), a space is inserted between words (Meeting Place).

A class member is denoted by its ident ifier, but with its first char acter

lowercase (boolean ). If th e iden tifier is severa l words (Meetin gPla ce),a s pace is inser ted bet ween words (meet ing place).

An actual par amet er is denoted by its forma l para meter followed by the

word par am eter (th e Item parameter).

An actual argument is denoted by its formal argument followed by the

word argument (the ticket argument).

An att ribut e is denoted by its ident ifier followed by th e word att ribut e

(the length attribute).

An operat ion is denoted by its identifier followed by th e word operat ion

(the copy operation).

An except ion is referr ed to as follows. IfX is th e ident ifier of Except ion or

a subclass thereof, throws X mean s th rows a m ember ofX.

As here, the t erm identi fier sometimes denotes an identifiers t ext, rat her

th an t he ident ifier as a whole. This is a mer e economy of expression.

Formal conventions

This manual uses Backus-Naur Form (BNF) to describe str ings an d octetstr ings. In su ch descript ions, th e man ua l observes th e following convent ions:

| separa tes synta ctic alternat ives.

[ an d ] sur round a synt actic option.

and sur round a term inal th at is a str ing (ra ther th an a n octet

str ing). Wheth er t he ter mina l is uppercase or lowercase is significan t.

If two or m ore segments of a str ing or a n octet str ing could satisfy a

nontermina l, the longest segment is t aken t o satisfy it.

In prose, for example, Match is shortha nd for th e char acters th at

satisfy the Match nonterminal.

References

This ma nu al incorporat es by reference the following document s:



18/229


The Unicode Standard: Worldwide Character Encoding, Volume 1,

Version 1.0, The Un icode Consort ium , Addison-Wesley, 1991.

Unicode Technical Report #4, The Unicode Standard,Version 1.1 (Pr epu blicat ion E dition), Unicode In c., 1993.

Fi le System SafeUCSTransformation Format (FSS_UTF),

X/Open Preliminary Specification, Document Number P316, X/Open.

IEEEStandard for Binary Floating-Point Arithmetic,754-1985 (Reaff 1991), Amer ican N at iona l Stan dar ds Inst itut e (ANSI).

Hereafter a nd in compa nion documents, th e language manualis the presentdocum ent, the Unicode specificati onth e first two document s cited above.



19/229

Language Concepts

Part One

LanguageConceptsThis part of the manual defines the major conceptsin particular, the objectand class abst ra ctionsth at un derlie the langua ge.

Chap ter s ar e devoted t o the following topics:

1. object composition, which describes how an objects extern ally visibleinter face and exter na lly invisible implementa tion ar e defined.

2. object man ipulation, which describes how objects are man ipulated.

3. object a ggregation, which describes how objects with the sa me interface

an d implementa tion are defined collectively ra th er th an in dividua lly.

4. object t erminology, which int roduces some import ant terminology.



20/229


Object composition

An objectis the unit of both information and information processing. It hasan externally visible interface, consisting of operations and attributes, andan externally invisibleimplementation, consisting of methods and properties.

Note. An object can be simple (for example, a boolean) or complex (a dictionary),pass ive (a st ring) or active (an agen t or a pla ce).

Operations

This section intr oduces th e concept of an operat ion a nd describes how anopera tions inter face and implement at ion ar e defined.

The operation concept

An operati onis a ta sk t ha t one object performsat a s econd s request. Theobject that requests t he operat ion is the requester. The object t ha t per form sit is the responder. The requester an d the r esponder may be the sam e.

When an operation is requested, the requester provides the responder withzero or more objects, the operations actual arguments(or arguments). Thefirst zero or m ore ar guments a re fixed in number. The rem aining zero ormore, which t he operat ion ma y not allow, are varying in number. Aconstr aint (see Const ra int s) is placed individua lly upon ea ch argu mentfixed in num ber an d collectively upon each ar gument varying in nu mber.

When an operation is performed, it either succeedsor fails. If the operat ionsucceeds, the responder may returnto the requester a s ingle object, t heoperations result. A const ra int is pla ced upon th e resu lt. If th e opera tionfails, th e responder throwsto th e request er a single object, an exception. Therequester can catchth e exception. Unless it does so, the en gine propagatesth e exception by effectively cau sing th e request er t o thr ow it.

An opera tion is pr ivate or pu blic. An object perform s a private operationtowhich the engine, ra th er t ha n t he object it self, controls accessonly at it sown request . An object per form s a publi c operationat eith er its own requestor th at of an other object. (Thus pu blic operat ions let objects in ter act.)

An operat ion t hat an agent or place performs is sponsored or u nsponsored.An agent or place perform s a sponsored operationunder its own auth ority,which th e engine inst ates at the performa nces star t an d withdr aws at t hefinish. An unsponsored operationis perform ed with no cha nge in aut hority.

Note. The choice between pr ivate a nd p ublic and t he choice between s ponsoredand u nsponsored are orthogona l.

Defining an operations interfaceAn operation has an interfacewhich dicta tes how th e requester and t heresponder inter act. The inter face specifies th e following:

An identifier that distinguishes the operation from the others the object

performs and th e att ributes it gets and s ets (see Defining an a tt ribute).

How many fixed argument s th e requester supplies and th e constr aints

th at ar e placed upon t hose argument s individually (see Constr aints ).



21/229

Language Concepts

Whether t he requester su pplies varying arguments a nd, if so, the

const ra int t ha t is placed collectively upon each of th ose ar gument s.

Whether t he operat ion retu rns a r esult and, if so, the const raint tha t is

placed upon th at r esult.

Whether the operat ion is private or public and, if the r esponder is an

agent or place, whether the operat ion is sponsored or u nsponsored.

Defining an operations implementation

An operation has an implementationwhich dictates how the responderperforms the operat ion. The implementa tion t akes t he form of a method.Like the opera tion it implements, a met hod is performedand succeedsor fails.

There ar e thr ee kinds of method. A predefined methodis par t of th e engine. Auser-defined method, written in t he langua ge, is par t of an object pr ogramtha t t he engine interprets. An out methodis part of system or applicationsoftware outside the engine and accessible to it by means of its API s.

Notes.

For exam ple, an object some of whose operat ions h ave out met hods might

provide access t o an informa tion service offering n ews, weath er forecast s,stock ma rket results, an d other informa tion from outs ide the engine.

Becau se a reference to the sa me object can be conveyed to any nu mber of

agents and places, an objects meth ods must be prepared in general for t heobjects operat ions to be request ed any nu mber of times concurr ent ly.

Implementing a method with a block

A block, the t ypical meth od, is a list of sta tement s (see Sta temen ts) andvariable declarations. A variable declarationdefines th e identifiers an d t ypeof one or more local var iables. A var iable declar at ion m ay a lso initialize thevaria bles it intr oduces by assigning th e same object to all of them.

The scope of a local var iable is defined in t erm s of var iable declar at ionsegments. A variable declarati on segment is one or m ore variable declar at ionswith no adjacent var iable declarat ions a nd with n o int ervening statement s.A local var iables scope extends from th e beginnin g of the segmen t in wh ichits declared t o the en d of th e block. Even if declar ed in different segment s,two local var iables declared in th e sam e block shall ha ve different iden tifiers.

Besides declaring local variables explicitlyas d escribed above, a block maydeclare local variables implicitly. Any imp licit va ria ble declar at ions effectivelyprecede the firs t it em of th e block. A block sh all not declare explicitly a localvaria ble whose ident ifier is t ha t of a local variable it declares implicitly.

A block is executedby execut ing its item s from left t o right . A st at ement isexecut ed as discuss ed elsewhere (see Sta tem ent s). A var iable declar at ion is

executedby initializing an y of its local var iables th at requir e initialization. Ablocks valueis as follows. If th e blocks las t it em is a st at emen t, t he blocksvalue is th at sta tement s value. Oth erwise the blocks value is null.

Notes.

Stat ements and variable declarations ma y be freely intermixed.

A blocks context deter mines th e local va riables (if any) it declar es implicitly.

In par t icular , the blocks that f igure in meth ods, catchphra ses, the for-tos t a t em en t , and the for-in sta temen t declare local var iables implicitly.



22/229


Maintaining local variables

The int ern al st at e of one per form an ce of a m eth od is zero or m ore objects , themethods local variables. Theyre s et t o nil before th e met hod is performedand discarded after. In between th e method can geta nd setthem.

A constra int is placed upon a local variable just a s it is u pon a n a rgument or

a r esult. However, the const raint s passa ge is disregarded a nd its type isenforced by the compiler bu t not by t his vers ion of the engine.

Attributes

This section introduces the concept of an attribute and describes how anatt ributes int erface an d implementat ion ar e defined.

The attribute concept

An attributeis an object th at one object getsor setsat a s econd s request. Theobject t hat requests the a ttr ibute is th e requester. The object t ha t gets orsets it is the responder. The requester a nd th e responder may be the sa me.

An a tt ribute is th e product of two operat ions, its getter a nd sett er, which t heatt ributes requester requests a nd t he at tr ibutes responder performs . Thegettergets the at tribute. It has no arguments but has th e attribute as itsresult. The settersets the attr ibute. It has no result but has th e attribute asits sole argumen t, an a rgument fixed in nu mber. The same constr aint (seeConst raint s) is placed upon th e getters r esult a nd t he sett ers ar gument.

An a tt ribute m ay be read only. A read onlyattributeto which the engine,ra th er t ha n t he object it self, cont rols accesscan not be set. A read onlyatt ribute h as n o setter and s o is the product of its getter alone.

Note. Like an y operat ion, th e getter or sett er is private or public an d may besponsored or u nsponsored. The choices ma de for t he gett er a nd t he choices madefor t he set ter a re orthogonal, al th ough this version of th e compiler l inks th em.

Defining an attributes interface

An att ribute has an interfacewhich dicta tes how the requester an d theresponder inter act. The inter face specifies th e following:

An ident ifier which distinguishes th e att ribut e from th e oth ers t he object

gets and sets an d the operat ions it performs .

Whether th e attr ibute is read only.

The const raint placed upon the getter s resu lt. (Unless th e att ribute is

read only, the setter s ar gument is subject t o the sam e const ra int.)

Whether t he getter is pr ivate or pu blic and, if the r esponder is a n a gentor place, whether the getter is sponsored or unsponsored.

Unless the at tr ibute is read only, whether t he setter is private or public

and, if the responder is an a gent or place, whether t he sett er issponsored or unsponsored.

Note. The manua l sometimes speaks as if an at tr ibutes getter and set ter ha ddifferent identifiers. These different identifiers are fictions of the exposition.



23/229

Language Concepts

Defining an attributes implementation

An att ribute has an implementationwhich dictates h ow the responder getsand set s th e att ribut e. The implementat ion t akes t he form of a method forthe a tt ributes getter an d, unless the at tr ibute is read only, one for its set ter.

An at tr ibutes gett er an d setter ma y have predefined methods tha t ma intain

the attribute as a property of the responder (see Maintaining properties).The propert y has t he at tribut es identifier. The setter discards t he propertyand substitutes its a rgument for it. The getter return s the pr operty as itsresult, th us giving to its r equester t he object tha t t he sett er r eceived mostrecently.

A predefined att ribute h as t he above predefined methods for its getter a ndsett er if it isn t r ead only. The ma nu al notes t he few exceptions to th is ru le.

A user-defined att ribute h as t he above predefined methods for its getter a ndsett er a ccording to the following ru le, which r equires informa tion in lat ersubsections: a concret e user -defined class ha s pr edefined met hods for t hegetter an d sett er of a us er-defined inst an ce at tr ibute if, collectively, the classand its implementa tion superclasses provide a met hod for neither operat ion.

Notes.

Getting th e typical at tr ibut eunless i ts passed byCopy(see Defining a

const ra ints pa ssa ge)exposes its propert y to ongoing examina tion.

Get t ing the typical a t t r ibuteunless the a t t r ibute i s passed byCopy or

byProtectedRef or the responder a ccesses the pr operty with a protectedreferen ceexposes its propert y to ongoing modification.

If the typical attribute is required by its type to be, for example, a member of

Event , an d an instance of a su bclass of Event i s g iven t o the se t t er , theget ter la ter re tu rns t hat instance of that su bclass , not an instance of Event .

Maintaining properties

An objects int ern al st at e is zero or m ore objects , its properties. Theyre set t onil before the const ru ctor is performed an d discarded when th e object isdestroyed. In between the methods the object performs can getand set them.

Ea ch of an objects implem ent at ion member class es (see Specifying a classsimplement at ion) defines zero or more of the objects pr operties. The meth odstha t a par ticular implementat ion member class defines can get an d set th eproperties defined by tha t class but not th ose defined by oth er classes.

A constra int is placed upon a property just as it is upon an ar gument or aresult. H owever, th e const raint s pa ssage is disregarded an d its type isenforced by the compiler bu t not by t his vers ion of the engine.

ConstraintsThis section intr oduces th e concept of a const ra int a nd describes how aconst ra ints t ype and pa ssage ar e defined.

The constraint concept

A constraintdicta tes a n objects type as well as its pa ssage between a noperat ions reques ter a nd r esponder. An object su bject t o th e constr aint ischecked (stat ically by the compiler a nd dyna mically by the en gine) to ensu reth at it sa tisfies t he specified type. Then th e object is passed a s specified.



24/229


Note. Constraint s are imposed upon attr ibutes, the argument s and result s of operations, and properties; types alone are imposed upon local variables and uponobjects in certa in other roles in stat ement s an d expressions. However, thepass age of a pr operty is disregarded a nd th e type of a pr operty or a local variableis enforced by the compiler but not by th is version of the en gine.

Defining a constraints type

A type, a generalizat ion of a class, is a predicat e th at certa in objects satisfy.A type iden tifies, by mea ns of a class specifier (see Specifying a clas s), abase class, whose inst ances sat isfy the t ype, and two booleans, isSubclassOKand isNilOK, which ma y ident ify other objects th at sat isfy th e type. If th eisSubclassOKboolean is true, instances of interface subclasses of the baseclass sa tisfy the type. If the isNilOKboolean is true, nil sat isfies the t ype.

Types are r elated in th e following ways. A supertypeof one type is a secondtype, satisfied by the objects t hat sat isfy the first t ype, but perha ps sat isfiedby oth er objects as well. The first t ype is a subtypeof th e second. On e type iscompatiblewith a nother if th e first types base class is compat ible with t heseconds. A class is compatiblewith itself and with its int erface superclasses.

Defining a constraints passage

A form ofpassagedicta tes h ow the engine conveys an object bet ween anopera tions r equester an d responder (including a gett ers or sett ers). Theform s of pa ssa ge are defined in t erm s of references (see Object r eferences).

The following ta ble defines t he form s of pass age. Throughout th e ta ble, Sisth e reference th at th e objects sour ce gives to th e engine. D, which t he enginederives from S, is th e reference th e engine gives t o the objects dest inat ion.

Passage Defini ti on

byRef D is S.

byProtectedRef Dis a pr otected r eference to the r eferent ofS.

byUnprotectedRef Dis S. However, ifSis a pr otected reference, th e engineth rows Reference Pr otected.

byCopy The engine copies th e referent ofSand passes byOwnerth e result ing reference to th e result ing copy.

byOwner D is S. However, unless th e referent ofSis an a gent orplace, th e engine tr an sfers ownership of its closur ebetween th e cur rent owner a nd th e responders owner(see Transferring ownership).

An objects pas sage is explicit in a const ra int a nd implicit elsewhere in t helangu age. The passa ge of an opera tions ar gumen t or resu lt is explicit, tha t

of an operat ions res ponder or t hr own except ion implicit. An opera tionsresponder is passed byRef. A th rown exception is pas sed byOwner. However,a li ghtweight primit iveis always passed byCopyno mat ter what its passage.

Specifying a class

A class specifierdenotes a class u sing ident ifiers. If the class is derived from aclass family, an ident ifier denotes th e class family, a class specifier ea chpara meter u sed in the derivation. Otherwise an identifier denotes the class.



25/229

Language Concepts

The ident ifier us ed in a class specifier denotes a class listed below. Each listitem describes zero or m ore classes t o which ident ifiers a re bound. The it emsappea r in order of decreasing precedence. Of all the class es th e list includes,th e identifier denotes t he one of highest precedence with t ha t ident ifier:

1. If the curr ent class (see Curr ent objects) was derived from a classfamily, the classes tha t const itut e the para meters u sed in the derivation.

2. If the curr ent class or its class family was defined in a module, theclasses in t he m odule (which include th e cur rent class or its class family).

3. The predefined classes.

Thus th e compiler k nows of th e predefined class es. In fact, th e compilerexhibits k nowledge of cert ain pr edefined feat ur es beyond their s ignatu res.For example, the predefined copy operat ions signa tu re is ObjectObjectbut t he compiler r egards it as (t.(tt))(obj.class), for any object, obj.

Note. Further examples are given elsewhere (see Applying an infix operator).

Searching for a class

A class s pecifier iden tifies a class t o the compiler. Sometim es a class m ust beidentified to th e engine so tha t t he engine can find it at run time. The enginemust find classes upon which classes to be constructed depend, the classes ofwhich inst ances are t o be const ructed, and other classes in other situa tions.

While classes, like oth er objects, can be exchanged as the ar guments andresults of operations, the engine provides a more systematic means of classdistribution an d uses it for t he above pur poses. When offered a type and zeroor more members of the predefined Pa ckage class, th e class search algori thmlooks am ong th e following classes for one th at sat isfies t he t ype. If one ormore sat isfy th e type, the algorit hm pr oduces one. Other wise it produces nil:

The predefined classes.

The values of the packages.

The classes th at can be derived from th e class families am ong t he a bove.



26/229


Object manipulation

An object is accessed wit h a reference. Once accessible in t his fash ion a nobject can be man ipula ted in s everal wa ys. An object is owned by an agentor place. An object can be man ipulat ed in some ways only by its owner.

Object references

This section intr oduces th e concept of a reference and describes how areference can let an object be exam ined, examined a nd m odified, or n either .

The reference concept

A referenceis wha t pr ovides access to an object, its referent. There is at leastone r eferen ce to every object, but th ere ma y be any num ber of th em.

Notes.

The predefined new operation ret urn s a reference to a new object . Many

other pr edefined operat ions r etur n r eferences to new or exist ing objects.

The predefined isSame operation discloses whether two references provide

access to the sa me object , th at is, ha ve the sam e referent .

Acquiring a protected reference

A reference is either protected or u npr otected. A protected referencelets itsreferent be examined. An unprotected referencelets its r eferent be examinedan d modified. To examinean object is to obta in a r eferen ce to an object in itsclosu re. To modifyan object is t o modify or r epla ce such a n object. An objectsclosureis th e object, t he objects pr opert ies, and th eir pr opert ies, recursively.

An opera tion whose responder is accessed by a pr otected r eferen ce is limitedas follows. If the operat ion would examine t he r esponder, th e engine replaces

with a protected referen ce th e reference otherwise obta ined. This preventsth e opera tions request er from modifying the r esponder lat er. If the operat ionwould modify the responder, t he engine t hr ows Reference Protected.

Notes.

The predefined new operat ion re tur ns a n u nprotected reference to a new

object unless the object is a member of the predefined Protected class.

The predefined isProtected at tr ibut e discloses wheth er a r eference is

protected. The pr edefined protect operation exchanges an unprotectedreferen ce for a pr otected one. (Of course, t he r everse exchan ge is impossible.)

Modifications ma de to an object (by mean s of an un protected r eference) ar e

visible by mean s of al l references t o tha t object , pr otected or unpr otected.

In normal situations, objects ultimately modify themselves. In specialsi tua tions, an object is modified by anoth er object or by th e engine i ts elf.Isolat ion, locking, freezing, and t hawing a re a mong these special si tu at ions.

Acquiring a voided reference

A voided referenceno longer provides access to its referent. A reference isvoided in circumst an ces pr escribed by the predefined classes, some of whichmake t he voiding appear spontan eous t o the object t hat holds th e reference.



27/229

Language Concepts

A referen ce is voided, among other rea sons, if it would spa n t oo great adistance in the place hierarchy established by the predefined classes. Anoperat ions requ ester an d responder can be owned by one agent or place, bytwo occupa nt s of one place, or by a pla ce an d an occupant . In a ny othersituation, the engine voids the reference used to designate the responder.

Whether th e reference to an operat ions r esponder is voided before the

operat ion is r equested, when the operation is requested, or during t heperform an ce of th e request ed operation, th e engine th rows Reference Void.However, the predefined discard operat ion d oesnt t hr ow this exception.

Protecting objects

A protected object, a member of th e predefined Pr otected class, cannot bemodified becau se allreferences t o it ar e protected references.

A protected object is un locked while it performs t he const ru ctor (seePerforming the constructor). This lets the object initialize itself. The objectis locked (see Locking a n object) when th e new opera tion succeeds.

Notes.

The predefined isSame operation considers two protected objects to be t hesa me object if theyre copy-equa l. Ther efore t he t wo objects arethe same.

While a protected object can t be modified in norm al sit ua tions, it can be

modified as a consequen ce of isolat ion, freezing, or th awing.

Locking a protected object doesnt modify it because its locked already.

The protected objects include (but are not limited to) members of the

predefined Package, Class, and P rimitive classes.

Object manipulation

This s ection defines ba sic forms of object ma nipu lat ion.

Note. The most basic forms of object man ipulat ion a re examin at ion a ndmodificat ion which a re discussed elsewhere (see Object references).

Copying an object

To copyan object is to create another with certain similarities to the original.Two objects ar e copy-equal if one could ha ve been creat ed by copying t heother. In ter face member s of the pr edefined Un copied class cannot be copied.

A copy is created from the original as follows. The objects in the closures ofth e origina l and t he copy can be pa ired so tha t one object in ea ch pair is acopy of th e other . Let Obe an y object in t he closur e of th e origina l, and let Obe the object in t he closur e of the copy tha t is pa ired with O. Let Rbe thereference that links to Oany of its properties, and let Rbe the reference that

links t o Oth e corresponding propert y. The copy is crea ted so tha t Rand Raccess pa ired objects. I f th ese objects ar e pr otected or un copied objects, Risun protected if and only ifRis un protected. Other wise Ris unprotected.

For pur poses of copying and th us det ermin ing copy-equa lity, th e att ribut estha t t he predefined classes define ar e implement ed as inst ance propertiesexcept a s noted in s pecializat ions of the pr edefined copy operation.



28/229


Notes.

The predefined copy operation copies its responder. The predefined isEqual

operat ion discloses whether i ts responder an d i ts argumen t ar e either t hesame object or copy-equal (without distinguishing between the two cases).

The original a nd t he copy are inst ances of the same class.

Agents and places are uncopied objects.

Destroying an object

To destroyan object is t o void all r eferences to it; discard th e objectsreferences to its pr operties; and, if the object is a n a gent or a place, dest roythe other objects it owns. An objects size, which can vary from one engine toanother, is t he appr oximate a mount of stora ge in octets ther eby released.

An object is not dest royed upon request . The engine destr oys an y object t ha twould be excluded from its owner s closu re if th e owner wer e isolated . Forpur poses of this r ule, an objects p ropert ies include t he following:

While perform ing an opera tion, an object in cludes a mong its pr operties

any argument of that operation th at was passed byOwner.

While designat ed th e current owner, an agent or place includes among its

properties an y object th at is creat ed, by constr uction or by copying, orthat is passed byOwner as th e result of an operation oth er tha n a getter.

While performing a sponsored opera tion at t he engines request , an agent

or place includes among its properties the responder, stack, and localvariables for each method enta iled by its a ctivation for tha t pu rpose.

Notes.

In t he simplest case, the en gine destroys an object t o which a ll references

ha ve been either volun ta rily discarded or forcibly voided.

The curren t object can d estr oy an y object i t can pu t in t he requir ed posit ion.For example, if the reference th at makes an object a property of the curr entobject is th e only reference th at includes t he pr opert y in i ts owners closur e,repla cing the propert y (for exam ple, with nil) provokes its dest ru ction.

Object ownership

This section int roduces th e concept of object owners hip a nd list s a n a gentsor places pr ivileges while the cur ren t owner (see The own statement).

The ownership concept

Ever y object is ownedby an a gent or pla ce. An a gent or pla ce owns it self. Anyother object is owned by th e agent or place th at is designat ed the cur rent

owner when th e object is created, wh ether by const ru ction or by copying.

An agent or place can isolat e, lock, freeze, and t ha w objects it owns. Thecur rent object can exercise these ownership privileges of the curr ent owner.

Notes.

Th e owner global variable pr ovides an unpr otected r eference to the a gent or

place designat ed the curr ent owner. The predefined isOwned a t t r i bu tediscloses wheth er i ts r esponder is owned by the curr ent owner. Thepredefined owner at tr ibut e, which is private, discloses t o an object i t s owner.



29/229

Language Concepts

The predefined Pa ckage class gran ts t he curren t object the a ddit ional

privilege of constru cting new packages au thorized by the curr ent owner.

Ownership isn t t o be confused with aut hority.

Isolating an object

The curr ent object can isolate objects t ha t t he curr ent owner owns. To isolatean object, O, is first to reduce th e closure ofOby voiding any references theclosure includes t o objects t ha t t he owner ofOdoesnt own, wh ich leaves Oun iformly owned, and th en to void all references outside t he r esulting closur etha t access objectsoth er t han Oitselfinside th e closure. An object isuniformly ownedif all objects in its closur e ha ve the sa me owner.

Notes.

The predefined isolate operat ion isolates i ts responder.

An agent or a place, like an y other object , can be isolat ed. The pr edefined

partAll operation, among other thin gs, isolat es an a gent.

Locking an object

The curr ent object can lock objects t ha t t he curr ent owner owns. To lockanobject is first t o isolate it a nd t hen t o mak e it subsequent ly treatunpr otected r eferences to itself as th ough they were pr otected references.

Notes.

The predefined lock operat ion locks its r esponder . Alth ough a locked object

cant be unlocked, the predefined unlockedCopy opera tion creat es anun locked copy of its r esponder even if the res ponder is locked. Finally, thepredefined isLocked att r ibute discloses wheth er i ts responder is locked.

Locking a n object doesnt lock its propert ies.

Locking an object prevents its subsequent modification.

Freezing an objectThe curr ent object can freeze objects t ha t t he curr ent owner owns. To freezealocked object is to discard it s pr operties. This is done in t he pr esence of amember of the pr edefined Pa ckage class whose values include an adequat esubstit ut e for t he object. A class is a n a dequate s ubstit ut e for it self. Anadequat e substitu te for a ny other object is an unfrozen object t hat mat ches.

An object is dysfunctional while frozen. The engine throws Object Frozen ifth e object is as ked to perform an y but a h an dful of predefined operat ions. Ifth e object is a class, th e engine th rows th e sam e exception if th e opera tion isrequ ested of a member of the class. The operat ions t ha t a fr ozen object or amember of a frozen class canperform a re th e isolate a nd protectoperat ions a nd th e gett ers for t he isLocked, isOwned, isProtected, andisFrozen at tr ibutes (th e last of which reveals wheth er th e object is frozen).

Notes.

The predefined freeze operation freezes objects. The predefined isFrozen

att r ibute discloses wheth er i ts responder is frozen.

A frozen object is a placeholder for t he u nfrozen object, dra ma tically less

functional but often dram atically smaller in size in retur n. To reduce i ts sizein t ran sit , an agent can freeze some of the objects i t owns just before i tdepar ts on a t r ip and can tha w them just af ter i t a r r ives a t i t s dest inat ion .



30/229


Thawing an object

The current object can tha w objects tha t t he curren t owner owns. To thaw afrozen object is to inst at e as its propert ies th ose of another object. This isdone in th e presen ce of a mem ber of th e predefined Pa ckage class wh osevalues include an a dequate su bstitu te for t he object. A class is an adequa tesubstit ute for itself. An a dequate su bstitu te for a ny other object is a value

whose key and th e nam e of whose package are copy-equal to th e key and t henam e of the package of the value t hat proved suita ble at freezing.

Notes.

The predefined thaw operat ion t ha ws objects.

In pr actice, a t hawed object is copy-equal t o the object th at was frozen.

Transferring ownership

The curr ent object can a cquir e or r elinquish ownersh ip of an object a nd itsclosur e, on beh alf of the cur ren t owner , by passing t he object byOwner.

Passing byOwner an object, O, other t han an agent or place tran sfersowners hip of its closur e. IfOis an argument , ownership is tr ansferred fromth e curr ent owner (see Cur rent objects) to th e responder s owner. IfOis theresult of an operat ion other t han a getter, ownership is tra nsferred from theresponders owner t o the curr ent owner. H owever, in either case, if neither ofth e two un iformly owns O, the engine th rows Object Unowned. IfOis agetters resu lt, the engine behaves as th ough its pa ssage were byRef.



31/229

Language Concepts

Object aggregation

As a n economy, objects with t he sa me int erface an d implementat ion a redefined an d implemented together as a class. As a furth er economy, classeswhose members ha ve different but systemat ically similar interfaces a nd

implementat ions a re defined an d implemented together as a class family.

Class definitions

This section int roduces th e concepts of a class an d a class fam ily, describeshow a classs int erface an d implement at ion ar e defined, and int roducesman y ancillar y concepts, most of which have t o do with inher itan ce.

The class concept

A classdeterm ines a set of objects, it s instances, and specifies th e inter facean d imp lement at ion of each of them . An objects interfaceor implementationconsist s of the int erfaces or implement at ions of its feat ur es. An objects

featuresare th e operations it performs and t he att ributes it gets and sets.

A class , an object it self, specifies its own int erface and im plement at ion a swell as th ose of its ins ta nces. Thu s a class specifies class a nd in sta ncefeatu res, class an d insta nce methods, and inst ance properties. (There ar e noclass propert ies becau se class es, once constr ucted, ar e immu ta ble.) A classfeatureis request ed of the class, an instance featureof an inst an ce thereof. Aclass methodis performed by the class, an instance methodby an inst anceth ereof. An instance propertyis maint ained by an inst ance of a class.

A class is either predefined or user -defined. A predefined classis a universallyavailable extension to the language. It represents a kind of object availableto every Telescript program mer. A user-defined classis defined by a particularTelescript program mer. It extends the language for a pa rticular pu rpose.

Note. Instan ce featur es or methods far outnumber class featur es or methods.

The class family concept

A class familyis a class-producing templat e or function. The function isdefined us ing one or m ore identifiers, t he formal parametersof th e classfamily. The function is applied with t he a id of as man y classes, th e actualparameters(or parameters) of the derived class. Both defined by lists, t heforma l and actua l para meters a gree in order as well as nu mber. To applythe function is to substitu te th e actual par ameter s for t he forma l ones.

Besides a s ource of class es, a class family is its elf a class, t he one der ivedusing defaul t actual parameters(or defaul t parameters). If th e class family ispredefined and a n actua l para meter is limited to a certa in class or interface

subclass t hereof, the default pa ra meter is tha t class. Otherwise its Object.

Specifying a classs interface

Each of th e two inter faces tha t a class specifiesis t he composite of one n at iveinter face and zero or m ore inherit ed inter faces. The class definesthe nativeinterfaceand inheritsthe inherited interfaceswhich other classes specify.

The following ter ms describe th e relat ionsh ips am ong classes . A class is a nimmediate interface subclassof th e classes t ha t sp ecify the int erfaces itinherits . The class is an interface subclassof the classes t hat define the



32/229


na tive inter faces of which th e inher ited int erfaces are composed. A class is animmediate interface superclassof its imm ediate int erface subclasses, aninterface superclassof its in ter face subclasses .

The following terms describe the relationships between classes and objects.An object is an interface memberof its class an d its interface superclasses, allof which a re interface member classesof the object.

Notes.

Object ha s no immediate int erface super classes .

An objects in ter face member classes collectively define a ll of it operat ions

and a ttr ibutes, both pr edefined and u ser-defined.

This section is the sa me as t he next except tha t interface appear s in one

an d implementa tion in the other .

Specifying a classs implementation

Each of th e two implementat ions t hat a class specifiesis the composite of onenat ive implementation an d zero or m ore inh erited implementations. Theclass definesthe nati ve implementationand inheritsthe inherited

implementationswhich other classes specify.

The following ter ms describe th e relat ionsh ips am ong classes . A class is a nimmediate implementation subclassof th e classes t ha t specify theimplementat ions it inh erits. The class is an implementation subclassof th eclasses th at define th e nat ive implementations of which t he inher itedimplementat ions ar e composed. A class is an immediate implementationsuperclassof its immediat e implementat ion su bclasses, an implementationsuperclassof its implement at ion su bclasses.

The following terms describe the relationships between classes and objects.An object is an implementati on memberof its class an d its implement at ionsuper class es, all of which ar e implementation member classesof the object.

Notes.

Object has no immediate implement ation superclasses.

An objects implementation member classes collectively define all of it

methods a nd properties, both predefined and user-defined.

This section is t he sa me as the pr evious except th at interface appear s in

one and implement at ion in th e oth er .

Elaborating upon inheritance

A class can be a mix-inrather than a flavor. A mix-in cann ot h ave inst an ces.Every imm ediat e subclass of a m ix-in is a s ubclass of a class t he mix-indesignates as it s anchor. The an chor or it s an chor, r ecur sively, is a flavor.

A class or feat ur e can be sealed. A sealed class cann ot ha ve user-definedimmediate su bclasses. A sealed featu re cannot be implement ed by user-defined subclasses of the class t ha t defines it . A class is sealed by itself. Afeat ure is sealed by a class t hat defines or inh erits a n implementa tion of it.

A class or feat ur e can be abstract rather than concrete. An abst ra ct classcann ot h ave instan ces. Hence the class an d its implementa tion superclassesneed not collectively implement all featu res t ha t t he class defines or inh erits .An abst ra ct featur e cann ot be implemented by the class th at defines it.



33/229

Language Concepts

Notes.

Flavors pr ovide single inherit an ce, mix-ins a limited form of mult iple

inher ita nce. Informally, flavors act as n ouns, mix-ins as adjectives.

A flavor is either abst ra ct or concret e. A mix-in is effectively abst ra ct.

Class relationships

This section describes how classes are related to one another. It introducesth e concepts of the class grap h, canonical order, an d escalation.

Relating one flavor to another

A tree, illustrated, defines the interface inheritance relationships amongflavors, a second tr ee the implementa tion inheritan ce relat ionships.

Eith er tr ee is inter pret ed as follows. The trees nodes represen t flavors, th ear c between two nodes the (int erface or implemen ta tion) inh erita ncerelat ionsh ip between th ose two flavors. The tr ees root r epresen ts Object.

Each destina tion node reached byan ar c that emanates from anysource node represents animmediate subclass of the flavor thesource node represents. Thus t hesource node represents animmediat e super class of the flavorthe destinat ion node represent s.

Object

Place

Home Shop

CreditCard

Process

Agent

Buyer Seller

BusinessCard

Each destina tion node reached byone or more arcs in successionrepresents a subclass of the flavorthe source node represents . Thusthe s ource node represents a

superclass of the flavor the destinat ion n ode represent s.

Note. This version of th e compiler an d th is version of th e engine require t hat th ein ter face t ree and th e implementat ion t ree be one an d the sa me.

Relating one mix-in to another

A tree, illustrated, defines the interface inheritancerelat ionsh ips among a mix-in and its zero or moreinterface superclasses, a s econd tr ee the implementa tioninheritance relationships.

QualifiedBuyer

BusinessCarded

CreditCarded

Eit her t ree is inter pret ed as follows. The tr ees nodesrepresent mix-ins, the a rc between t wo nodes th e inverse(int erface or implement at ion) inherit ance relationship

between th ose two mix-ins. The tr ees root r epresen ts t hemix-in.


Relating one class to another

A directed graph, illustrated, defines the interface inheritance relationshipsam ong classespredefined an d user -defined class es, flavors a nd m ix-ins. Asecond graph defines th e implementation inher itance relationships.



34/229


Object

Place

Home Shop

CreditCard

Process

Agent

Buyer Seller

BusinessCard

BusinessCarded

CreditCarded

QualifiedBuyer

This class graphis constr ucted in two steps. Fir st, each ar c in each mix-intree is reoriented to represent the inherita nce relationship, rath er tha n itsinverse. Second, the alter ed mix-in tr ees are gra fted ont o th e flavor t ree.

Notes.

This version of the compiler an d th is version of th e engine require th at th e

interface graph a nd th e implementa tion graph be one and t he same.

The langua ge provides the ba sis for one un iversal class gra ph. However, the

graph chan ges over t ime and is known only in part at a ny part icular place.

Ordering a class and its superclasses

A tree, illustr at ed, defines t he canonicalorderof a class a nd its interfacesuperclasses, a second t ree th at of aclass an d its implementat ionsuperclasses.

Object

BusinessCarded

CreditCarded

`

Process

Agent

Buyer

QualifiedBuyer

Either tr ee is interpret ed as follows. Theroot r epresents the class, its other n odes

th e (inter face or implement at ion)superclasses, and the ar c between twonodes t he inverse inherita ncerelationship between th e two classes.

The canonical order is a dept h-first walkof th e tr ee in which a classs immediat e super class es ar e visited in theircanonical order (see Definin g a clas ss im mediat e su perclasses ).


Searching a class and its superclasses

An objects class a nd it s implemen ta tion sup erclasses can define met hods for

an operat ion t hat th e object per forms . Thus several meth ods for t he sam eopera tion can (and often do) ar ise. The engine selects for an opera tion th efirst meth od it finds by sear ching t he following four locat ions in order:

1. If the responder is a class, its class methods.

2. If the responder is a class, the class methods of its implementat ionsuper class es, searched in canonical order.

3. The instan ce methods of the responders class.



35/229

Language Concepts

4. The instan ce methods of the implementation superclasses of theresponder s class, sear ched in can onical order.

A method for a n operation can request either tha t sa me operat ion again oran other opera tion of th e same object in a way th at const ra ins t he choice ofmeth ods. In eith er case, the operation is said t o be escalated. In th e formercase, the s earch for a m ethod begins immediately after th e curr ent class (see

Cur ren t objects). In t he lat ter case, the sea rch begins with a specified class,either th e curr ent class or a n immediate implementat ion su perclass.

The constructor

This section int roduces the concept of th e const ru ctor and describes how theconstru ctor differs from oth er opera tions.

The constructor concept

An object is constructedby asking its class, an instance of Class, to performthe predefined new opera tion. If all actua l argum ent s (if an y) ar e nil, th eobject is a basic instanceof its class.The class in tu rn asks th e object under

constru ction t o perform t he pr edefined initialize operation, often calledthe constructor, whose main p ur pose is to initialize th e objects pr operties.

Because of its special role in the construction of objects, the constructordiffers from other opera tions in severa l import an t r espects. These differenceshelp ensur e tha t object const ru ction is orderly and pr edicta ble.

Note. Not every object can be const ru cted using t he new operation. Some of theobjects t hat cannot be so constru cted are l i terals of the lan guage. Others a recreated by const ructing an d th en modifying other insta nces of their classes.

Deciding the constructors formal arguments

telescript language reference

Documents