Telescript (langage de programmation)

Telescript

Informations

Type	Langage de programmation orienté objet (en) Langage de programmation
Documentation	bitsavers.informatik.uni-stuttgart.de/pdf/generalMagic/Telescript_Language_Reference_Oct95.pdf

Telescript est un langage de programmation orienté agent écrit par General Magic dans le cadre du système global Magic Cap. Les programmes Telescript utilisaient une syntaxe de type C modifiée connue sous le nom de High Telescript et étaient compilés dans un langage basé sur une pile appelé Low Telescript pour l'exécution. Low Telescript s'exécutait dans des interpréteurs de machines virtuelles, ou «moteurs Telescript», sur des ordinateurs hôtes.

Le modèle de base de Telescript est similaire à Java et diffère principalement par l'endroit où les applications s'exécuteraient. Java a été modélisé pour permettre de télécharger des applications Java sur n'importe quelle plate-forme et de les exécuter localement. Telescript a essentiellement inversé cela, permettant à l'équipement de l'utilisateur final avec des capacités limitées de télécharger des programmes Telescript sur des serveurs pour leur permettre de tirer parti des capacités du serveur. Telescript pourrait même migrer un programme en cours d'exécution ; le langage comprenait des fonctionnalités pour rassembler le code et l'état sérialisé d'un programme, le transférer vers un autre moteur Telescript (sur un appareil ou un serveur) pour continuer l'exécution, et enfin revenir au client ou au serveur d'origine pour fournir sa sortie.

General Magic s'était à l'origine développé en tant qu'équipe au sein d'Apple Inc. et a été essaimé en 1990. Lorsqu'ils ont commencé à générer un certain buzz dans la presse en 1992, Apple a décidé d'entrer sur le même marché avec leur tablette tactile Newton. General Magic n'a pas été en mesure de trouver une niche sur le marché et les services Telescript ont rapidement été abandonnés au profit de nouveaux produits sans rapport avec l'informatique mobile.

Histoire

En 1990, Marc Porat a convaincu John Sculley, alors PDG d'Apple, que l'avenir de l'informatique ne résidait pas dans les ordinateurs personnels de bureau, mais dans des appareils portables beaucoup plus petits combinant puissance de calcul, systèmes de communication et données situées sur des serveurs accessibles par le réseau. Il a noté que les ordinateurs portables auraient toujours moins de puissance que les machines auxquelles ils se connecteraient, et a suggéré que cela fasse partie de la conception - au lieu d'essayer de construire un ordinateur portable qui pourrait effectuer les tâches d'un système de bureau, l'appareil portable doit utiliser de manière invisible la puissance de calcul des serveurs pour produire un résultat similaire.

Sculley a accepté de permettre à Porat de commencer à rechercher les concepts sous le nom de code "Pocket Crystal". Les membres clés de la première équipe étaient Porat et les célèbres développeurs Macintosh Bill Atkinson et Andy Hertzfeld. L'équipe s'est rapidement retrouvée ignorée par la haute direction et est partie sans cesse à la recherche de ressources. Ils ont de nouveau approché Sculley avec l'idée de transformer Pocket Crystal en une société distincte. Sculley a accepté cela, ainsi que l'idée d'inviter de nouveaux partenaires du côté du matériel. La nouvelle société, General Magic (GM), a été créée en mai 1990 avec Apple, Sony et Motorola détenant chacun une participation de 10 %. La société se classe rapidement avec d'autres anciens élèves de Macintosh, dont Joanna Hoffman, Susan Kare, Dan Winkler, Bruce Leak et Phil Goldman.

