Dynamic typing and lazy evaluation as necessary ... - CiteSeerX

S.A.Cerri; Dynamic typing and lazy evaluation as necessary requirements for Web languages; European Lisp User Group Meeting; Amsterdam (NL), June 6-8 1999; p. 1 of 17

Dynamic typing and lazy evaluation as necessary requirements for Web languages Stefano A. CERRI Dipartimento di Scienze dell’Informazione Università di Milano Via Comelico 39, 20135 Milano, Italy1 Email: [email protected] Abstract. The availability of the WWW offers new opportunities that, in turn, generate needs, potential solutions and real applications. An example is offered by the rising interest in markup description languages - such as SGML and XML - and in the associated "processing languages" such as DSSSL and XSL. In another paper [1] we present a unified, simple view of the consequences of the extraordinary growth of these languages, in terms of a few fundamental notions that are associated with Scheme and have also been exploited in a model of agent-to-agent dialogues called STROBE [2, 3]. In this contribution we introduce two requirements for Web processing, i.e. weak (dynamic) typing and lazy evaluation. The case for these requirements seems to provide better evidence than other arguments that languages such as Scheme represent a clear opportunity for future Web applications.

Introduction The events around the WWW continue to wonder and challenge. On one side we notice a “babelic” growth of interest in different markup languages that emerge from the needs for interoperability and new applications, e.g. in Electronic Commerce (see, for instance, the appendix). On the other side there is a trend to consider Java as the candidate Web processing language, even if authors interested in the efficiency of solutions continue using C-based compilers. The functional approach to programming languages seems to be cultivated mainly within academic contexts: teaching Computing and prototyping new languages. Even though a few important Lisp-based , whether previously developed or currently under development, have shown the excellence of the choice, today the mainstream Webprocessing offer happens to be in Java. Usually, the attempt to convince people to use Lisp or Scheme in real applications ends up with the observation that, even if both are currently as efficient as C at run time, both are too “poor” (or non standard) concerning interfaces, networking, support for middle-ware etc. Lisp is often discarded as a development language also for the simple pragmatic reason that most educated programmers prefer a “state-oriented” underlying virtual machine (i.e. a procedural, assignment-centered view) rather that a functional (descriptive) view. Not only the pre-installed software but also the pre-installed competencies of available human resources delay innovation. This feedback, in turn, influences choices for Universities and Schools that privilege C, C++ and Java in the curricula so that future competencies again will privilege a procedural view which allows a reduced level of abstraction and flexibility. Finally: the traditional software engineering view of programming that favors strongly typed languages has the effect that even when functional languages are 1

On leave at Ecole Supérieure en Sciences Informatique, Université de Nice Sophia-Antipolis, France; [email protected]


naturally adequate – e.g. for parallel processing - the choice goes to one of the SML family [4]. This is a grounded decision in all the cases where the domain is closed and therefore well known at define time. On the contrary, as it is the case for Web applications, when the knowledge (information, data, etc.) of the domain is unknown at define time and the purpose of the system is to “discover” it on the Web, strong typing seems undesirable. Most Electronic Commerce applications (often associated with Agents, c.f. the March 1999 issue of the Communications of the ACM) have this property, therefore raising a challenge to reflect about the requirements of languages for generic Web applications. Recently, there has been a growing interest in Scheme or Lisp as a Web language, e.g. integrated with Java [5, 6] [7-9]. Yet, we did not find any convincing argument explicitly reported in the literature supporting the choice of Lisp or Scheme because some of their inherent linguistic features fit with available and future “documents” in the Web and with the need to have asynchronous, concurrent, distributed, mobile code developed for solving problems on the Web. The issue relates to several aspects of passive (data) and active (programs) code and the associated processes. Among the various characteristics entailed by the new scenario where “the computer is the Web”, we will concentrate here on two important properties that seem to be necessary conditions for languages able to realize future Web applications, i.e. dynamic typing and lazy evaluation. Both properties are well known to Scheme and Lisp programmers. Between the two, we privilege Scheme as the fit seems to us better, even though most of what will be said applies to Lisp as well. The third component we envision for Web processing, i.e. truly conversational behavior of active software components (such as that associated to Agents) will be not explored here, but simply assumed as an intuitively reasonable option. We conclude by showing that the three choices supported by our arguments concerning Web processing coincide fundamentally with what underlies our STReams OBjects Environments model [2,3] developed a few years ago starting from studies of the basic principles of dialogues among autonomous Agents.

