Telescript (programovací jazyk) - Telescript (programming language)

Telescript je programovací jazyk zaměřený na agenty, který napsal General Magic jako součást celkového systému Magic Cap . Programy Telescript používaly upravenou syntaxi podobnou C známou jako High Telescript a byly pro provedení zkompilovány do jazyka založeného na zásobníku nazvaném Low Telescript. Program Low Telescript běžel v rámci tlumočníků virtuálních strojů nebo „motorů Telescript“ na hostitelských počítačích.

Základní model Telescript je podobný Javě a liší se především v tom, kde by aplikace běžely. Java byla modelována tak, aby umožňovala stahovat aplikace Java na libovolnou platformu a spouštět je lokálně. Telescript to v zásadě zvrátil a umožnil koncovým zařízením s omezenými schopnostmi nahrávat programy Telescript na servery, aby jim umožnil využívat výhod schopností serveru. Telescript mohl dokonce migrovat spuštěný program; jazykových zahrnuty funkce k zařazování ovládací kód programu a serializován stát, převést na jiný motor Telescript (na zařízení nebo serveru), pokračovat v realizaci, a nakonec se vrátit ke klientovi původu nebo serverové zařízení dodat jeho výstup.

Společnost General Magic se původně vyvinula jako tým v rámci společnosti Apple Inc. a byla vyčleněna v roce 1990. Když v roce 1992 začali generovat tiskové zprávy, společnost Apple se rozhodla vstoupit na stejný trh se svým tabletovým počítačem Newton . Společnost General Magic nebyla schopna najít mezeru na trhu a služby Telescript byly brzy zastaralé ve prospěch nových produktů nesouvisejících s mobilními počítači .

Dějiny

V roce 1990 Marc Porat přesvědčil tehdejšího generálního ředitele společnosti Apple Johna Sculleye , že budoucnost výpočetní techniky nespočívá v desktopových osobních počítačích , ale v mnohem menších přenosných zařízeních kombinujících výpočetní výkon, komunikační systémy a data umístěná na serverech přístupných v síti. Poznamenal, že přenosné počítače budou mít vždy méně energie než stroje, ke kterým by se připojovaly, a navrhl, aby to bylo součástí designu - namísto pokusu o vytvoření přenosného počítače, který by mohl plnit úkoly stolního systému, mělo by přenosné zařízení neviditelně použít výpočetní výkon serverů k dosažení podobného výsledku.

Sculley souhlasil, že umožní Poratovi začít zkoumat koncepty pod krycím názvem „Pocket Crystal“. Klíčovými členy raného týmu byli Porat a slavní vývojáři Macintosh Bill Atkinson a Andy Hertzfeld . Tým rychle zjistil, že je vrchním vedením ignorován, a neustále bojovali o zdroje. Znovu se obrátili na Sculleyovou s myšlenkou vyčlenit Pocket Crystal jako samostatnou společnost. Sculley s tím souhlasil, stejně jako myšlenka pozvat nové partnery po hardwarové stránce. Nová společnost, General Magic (GM), byla vytvořena v květnu 1990 s 10% podílem na společnostech Apple, Sony a Motorola . Řady společnosti se brzy zaplnily dalšími absolventy Macintosh, včetně Joanna Hoffman , Susan Kare , Dan Winkler, Bruce Leak a Phil Goldman .

Do roku 1992 GM podepsala dohody o vývoji s řadou společností pro práci s prostředím Magic Cap, včetně společností Sony, Motorola, Matsushita , Philips , British Telecom a AT&T Corporation . To vygenerovalo značný „buzz“ tisku. Apple do této doby zahájil projekt Newton , design pro větší ruční tabletový počítač, který se více podobá iPadu v plné velikosti . Díky úspěchu společnosti General Magic v tisku znovu umístili Newtona přímo na stejný trh a v roce 1993 jej spěchali k vydání. Rovněž prodali svůj podíl ve společnosti General Magic a žalovali je. Partneři společnosti General Magic vydali hardware až v roce 1994, kdy Newton v podstatě definoval, co by měl být osobní digitální asistent (PDA), a systémy PDA byly posuzovány podle jejich schopností rozpoznávání rukopisu . Magic Cap bylo rozhraní typu point and click (podobné jako HyperCard nebo moderní iOS ).

V roce 1995 byla společnost skořápkou svého bývalého já a většina původních vývojářů odešla. V roce 1996 byl převzat Steve Markman, který převzal společnost, a on najal Kevina Surace, aby převzal společnost novým směrem. Nový tým vyvinul telefonický systém osobních asistentů Portico, který dnes žije jako základ systému OnStar . Původní kapesní skupina byla vyčleněna v roce 1998 pod názvem DataRover Mobile Systems Incorporated a později přejmenována na Icras v roce 2000. Před uzavřením v roce 2001 sloužila řadě vertikálních trhů . Zbytky původní společnosti byly zlikvidovány v roce 2004.