En 1992, GM avait signé des accords de développement avec un certain nombre de sociétés pour travailler avec l'environnement Magic Cap, notamment Sony, Motorola, Matsushita, Philips, British Telecom et AT&T Corporation. Cela a généré un "buzz" considérable dans la presse. Apple avait à cette époque lancé le projet Newton, une conception d'un ordinateur portable plus grand, semblable à une tablette, plus similaire à l'iPad pleine grandeur. Avec le succès de General Magic dans la presse, ils ont carrément repositionné le Newton sur le même marché et se sont précipités pour le sortir en 1993. Ils ont également vendu leur participation dans General Magic et les ont poursuivis en justice. Les partenaires de General Magic n'ont sorti de matériel qu'en 1994, date à laquelle le Newton avait essentiellement défini ce que devrait être un assistant numérique personnel (PDA), et les systèmes PDA étaient jugés sur leurs capacités de reconnaissance de l'écriture manuscrite. Magic Cap était une interface pointer-cliquer (similaire à HyperCard ou à l'iOS moderne).

En 1995, la société n'était plus qu'une coquille d'elle-même et la plupart des développeurs d'origine étaient partis. En 1996, Steve Markman a été embauché pour prendre la relève, et il a embauché Kevin Surace pour orienter l'entreprise dans une nouvelle direction. Une nouvelle équipe a développé le système d'assistant personnel par téléphone Portico, qui est aujourd'hui la base d'OnStar. Le groupe portable d'origine a été créé en 1998 sous le nom de DataRover Mobile Systems Incorporated, puis renommé Icras en 2000, desservant un certain nombre de marchés verticaux avant de fermer en 2001. Les restes de la société d'origine ont été liquidés en 2004.

La description

Concepts sous-jacents

Telescript a été calqué sur le concept de petits programmes connus sous le nom d' agents qui interagiraient avec des services informatiques connus sous le nom de lieux qui fonctionneraient tous sur un cluster d'un ou plusieurs serveurs hébergeant ce qu'on appelait un nuage Telescript. L'appareil portable de l'utilisateur était l'un de ces endroits, bien qu'il ait des capacités limitées. Le modèle supposait que la plupart des informations et des services seraient fournis par des emplacements fonctionnant sur des ordinateurs serveurs plus grands hébergés par des fournisseurs de communications comme AT&T. Même les premiers documents font référence à cela comme s'exécutant dans le cloud. Les programmes destinés aux utilisateurs seraient constitués d'un certain nombre d'agents de ce type, qui pourraient s'exécuter localement, sur les hôtes du fournisseur, ou même être transmis à des serveurs tiers. Pour coordonner les communications, Telescript a également inclus les concepts d'un télénom qui identifiait de manière unique les utilisateurs et des téléadresses qui identifiaient l'appareil même lorsqu'il se déplaçait entre les réseaux.

Par exemple, considérons une application de magasinage à laquelle l'utilisateur demande de trouver les prix d'un nouveau barbecue qu'il souhaite acheter. Dans un modèle client-serveur traditionnel, l'application formerait un certain nombre de requêtes, les enverrait à un certain nombre de services, puis collecterait les résultats et les afficherait. Dans le modèle Telescript, l'application créerait à la place un nouvel agent rempli avec les données de la demande, l'estampillerait avec son nom et son adresse, puis l'enverrait à un emplacement de stockage sur un serveur pour traitement. Ce serveur pourrait alors traiter la demande directement ou transférer l'agent à d'autres endroits, comme les endroits des vendeurs réels, pour un traitement ultérieur. Les résultats pourraient être placés dans les champs de données internes de l'agent et renvoyés via le réseau à l'appareil de l'utilisateur, ou un nouvel agent « messager » pourrait être généré pour transporter uniquement les données de résultat et renvoyé pour minimiser le transfert de données réseau.

Le modèle se distingue également des solutions traditionnelles par la manière dont l'échange de données s'effectue dans le cas de programmes interactifs. Par exemple, si l'utilisateur choisit d'acheter l'un des barbecues qu'il a trouvés dans sa recherche précédente, dans un système conventionnel, la tâche consistant à remplir les formulaires de commande et à confirmer le paiement serait accomplie par des communications directes entre l'appareil de l'utilisateur et le serveur distant, ce qui nécessiterait un canal de communication "en direct" tout au long du processus. Dans le modèle Telescript, un nouvel agent contenant les informations nécessaires pour effectuer l'achat est envoyé au magasin du vendeur, interagit avec le magasin ou les agents du vendeur, puis revient avec le succès ou l'échec. Les principales communications ont lieu entre les agents et les sites sur le serveur distant, de sorte que les communications sur le réseau ne sont nécessaires qu'au début et à la fin du processus.

Telescript était orienté objet (OO) et utilisait un certain nombre de termes peu courants pour décrire l'état de l'objet et les communications. Les attributs correspondent à ce que d'autres langages appellent des variables d'instance ou des champs. Les appels de méthode étaient connus sous le nom de demandes et l'action d'exécuter l'implémentation d'une méthode était connue sous le nom de l' exécuter. Tous ces appels répondaient toujours par un message indiquant le succès ou l'échec, il appartenait à l'objet demandeur de les piéger éventuellement et d'y répondre. Les conseils sur la façon de transmettre les données dans et hors des appels de méthode étaient connus sous le nom de contraintes, et couvraient le commun " by ref " et " by value ", entre autres.

Telescript était généralement sans état en termes de durée de vie des données. Toutes les données du programme, à la fois l'instance et les variables locales, étaient toujours sérialisées. Les agents pourraient être invoqués ou suspendus à tout instant et ne perdraient pas leur statut. Ce même mécanisme a également permis aux agents d'être facilement communiqués entre les hôtes.

Syntaxe et mise en page

Bien que le contrôle et la mise en page de Telescript aient été inspirés par C, sa syntaxe précise était considérablement différente. Une différence évidente était le remplacement des accolades de style C par des parenthèses au niveau de la définition, la conservation des accolades pour regrouper les instructions dans la logique et les instructions de contrôle de flux, et l'utilisation des deux-points pour séparer un nom de sa définition. Le code suivant définit l'interface pour les objets de type Pie :

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

Notez l'utilisation du mot-clé op, qui correspond à la function ou sub trouvée dans d'autres langues. L'implémentation de Pie peut être utilisée dans un ou plusieurs objets class, qui peuvent être organisés en modules s d'une manière similaire à Visual Basic . Construction d'espace de namespace de NET. #include est utilisé pour importer des fichiers d'en-tête, mais l'importation est locale aux modules, pas au fichier dans son ensemble.

Les concepts d'agent et de lieux de Telescript ont été invoqués simplement en sous-classant ces deux classes, Agent et Place, qui étaient toutes deux des sous-classes de Process. Pour la clarté du code, on pourrait placer les deux dans un seul fichier, et même les rassembler dans un seul module. Le code suivant définit les agents nécessaires pour implémenter un magasin qui vend des tartes :

   PieStoreModule: module = (
   	#include "pie.i"
       
   	PieBuyer: class(Agent) = (
   		public
   			live: sponsored op() = {
   					*.go(*.destination);
   					myPie = place@PieSeller.sellPie();
   					*.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;
   				};
   			};
   		);
   );