Old and new arguments in favor of Scheme In a quite dated paper [10], Kurt Normark lists four important properties of Scheme: 1. Static binding of free names in procedures; 2. First Class procedures; 3. Uniform evaluation of all positions in a procedure call form; 4. Program is not data. From the first three of those, Normark shows that it is relatively simple to model Objects using only procedures. At the end, one is convinced that Scheme is a useful language for modeling the behavior of other languages. This is an important result, but not a surprise knowing that Scheme is related to lambda calculus and denotational semantics, as Queinnec showed in his excellent book [11]. More recent arguments supporting Scheme (see, e.g., in the appendix the corresponding section) adopt a similar approach. Scheme is nice for implementing languages, for transformational programming, for writing extensible programs, for incremental development, for learning Lisp, it may open your eyes, the focus has been on quality but: it does not have industrial usability! These arguments are exciting for a curious PhD student, but may result to be even counterproductive for influencing an industrial choice. Our arguments, instead, aim at a quite different goal. We wish to end up with a committed industrial support to functional languages, such as Scheme, based on understanding the impact of two of its most controversial linguistic features: dynamic typing and (potentially) lazy evaluation. The first is part of the standard, the second is


not officially part of the language, but one may accept that it can be easily introduced in applications. Both properties are necessary as we will see, in order to process Web documents.

Web documents; i.e. the memory content in the Web At the moment, most Web documents are HTML tagged, but there are significant industrial and academic efforts to enhance the semantic description of Web documents of the future by means of more powerful markup languages. In the appendix, a few excerpts of selected documentation to be found currently in the Web are presented. An observation that Scheme programmers make immediately is that SGML and XML marked-up documents look very similar to instances of complex Abstract Data Types with manifest type-names. In other words, Web documents marked up are trees (or groves: see the appendix) such that the nodes contain explicit type information and the leaves represent the data belonging to the primitive types of the language.

Dynamic (weak) versus strong typing; i.e. the Environment In dynamically typed languages, neither the name of a datum, nor the link namevalue contain type information concerning the datum. Scheme is such a language. Lisp adopts the same convention, but the different space attributed to procedures and data (defun and defvar) has the consequence that it cannot be really considered weakly typed, as we may check if a name concerns a procedural value without accessing the procedural value itself. This, in turn, is related with the fact that in Lisp the first element of a procedure application must be a procedural name, so that property 3 cited above from Normark is not valid for Lisp. Thus, we may say that Lisp is strongly typed with respect to procedures. As these may be located anywhere in the Web, this property may be a handicap. In Scheme, the Environment binds names with values. When values are primitive, they contain their type information; when they are complex, the ADT package (constructors, selectors, predicates and, possibly, constraints on well formedness) labels complex data with their explicit types and subtypes. The construction and the selection of tree-structured, explicitly typed complex data, is current practice in Scheme programming.

Generic functions; i.e. control at define time Among the most important reasons to introduce typing information, there is the need to construct generic functions (or procedures), i.e. to build complex software packages of increasing level of abstraction, so that programmers concentrate on the highest level and do not enter into implementation details at the levels underneath. Procedures are called generic when they may be applied to arguments of different possible types, unspecified at define time. At run time, the types of the actual arguments are evaluated and the system selects the specific function suitable for processing the data belonging to the actual types. This occurs by means of a selection statement that – in its essence – looks like: (if () 1 n1 ( … ) (…))