Popis

Základní koncepty

Telescript byl modelován na konceptu malých programů známých jako agenti, kteří by interagovali s výpočetními službami známými jako místa, která by fungovala na klastru jednoho nebo více serverů, které hostovaly takzvaný cloud Telescript. Ruční zařízení uživatele bylo jedním z takových míst, i když s omezenými schopnostmi. Model předpokládal, že většinu informací a služeb budou poskytovat místa běžící na větších počítačích serveru hostovaných poskytovateli komunikace, jako je AT&T. Dokonce i rané dokumenty to označují jako běh v cloudu . Programy zaměřené na uživatele by sestávaly z řady takových agentů, kteří by mohli běžet lokálně, na hostitelích poskytovatele nebo dokonce být předávány na servery třetích stran. Pro koordinaci komunikace zahrnoval Telescript také koncepty telename, které jednoznačně identifikovaly uživatele, a teleaddresses, které identifikovaly zařízení, i když se pohybovalo mezi sítěmi.

Zvažte například nákupní aplikaci, kterou uživatel požádá, aby zjistil ceny na novém grilovacím grilu, který si chce koupit. V tradičním modelu klient-server by aplikace vytvořila řadu dotazů, poslala je na řadu služeb a poté shromáždila výsledky a zobrazila je. V modelu Telescript by aplikace místo toho vytvořila nového agenta naplněného daty z požadavku, označila jej svým jménem a adresou a poté ji odeslala do úložiště na serveru ke zpracování. Tento server by pak mohl zpracovat požadavek přímo nebo předat agenta na další místa, jako jsou místa skutečných prodejců, k dalšímu zpracování. Výsledky by mohly být umístěny do interních datových polí agenta a odeslány zpět přes síť do zařízení uživatele, nebo by mohl být vytvořen nový agent „messenger“, který by nesl pouze výsledná data, a odeslán zpět, aby se minimalizoval přenos síťových dat.

Model se také liší od tradičních řešení způsobem, jakým dochází k výměně dat v případě interagujících programů. Například pokud se uživatel rozhodne koupit si jednu z grilovaček, které našel při předchozím hledání, v běžném systému bude úkol vyplnění objednávkových formulářů a potvrzení platby splněn prostřednictvím přímé komunikace mezi zařízením uživatele a vzdáleným serverem, vyžadující „živý“ komunikační kanál v průběhu celého procesu. V modelu Telescript je nový agent s informacemi potřebnými k dokončení nákupu odeslán do prodejny tohoto dodavatele, interaguje s obchodem nebo agenty od dodavatele a poté se vrátí s úspěchem nebo neúspěchem. Hlavní komunikace probíhá mezi agenty a místy na vzdáleném serveru, takže komunikace přes síť je vyžadována pouze na začátku a na konci procesu.

Telescript byl objektově orientovaný (OO) a k popisu stavu a komunikace objektu používal řadu neobvyklých výrazů. Atributy odpovídají tomu, co jiné jazyky označují jako proměnné instance nebo pole. Volání metody byly známé jako požadavky a proces spuštění implementace metody byl známý jako její provedení . Všechna taková volání vždy reagovala zprávou označující úspěch nebo neúspěch, bylo na žádajícím objektu, aby je volitelně zachytil a odpověděl na ně . Rady, jak předávat data do a z volání metod, byly známé jako omezení a mimo jiné zahrnovaly běžné „ podle odkazu “ a „ podle hodnoty “.

Telescript byl z hlediska životnosti dat obecně bez státní příslušnosti . Všechna data v programu, instance i lokální proměnné, byla vždy serializována. Agenty bylo možné vyvolat nebo pozastavit kdykoli a neztratili by svůj stav. Stejný mechanismus také umožňoval snadnou komunikaci agentů mezi hostiteli.

Syntaxe a rozložení

Ačkoli ovládání a rozložení Telescript bylo inspirováno C, jeho přesná syntaxe byla značně odlišná. Jedním zjevným rozdílem bylo nahrazení složených závorek ve stylu C závorkami na úrovni definice, zachování složených závorek pro seskupování příkazů v rámci příkazů logiky a řízení toku a použití dvojtečky k oddělení názvu od jeho definice. Následující kód definuje rozhraní pro objekty typu Pie :

  Pie: interface(Object) = (
       public
           name: String;
           initialize: op(name: String);
  );

Všimněte si použití klíčového slova op , které odpovídá function nebo se sub nachází v jiných jazycích. Provádění Pie by mohly být použity v jednom nebo více class objektů, které mohou být organizovány do modules sekund v módě podobné Visual Basic .NET ‚s namespace konstruktem. #include se používá k importu hlavičkových souborů, ale import je lokální pro modules , nikoli pro soubor jako celek.