L'objet PieBuyer, un Agent, contient une seule méthode, live, la méthode de démarrage standard utilisée par tous les Agents. Le simple fait de créer un PieBuyer et de l'invoquer entraînera l'appel de la méthode live, d'une manière similaire à la new opération trouvée dans la plupart des langages OO, bien que cette méthode soit appelée après la configuration. Le * remplace ce qui est plus communément implémenté comme self ou Me, se référant à l'objet lui-même, dans ce cas l'agent PieBuyer. Le code dit essentiellement que lorsqu'il est créé, l'objet doit s'envoyer (*.go) à l'emplacement qui lui a été envoyé lors de la création (*.destination). Une fois là, il devrait indiquer à l'objet de lieu correspondant, dans ce cas un PieSeller, de vendrePie. Lorsque cette commande est terminée, l'agent retournera à son lieu d'origine. L'application appelante peut ensuite examiner les résultats en inspectant la variable myPie.

L'objet PieSeller, un Place, contient également une seule méthode, sellPie. Il définit une variable locale appelée aPie, la définissant comme un objet Pie, ou "rien", qui est utilisé dans le cas où il n'y a pas de tartes. Il tente ensuite de définir aPie sur une valeur en appelant sa propre méthode getPieFromStock (non illustrée ici), puis vérifie si cela a renvoyé une valeur. S'il n'a pas réussi, par exemple, si le stock était vide, il construit alors son propre objet PieBuyer, envoie cette demande à un autre magasin, puis attend une réponse. Ce magasin peut transmettre la demande à un autre, et ainsi de suite. Lorsque cette chaîne d'événements se termine, soit avec une tarte, soit sans succès, la place PieSeller la renvoie finalement à l'appelant PieBuyer.