In order to select the specific function, we may use a. the traditional technique that dispatches on types in the calling generic function, or b. the technique of data directed programming, or finally c. object oriented programming. In all the cases we will have to express a condition, such as the simple “if” above, that allows us to test the type combination before selecting the correct function specific for the actual combination of types. Notice that the specific function may eventually not be available locally, so that the (exp1) of our “if” (corresponding to the “true” value of the test) may need to evaluate a search procedure for fetching the desired specific function: again an example of the need for the property 3 cited for Scheme by Normark (the first expression of a function application is evaluated as any other one and its result must be a procedural value). The arguments to the function do not need to be evaluated until one is sure that the specific function concerned exists and that it is available. The processes generated by generic functions may delay the evaluation of the parameters until the specific function corresponding to the parameter types has been found.

Eager and lazy evaluation; i.e. control at run time Scheme parameters in function applications (or procedure calls) are considered to be strict: they are evaluated before the procedure is applied (eager evaluation) because one assumes they will be needed in order the procedure application to be successful. The mechanism conforms to the call-by-value of many programming languages that is simply and efficiently implemented by stacks. However, in many cases (see, for instance Fournerie’s thesis [4] for a more profound discussion) some of these parameters may not be strict (i.e. the procedure will not need them). If one assumes that it is known which parameters will be strict and which not, at define time, then it is possible to design a compiler that is eager except where it is lazy for each parameter explicitly expressed as lazy. The resulting code will be optimized, for instance parallelizing all strict operations and delaying the other ones. In other cases, where information on strictness of parameters is not available at define time, lazy evaluation of all parameters may be preferred.

Scheme is not always eager; i.e. a mixed virtual machine model There are notable exceptions in Scheme to the rule of eager evaluation of parameters in function application. For instance define, let*, set! expressions, and the conditionals follow different rules of evaluation. Let us for the moment look last at the last class of special forms, e.g. if: (if ) means that exp1 will be evaluated only after ’s result value is true; else will be evaluated. The fundamental Scheme control primitive is … lazy! Similar considerations hold for let*: arguments are evaluated in turn; yielding a sort of control structure. We will not discuss here all exceptions to the call-by-value rule in Scheme, but simply recall that control and definition (or assignment) forms represent exceptions. Even when the call-by-value rule applies, it is simple (for the programmer) to impose lazy evaluation in Scheme. The implementation package for Streams is an example of lazyness and memoization (call by name and by need). In general,


Scheme expressions to be evaluated with a delay are “frozen” in a parameter-less procedure, which will be called when needed yielding the required (delayed) value.

Back to Web documents; i.e. steps towards a conversational view If Web documents contain the data we concern ourselves with for our Web processing, these are remotely located and accessed with a delay that may not be foreseen, due to the nature of the network. In particular, their types and subtypes cannot be anticipated. Web languages, therefore, cannot be founded on strong typing. Types have to be explicit, so that the procedures using these data may determine at run time the type information. However, this will only be possible if the association between type-names and type-specific procedures (constructors, selectors etc.) is known by the client process 2, e.g. by means of a common standard. In the case where this is not realistic, Web documents are expected to be able not only to communicate type names but also their own type-specific procedures; they are deemed to become objects responding to messages according to a standard interface. In mixed situations (partial knowledge of type-related procedures) the flow of information in the Web is expected to proceed conversationally: first the conversations will focus on setting up the linguistic conventions (the various ADTspecific procedures)3 and finally the real data (the leaves of the trees) are sent to the client. This occurs by means of delaying sub-computations in order to construct the correct, specific procedure call with the actual parameter values. At this point we have reached the second objective of the paper (to argue that laziness is required for Web languages). Therefore we leave the reader who is interested in knowing more about conversations among autonomous Agents with some concise information at the end of the appendix.

Conclusions The table shown hereafter represents our synthesis as emerged from the previous pages. The central column is in Italic as it was not a focus of this paper.

Concurrent, distributed, asynchronous Web processing

Dynamic scheduling Structured messages Agent’s State

PROCESSES Delayed evaluation STReams

PROGRAMS First class procedures OBjects

Markup as ADT Active documents Documents DATA Dynamic (weak) typing Environments

Our effort has tried to relate the essential properties of the Web with the requirements associated with computations in the Web and the fit with future Web languages. We have seen that some “traditional” principles (strong typing, eager evaluation) may not support the Web and its evolution as a computational resource. Then we have tried to identify other computational principles that seem to cover most 2 3