Koncepty agentů a míst Telescript byly vyvolány jednoduše podtřídou těchto dvou tříd, Agent a Place, které byly podtřídami Process. Kvůli jasnosti kódu je možné oba umístit do jednoho souboru a dokonce je shromáždit do jednoho modulu. Následující kód definuje agenty potřebné k implementaci obchodu, který prodává koláče:

   PieStoreModule: module = (
   	#include "pie.i"
       
   	PieBuyer: class(Agent) = (
   		public
   			live: sponsored op() = {
   					*.go(*.destination);
   					myPie = [email protected]();
   					*.go(*.originPlace);
   				};
   			);
   			
   	PieSeller: class(Place) = (
   		public
   			sellPie: op() Pie = {
   				aPie: Pie | Nil;
   				aPie = *.getPieFromStock;
   				if (aPie = nil) {
   					PieBuyer(*.distributorTicket, Permit(nil));
   					aPie = *.waitForPie();
   					return aPie;
   				};
   			};
   		);
   );

Objekt PieBuyer, agent, obsahuje jedinou metodu, live standardní metodu spouštění používanou všemi agenty. Pouhé vytvoření PieBuyer a jeho vyvolání způsobí, že se live metoda bude volat podobným způsobem jako new operace nalezená ve většině jazyků OO, i když se tato metoda volá po nastavení. * Nahrazuje to, co je běžněji implementováno jako self nebo Me , s odkazem na samotný objekt, v tomto případě agent PieBuyer. Kód v podstatě říká, že když je vytvořen, měl by se objekt odeslat sám (* .go) na místo, které mu bylo zasláno během vytváření (* .destination). Jakmile tam bude, měl by informovat objekt odpovídajícího místa, v tomto případě PieSeller, sellPie. Po dokončení tohoto příkazu se agent vrátí na místo původu. Vyvolávající aplikace pak může zkontrolovat výsledky kontrolou proměnné myPie.

Objekt PieSeller, místo, také obsahuje jednu metodu sellPie . Definuje místní proměnnou nazvanou aPie, která definuje objekt Pie nebo „nic“, což se používá v případě, že neexistují žádné koláče. Poté se pokusí nastavit aPie na hodnotu voláním vlastní metody getPieFromStock (není zde zobrazena) a poté zkontroluje, zda vrátila hodnotu. Pokud se to nepodařilo, například pokud byl sklad prázdný, vytvoří nový nový objekt PieBuyer, odešle tento požadavek do jiného obchodu a poté čeká na odpověď. Ten obchod by mohl přeposlat požadavek jinému atd. Když tento řetězec událostí skončí, buď s koláčem, nebo neúspěšně, místo PieSeller to nakonec vrátí volajícímu PieBuyer.

Objekty obvykle „vlastní“ místo, které je vytvořilo. Vlastnictví také uděluje možnosti a nastavení zabezpečení. Jazyk může převzít vlastnictví objektu prostřednictvím own {} konstrukce, nebo v tomto případě použít sponsored klíčové slovo k označení, že by se mělo spouštět ve vlastnictví místa, kde běží. To může být použito například k udělení schopnosti agentovi vidět zásoby v inventáři, hodnoty, které by jinak byly soukromé. Použití sponsored je přesně stejný výsledek jako umístění kódu do own {} bloku, ale umožňuje, aby k tomu došlo u volajícího.

Telescript obsahuje několik vestavěných typů na výběr Set , List , Dictionary a Collection , z nichž poslední je v podstatě seznam s textovými indexy (jedna polovina slovník). Jedním běžným zdrojem chyb v Telescript bylo, že zatímco kolekce jako celek mohla být předána zpět v agentovi, jednotlivé položky v ní byly vlastněny místem. Pokud by tedy někdo použil return MyCollection[someIndex]; , dorazil by zpět na zařízení uživatele jako null. Řešením byla další syntaxe, DictOwned a ColOwned hints, která způsobila, že vlastnictví vrácených hodnot bude při návratu změněno a bude tedy při návratu na původní místo serializováno do výsledků.

Podtřídy byly známé jako příchutě ; výše uvedená třída PieBuyer je příchutí Agenta. Telescript také zahrnoval koncept tříd mix-in, který nabízel funkce podobné vícenásobnému dědění tím, že umožňoval vytváření tříd obsahujících pouze kód, který by pak mohl být zahrnut do jiných tříd. Mix-iny nebyly příchutě.

Stejně jako mnoho moderních jazyků OO, rozhraní a implementace oddělené teleskopem, jejich umisťování do .i souborů pro rozhraní a .t souborů pro implementaci (t jako v „t“ elescript). Jazyk neobvykle definoval také třetí typ souboru .d , který kombinoval více .i souborů dohromady. Zkompilovaný kód byl umístěn do .s souboru, který byl veden pokyny linkeru v .l souboru. Rozhraní External Application Framework umožňovalo volání kódu C ++ pomocí Telescript.

Poznámky

Reference

Citace

Bibliografie