Les objets sont normalement "possédés" par le lieu qui les a créés. La propriété confère également des capacités et des paramètres de sécurité. Le langage peut s'approprier un objet via sa own {} ou, dans ce cas, utiliser le mot-clé sponsored pour indiquer qu'il doit s'exécuter dans la propriété de l'endroit où il s'exécute. Cela peut être utilisé, par exemple, pour accorder à l'agent la possibilité de voir le stock dans l'inventaire, des valeurs qui seraient autrement privées. L'utilisation de sponsored est exactement le même résultat que de placer le code dans un own {}, mais permet que cela se produise dans l'appelant.

Telescript comprend plusieurs types de collection intégrés, Set, List, Dictionary et Collection, dont le dernier est essentiellement une liste avec des index de texte (la moitié d'un dictionnaire). Une source courante d'erreurs dans Telescript était que si une collection dans son ensemble pouvait être renvoyée à un agent, les éléments individuels qu'elle contenait appartenaient à l'endroit. Ainsi si l'on utilisait return MyCollection[someIndex];, il reviendrait sur l'appareil de l'utilisateur en tant que null. La solution était une syntaxe supplémentaire, les DictOwned et ColOwned, qui provoquaient la modification de la propriété des valeurs renvoyées au retour, et donc leur sérialisation dans les résultats lors du retour à l'emplacement d'origine.

Les sous-classes étaient connues sous le nom de saveurs ; la classe PieBuyer décrite ci-dessus est une version d'Agent. Telescript a également inclus le concept de classes mixtes, qui offraient des fonctionnalités similaires à l'héritage multiple en permettant la création de classes contenant uniquement du code qui pourrait ensuite être inclus dans d'autres classes. Les mélanges n'étaient pas des saveurs.

Comme de nombreux langages OO modernes, Telescript a séparé l'interface et l'implémentation, en les plaçant dans des fichiers .i pour l'interface et des fichiers .t pour l'implémentation (t comme dans "t"elescript). De manière peu courante, le langage définissait également un troisième type de fichier, .d, qui combinait plusieurs fichiers .i ensemble. Le code compilé a été placé dans un fichier .s, qui était guidé par les instructions de l' éditeur de liens dans un fichier .l. Le cadre d'application externe permettait au code C++ d'être appelé par Telescript.

Notes et références

Références

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Telescript (programming language) » (voir la liste des auteurs).

Bibliographie

• (en) Steven Levy, « Bill and Andy's Excellent Adventure II », Wired,‎ avril 1994 (lire en ligne)
• (en) Richard Clark, Scott Knaster et al., « A developer's introduction to General Magic and Magic Cap », MacTech,‎ mai 1995 (lire en ligne)
• (en) Michael Kanellos, « General Magic: The Most Important Dead Company in Silicon Valley? », Forbes,‎ 18 septembre 2011 (lire en ligne)
• (en) Telescript Language Reference, General Magic, octobre 1995 (lire en ligne)
• (en) Telescript Programming Guide, General Magic, 1995 (lire en ligne)