In a network-based view, access to memory becomes a client-server transaction. It is interesting to notice that conversations in humans occur exactly in the same way, as shown e.g. in [12].


computational phenomena in Web processing in a more realistic way, in particular dynamic typing and lazy evaluation. Both these properties are or may be adopted in Scheme programs, so that we hope to have offered stronger arguments for a wider diffusion of Scheme at least within the Communities interested in Web processing. The discussion concerning the third component of our model, i.e. Objects (Agents) and the associated conversational view of Web processing has not been elaborated, as it is work in progress. However, from the very brief hints, we hope to have stimulated useful reflections. Even if it is tempting to make a general synthesis, we are modest enough to admit the potential of several limitations in our view. The hope is that we may learn from the reactions to our efforts which ones can be removed and which ones cannot.

References [1] [2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11] [12]

S. A. Cerri and V. Loia, “A conversational, constructive view of Web Knowledge,” : In preparation., 1999. S. A. Cerri, “A simple language for generic dialogues: "Speech acts" for communication,” in Journées Francophones des Langages Applicatifs - JFLA97, M. Gengler and C. Queinnec, Eds. Dolomieu, Isère, France: INRIA, 1997, pp. 145-168. S. A. Cerri, “Shifting the focus from control to communication: the STReams OBjects Environments model of communicating agents,” in Collaboration between human and artificial societies, vol. 1624, Lecture Notes in Artificial Intelligence, J. Padget, Ed. Berlin Heidelberg New York: Springer-Verlag, 1999 (to appear). L. Fournerie, “Compilation et execution multiflot de programmes fonctionnels parallèles sur calculateurs à mémoires distribuées,” in Département Traitement de l'Information et Modélisation de l'ONERA-CERT. Toulouse: Ecole Nationale Supérieure de l'Aeronautique et de l'espace, 1999, PhD Thesis, pp. 207. K. Anderson, Hickey.T., and P. Norvig, “Lisp - a Language for Internet Scripting and Programming,” presented at Lisp User Group Meeting, 1998. http://www.franz.com/elugm99/conference/past.html N. Cramer, “Distributed-OMAR: Reconfiguring a Lisp System as a Hybrid Lisp/(Java) Component,” presented at Lisp User Group Meeting, 1998. http://www.franz.com/elugm99/conference/past.html S. A. Cerri and D. Maraschi, “Dialogues among Distributed Agents,” presented at Workshop on Advances in Languages for User Modeling, 6th Int. Conf. on User Modeling, Chia Laguna, Sardinia, 1997. http://zaphod.cs.uni-sb.de/~UM97//ws4.html S. Maffioletti, “Agenti Intelligenti: lo scheduler dei messaggi e le conversazioni,” Dipartimento di Scienze dell'Informazione, Università di Milano, Milano, Italy, Master thesis 1998. D. Maraschi, “Jaskemal: un linguaggio per agenti su Web,” Dipartimento di Scienze dell'Informazione, Università di Milano, Milano, Italy, Master thesis 1999 (to be defended) K. Normark, “Simulation of Object-Oriented Concepts and Mechanisms in Scheme,” Institute of Electronic Systems, Aalborg University, Aalborg, DK R 90 01, ISSN 0106-0791, 1990. http://www.cs.auc.dk/~normark/scheme.html C. Queinnec, Les langages LISP. Paris: InterEditions, 1994. S. C. Garrod and G. Doherty, “Conversation, co-ordination and convention: an empirical investigation of how groups establish linguistic conventions,” Cognition, vol. 53, pp. 181-215, 1994.


Acknowledgement The author is grateful to the ELUGM Conference Referee, Gail Anderson, for her patience and support that encouraged this effort during a period of heavy commitments.

Appendix We present here a collection of short, introductory and focused information excerpts available on the Web about document markup languages (SGML and XML), transformation languages (DSSSL, XSL), agent communication languages (KQML, AL, Jaskemal) and related issues. Concerning SGML, XML, DSSSL and XSL the available literature is simply overwhelming. The availability of documents of any kind from the Web may be appreciated by visiting Robin Cover's site at http://www.oasis-open.org/cover/sgmlxml.html. We will not review here any of the documents referenced, since we assume the interested reader to be aware of their essentials. Instead, we will provide for minimal information that allows us to provide a basis for our efforts to develop a synthesis between different aspects of Web processing, among which are emerging “standards” and recent research directions such as those associated to Agents. Document markup: SGML (from: ftp://ftp.ifi.uio.no/pub/SGML/FAQ/FAQ.0.0 ) What is SGML, briefly? SGML is an abbreviation for the "Standard Generalized Markup Language". SGML is defined in an International Standard published by the International Organization for Standardization (ISO), with reference number ISO 8879:1986, bearing the full name "Information processing -- Text and office systems -- Standard Generalized Markup Language (SGML)". To most people, _markup_ means an increase in the price of an article. Although we talk about increases in value, it's not the same thing. "Markup" is a term coming from the publishing and printing business, where it means the instructions for the typesetter that were written on a typescript or manuscript copy by an editor. Today, with your favorite editor, you can enter the markup yourself, or even have it entered for you, in terms of codes or other instructions for an electronic typesetting program, which in simple cases is also the editor. An example is troff's ".ce" for "center the following line". A _markup_language_ is a set of means (constructs) to express how text (i.e., that which is not markup) should be processed, or handled in other ways. Unlike most other artificial languages, markup languages have to deal with embedded data, and contain rules for what is markup and what is data. For instance, in TeX the backslash means that subsequent input is TeX instructions. Most markup languages offer additional, administrative, language constructs, with which to define other language constructs (such as macros).


_Generalized_markup_ is markup that has the curious property that it does _not_ specify how things should look. We still call it markup, though, because of the similarity with markup as described above. For instance, "" and "" are used in this FAQ to denote Question and Answer, respectively. This doesn't say anything about how questions should look in a typeset edition of this FAQ. You could have all the questions rendered in bold-face, for instance. With generalized markup, you tell the system _what_ you have, rather than how it should look, and you do so by putting a label (tag) around the text. There is a clear correlation between tags and what things look like. Tags are placed at the start and at the end of text of a certain kind, and these are precisely the places where typographic features are used, such as spacing, change of typeface, etc. An example is LaTeX, which, through macros, let you talk about itemized lists, instead of indents, item numbering, among other things. The _Standard_Generalized_Markup_Language_ started out as GML, the Generalized Markup Language, created by Charles Goldfarb, Edward Mosher and Raymond Lorie (G, M, and L, respectively) in 1969 at IBM. GML became the basis for the Standard through work in ANSI and with aid from a project predating GML, GenCode, which attempted to standardize names of commonly used elements. Rather than take this (impossible) approach, SGML is a language which makes it possible to roll your own generalized markup, but with a standard form and in standard ways. (Historic note: The origin of SGML was confused with that of GenCode in the 199112-15 edition of this FAQ.) In practice, you won't exactly roll your own, any more than you design LaTeX packages on your own. Although some people actually do that! Central to the design of SGML is the idea that a set of generic identifiers (the names of the tags), together with their interrelationships, form a type (or class) of documents, and that every document is an instance of a class, which means it can be validated with respect to this class. Document markup: XML (from: http://www.w3.org/TR/1998/REC-XML-19980210) The Extensible Markup Language is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received and processed on the Web in the way that it is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML. (from: http://www.w3.org/Talks/1998/1126-mjd-newmedia/all) XML: A Simple Example Acme Pharmaceuticals Co. 7301 Smokey Boulevard Smallville Indiana 94571


SGML Document Transformation: DSSSL (from: http://itrc.uwaterloo.ca/~papresco/dsssl/tutorial.html ) DSSSL is an international standard for associating processing with SGML documents. As you know, SGML itself is intended to allow the complete separation of the content of a document (text, structure, links), from the processing to be associated with it (usually formatting). So where a Word for Windows, Tex, or even LaTeX document would describe what a document looks like (in other words how a printer should "process" it), SGML documents would only describe the structure. Using DSSSL you can describe the processing of documents in a standard way. Since the two most common forms of document processing are formatting and transformation, DSSSL standardised these two processes first. Others may follow as they are needed. The first two are very powerful and many believe that DSSSL will "transform" (sorry) the world of SGML document processing Check : http://www.jclark.com/dsssl/ for another tutorial, and ftp://ftp.ornl.gov/pub/sgml/WG8/DSSSL/dsssl96b.pdf for the standard (293 pages).

ISO

DSSSL

XML Document Transformation: XSL (from: http://www.w3.org/TR/WD-xsl ) XSL is a language for expressing stylesheets. It consists of two parts: 1.a language for transforming XML documents, and 2.an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary. From XSL to DSSSL: XSLJ (from: http://www.ltg.ed.ac.uk/~ht/xslj.html ) 1. What is XSL? XSL is the eXtensible Style Language, proposed as the language for style sheets for XML in A Proposal for XSL. 2. What is xslj? xslj is a virtually complete implementation of XSL by way of translation into extended DSSSL, as supported by the latest release of James Clark's DSSSL engine Jade. xslj translates valid XSL style sheets into valid extended DSSSL style sheets, which can then be used to render XML documents using Jade. DSSSL and Scheme ( from: http://itrc.uwaterloo.ca/~papresco/dsssl/tutorial.html ) Document Style Semantics and Specification Language


Language used to associate formatting rules with the elements of a structured document encoded using SGML. Consists of two parts, a tree transformation language that can be used to reorder structured documents prior to presentation, and a formatting process that associates formatting instructions with specific "tree nodes" in the document to be presented. Both parts of DSSSL are specified using a variant of the LISP list processing programming language called Scheme. DSSSL extends the basic IEEE-defined Scheme semantics by adding functions that can transform tree structures and provide the types of information about page dimensions, formatting rules, and language typically required by a text formatter. Scheme (from ftp://ftp.cs.utexas.edu/pub/garbage/cs345/schintro-v14/schintro_5.html ; an on-line introductory book about Scheme) [ Warn people that this is partisan propaganda... ] Scheme is a very nice language for implementing languages, or for transformational programming in general--that is, writing programs that write programs--or for writing programs that can easily be extended or customized. The features that make Scheme attractive for implementing Scheme also make it good for all kinds of things, including scripting, the construction of new languages and application-specific programming environments, and so on. [ As you learn Scheme, you'll probably realize that all interesting programs end up being, in effect, application-specific programming environments...] Most Scheme systems are interactive, allowing you to incrementally develop and test parts of your program. In this respect, it is much like BASIC or Tcl--but a far cleaner and more expressive language. Scheme can also be compiled, to make programs run fast. This makes it easy to develop in, like BASIC or Tcl, but still fast, like C. (Scheme isn't usually quite as fast as C, but it's usually not too much slower, if you get a good Scheme compiler.) So if you're a Tcl or BASIC programmer looking for a less crufty and/or fossilized language, Scheme may be for you. Unlike most interactive languages, Scheme is well-designed: it's not a kludge cobbled up by some people with very limited applications in mind, and later extended past its reasonable scope of application. It was designed from the outset as a generalpurpose language, combining the best features of two earlier languages. It is fairly radical revision of Lisp, incorporating the best features of both Lisp and Algol (the ancestor of C, Pascal, et al.). (This is why Scheme has been adopted by several groups as an alternative to kludgey languages like Tcl and Perl. The Free Software Foundation's Guile extension language is based on Scheme. So is the Scheme Shell (scsh), which is a scripting language for UNIX. The CAD Framework Initiative has adopted Scheme as the glue for controlling Computer-Aided Design tools. The Dylan language is also based on Scheme, though with a different syntax and many extensions.) If you want to learn Lisp, Scheme is a good place to start. Common Lisp is a big, somewhat messy language, which is probably easiest to learn by starting with Scheme. Then you can understand Common Lisp as a series of extensions (and


significant obfuscation) of Scheme. Some of the best features of Common Lisp were copied from Scheme. If you want to get something of the flavor of functional programming, you can do that in Scheme--most well-written Scheme programs are largely functional, because that's simply the easiest way to do many interesting things. And if you just want to learn to program better, Scheme may open your eyes to new ways of thinking about programs. Many people prototype programs in Scheme, because it's so easy, even if they eventually have to recode them in other languages to satisfy their employers. Why Scheme Now? Scheme is not a new language--it's been around and evolving slowly for 20 years. The evolution of Scheme has been slow, because the people who standardize Scheme have been very conservative—features are only standardized when there is a nearuniversal consensus on how they should work. The focus has been on quality, not industrial usability. This policy has had two consequences. The first is that Scheme is a beautiful, extremely well-designed language. The second is that Scheme has been "behind the curve," lacking several features that are useful in general-purpose languages. Gradually, though, Scheme has grown from a very small language, suitable only for teaching concepts, to a very useful language. The most important new feature of Scheme (in my view) is lexically-scoped ("hygeinic") macros, which allow the implementation of many language features in a portable and fairly efficient way. This allows Scheme to remain small, but also allows useful extensions to the base language to be written as libraries, without a significant performance penalty. Groves (from: http://www.cogsci.ed.ac.uk/~ht/grove.html ; (c) Henry S. Thompson 1997) SGML Groves: A Partial Ilustrated Example Here's a trivial SGML document: ]> 1 2 And here's a picture of part of the grove that a conformant SGML parser (see the DSSSL spec. for details) should produce:



The many domain specific DTDs (From: Jon Bosak, Overview: XML, HTML, and all that; Sun Microsystems, April 11, 1997. Comment: presented here in order to show the “explosive” growth of markup conventions (called “babelic” in the introduction). Major industry DTDs (markup languages) ATA 2100 aircraft industry CMC pharmaceuticals DocBook computer software SAE J2008 automobile manufacturing TIM telecommunications ISO 12083 journal, book, and magazine publishing TEI academic and scholarly publishing HTML World Wide Web

CALS military, aerospace PCIS semiconductors IBMIDDoc IBM software TMC T2008 truck manufacturing EDGAR Securities and Exchange Commission ICADD publishing for the print-disabled UTF news media

Agent communication: KQML (from: http://www.cs.umbc.edu/kqml/whats-kqml.html ) What is KQML? KQML or the Knowledge Query and Manipulation Language is a language and protocol for exchanging information and knowledge. It is part of a larger effort, the ARPA Knowledge Sharing Effort which is aimed at developing techniques and methodology for building large-scale knowledge bases which are sharable and reusable. KQML is both a message format and a message-handling protocol to support run-time knowledge sharing among agents. KQML can be used as a language for an application program to interact with an intelligent system or for two or more intelligent systems to share knowledge in support of cooperative problem solving. KQML focuses on an extensible set of performatives, which defines the permissible operations that agents may attempt on each other's knowledge and goal stores. The performatives comprise a substrate on which to develop higher-level models of inter-agent interaction such as contract nets and negotiation. In addition, KQML provides a basic architecture for knowledge sharing through a special class of agent called communication facilitators which coordinate the interactions of other agents The ideas which underlie the evolving design of KQML are currently being explored through experimental prototype systems which are being used to support several testbeds in such areas as concurrent engineering, intelligent design and intelligent planning and scheduling. Agent communication: AL The description of AL (Alice Language), at the moment, is work in progress. AL is the outcome of G. Dionisi’s thesis 4. M. Gattoni and M. Giavazzi are preparing an 4

G. Dionisi, “AL: un linguaggio per descrivere la comunicazione tra agenti,” Dipartimento di Scienze dell'Informazione, Università di Milano, Milano, Italy, Master thesis 1998.


Italian and English version of http://weblab.crema.unimi.it/alice.

the

User

Manual,

to

be

found

in:

An excerpt of the User Manual (adapted) explains the reasons for the choice of the core representation of agents as Finite State Automata: Protocols and the formalisms for describing state changes in Agents In order to represent a communication process, various formalisms were proposed. Each of them has tried to describe a possible model of conversation, that is, define the flow of state changes occurring as a consequence of conversations. The description of the conversation's model may be called “a protocol”, i.e. a protocol defines the admissible sequence of messages or of type of messages inside a conversation. Let us review three formalisms used for describing conversation protocols between two agents: a single Finite State Automaton for both Agents, a Petri net, two communicating Finite State Automata Conversations described by a single Automaton. A conversation can be described by a single Finite State Automaton 5, where each state represents a state of two communicating agents and the set of possible speech acts - achievable in that state - and the transitions corresponds to an exchange of messages.. As an example, consider a conversation among two agents: the first one (user) asks for a service that the second one (provider) can offer. A picture describing the conversation is included hereafter.

This method is not perspicuous, as it does not distinguish between the different functionality’s and states of each of the two agents: it seems nearly possible that an agent can ask something and, at the same time, answer itself. Conversation described by Petri Nets

5

T. Winograd and F. Flores, Understanding Computers and Cognition: a new foundation for design: Ablex Publishing Corporation, 1986.


An agent – to – Agent conversation may be described by means of Petri Nets6. Let us consider the same example of a conversation as the one presented above, by means of a single Finite State Automaton. Hereafter a Petri Net graphical representation.

The Petri Net approach allows to identify the internal states and the functionalities of Agents and the evolution of the conversation. Using tokens of different colors, we may also visualize different concurrently occurring conversations. However, the “synchronization” events in Petri Nets (represented by the central column in the picture) are a form of shared memory that limits the suitability of the formalism for describing “autonomous” Agents with no shared memory or centralized control (synchronization). Conversation described by two communicating Finite State Automata. Here we have the graphical representation of the same example of conversation.

6

J. Ferber, Les systèmes multi-agents. Vers une intelligence collective. Paris: InterEditions, 1995.


As one may notice, the formalism does not assume any synchronization time for the agents, thus each Agent has private memory and autonomy. The only “shared” computational mechanism consists of exchanging messages, as it is the case in Operating Systems The two independent Automata start contemporaneously and change state at the moment they receive a message. The Automaton of the agent that begins the conversation, starts sending a message to the partner agent; this triggers a state change in the partner, that responds with a new message and so on to the end of the conversation. This last approach (Communicating Finite State Automata) is the one chosen to define AL's protocol. In order to complete the description of AL's protocol we have to show how single messages exchanged between agents are constructed. This is the aim of the next section. The two specific features of AL are the representation of Agents as Finite State Automata (briefly described above) and the compositionality of the Agent’s performatives as combinations of instances of three performative types. These performative types correspond to: tell, ask and reply in the sense that any message can be classified as belonging to one of the three categories: messages that don't want a reply (tell-like) messages that do want a reply (ask-like) messages that are a reply (reply-like) In AL the programmer may define his-her own performatives specifying to which group they belong. Further, new performatives may be defined by the user in terms of the Automata that process the conversation triggered by the new performative. AL is entirely developed in Scheme. Further information, including the code, may be asked by e-mail to the author. Agent communication: Jaskemal The description of Jaskemal (A Knowledge Manipulation Environment in Java and Scheme Languages within an Agent-based Architecture), at the moment, is work in progress. Jaskemal has been defined and prototyped by Daniele Maraschi (see: [7]and [9] )and later extended with the dynamic scheduler by Sergio Maffioletti in his thesis [8] . From the use of a first KAWA prototype the Scheme compiler into Java Byte Code has been extended to cover most of Scheme but also embedded into a full Agent’s language (see also http://www.cygnus.com/~bothner/kawa.html : notice the DSSSL interpreter; the current status of KAWA is quite advanced) The distinctive features of STROBE and AL have been implemented: Cognitive (First Class) Environments, KQML-like performatives from the Java Agent Template, the Finite State Automaton view of Agents during conversations and the compositionality of performatives). At the moment, we are documenting the language and using it within two applicative projects 7. Further information about Jaskemal, and the code, may be asked by e-mail to the author. 7

One of them is documented in: S. A. Cerri, V. Loia, P. Fontanesi, and A. Bettinelli, “Serendipitous acquisition of Web knowledge by Agents in the context of Human Learning,” presented at THAI-ETIS :


European Symposium on Telematics, Hypermedia and Artificial Intelligence, Varese, Italy, 1999.