John F. Sowa wrote:
> Ed,
>
> That is true, but you have to distinguish the object language
> from the metalanguage.
>
> EB> ... it is not possible to capture anything in a notation-
> > independent way". You need a notation to present the
> > information to anyone else.
>
> But it is possible to use a metalanguage to define the semantics
> of one or more object languages in a way that does not make any
> one of the object languages more privileged than any other.
> (01)
I fully agree. It occurred to me after I wrote what I did that you were
thinking in terms of Common Logic. (02)
I have had some difficulty in OMG sorting out the difference between an
abstract syntax model and a conceptual model for a language, both of
which are expressed in a metalanguage. The nearest I can come to a
clear distinction is that in an 'abstract syntax model' there is a
one-to-one mapping from concept to notational production (although there
may be some lexical reuse). In a concept model for the same language,
that is not necessarily the case. There may be several syntactic
structures that have the same fundamental semantics or use different
representations of what is really the same concept. The conceptual
model may also support semantically meaningful structures for which
there is no syntax, precisely because it abstracts the concepts from
multiple syntactic structures that limit what can be stated. (03)
That leads to a further observation. In most cases, an 'abstract syntax
model' is made before, or from, the productions of the language, whereas
the conceptual metamodel is made after the language is published, and
often in the light of the concepts of related languages. (04)
As you might guess, this realization is the product of bitter
experience. I am a conceptual modeler, and I regularly cross swords
with "metamodelers" who are just converting BNF to UML or OWL. (05)
What follows can be summarized as an example that illustrates the
problem as much as it supports John's point. (06)
> I usually use Common Logic as an example, but to make the point
> more clearly, I'll use the assembly language for a typical
> computer. (For me, that means IBM 360, but you can adapt it to
> any other machine.)
> (07)
Aside: Having taught this stuff, I think that the concept "typical
computer" does not apply to the IBM 360, which had a hybrid
architecture. In a certain sense, its architecture was a pattern for
many machines to follow, including VAXes and the MC68K whose
grandchildren probably populate your cell phone. (The Intel 80x86
series and its grandchildren had a significantly less flexible design.) (08)
> The semantics of the language is defined by the System/360 POP
> (Principles of Operation). (09)
This is only partly true. IBM 360 Assembly language was rather more
than a direct encoding of machine instructions. There were the obvious
additional concepts like storage reservation, literals (which you
mention) and floating symbols, and then there was the macro language,
and all the stuff that was related to getting the Link Editor and the
Initiator (program loader) to create the intended runtime "image" (the
memory bits that embodied the program when it was running). (010)
This may appear to be a quibble, but it means that the POP is only the
semantics of 75% of the "language in practice". If you made a metamodel
of the whole language, how many significantly different surface
languages would have exactly that model? Would the differences be
anything more than lexical (the rules for formation of terminal symbols)? (011)
> And the metalanguage is a carefully
> written English, mostly by Andris Padegs, but supplemented with
> lots of unpublished commentary and corrections by the implementers
> of each machine.
>
> That manual begins with a description (in English supplemented
> with diagrams) of an abstract System/360 machine, which is
> a common subset of the registers and bits in every physical
> implementation in the models 30, 40, 50, 65, 75. (I'll omit
> the Model 91 and 95, which had some minor changes.)
>
> Then for each machine instruction, there was a short section
> that specified the *preconditions* (i.e. states of each relevant
> register and bit) before the instruction was executed and
> the *postconditions* after its execution. This point also
> illustrates the general principle of defining a programming
> language by using a declarative language to state preconditions
> and postconditions.
>
> That POP manual was a notation-independent specification of
> the semantics of the IBM assembly language, which used a
> higher-level notation than bits that mapped to the machine
> code. It also specified higher-level data (characters,
> integers, and floating-point numbers) in a way that mapped
> to the bit patterns.
> (012)
Aside: One of my pet peeves with the POP was that it did not, in fact,
specify the bit representation of negative floating point values. In
its treatise on the floating-point concept, it never actually said that
the representation was sign-magnitude, while the integer representation
was clearly described as 2's complement. (And then, of course, we had
the Cahn diatribes about what it does and doesn't say about floating
arithmetic, which gave rise to an IEEE standard that finally became part
of the Intel Pentium architecture 30 years later. One man's semantic
model is another man's sketch.) (013)
> Meanwhile, Niklaus Wirth defined a totally different notation,
> called PL/360, which used an Algol-like notation, but mapped
> to exactly the same machine language:
>
> http://www.fh-jena.de/~kleine/history/languages/pl360man.txt
>
> The IBM 360 assembler language and Wirth's PL/360 are two
> very different notations that both map to identical semantics.
> (014)
Well, they have about 75% of the semantics in common. PL/360 had other
architectural notions of software structures, such as a subprogram, as
part of the language. The POP has only Branch-And-Link ("call")
(spelled BAL, which is the assembly acronym) and Branch Register
("return"). The corresponding assembly language concept is an ENTRY
symbol, an externally accessible symbol, which relates to generated
information for the Link Editor -- a critical functionality of
assemblers and compilers that goes beyond the instruction set. PL/360
had a compiler (of sorts) that knew how to generate the common patterns,
whereas you had to tell the assembler explicitly or use one of the
standard macros. (015)
> Both of them use exactly the same semantic specification,
> which was written in English by Andris Padegs. The syntax
> of each was independently specified in English, but each
> specification mapped the English to the same semantic spec.
>
> This illustrates the method for specifying the semantics of
> multiple notations without giving any one of them a privileged
> status relative to any of the others. (Of course, IBM did
> have more control over the development of the hardware than
> Wirth, so their specification was "more official" than his.
> But that is a separate issue.)
> (016)
Regrettably, it also illustrates that languages tend to embody
organizational stuff that is not the primary meat of the language but is
critical to making it useful. The 'language-independent' common
semantics is perhaps the lion's share of the language model, but a
complete metamodel for the language also deals with the other elements. (017)
One of the least consistent aspects of software languages is the
pragmata for dealing with modularization and importation. The
Achillles' heel of CLIF is "modules", and it was partly designed to deal
with a semantic problem discovered in RDF importation. These things are
not just syntactic -- modularization has a semantics, and it relates to
both syntactic structures and semantic structures. As soon as you have
a radically different syntax, the common pattern (if any) for the
modularization semantics is modified to get the syntactic impacts right. (018)
It is hard to make one language-independent metamodel for two entire
languages. You can make a common semantics metamodel, but then you have
to import it into the language-specific metamodels that deal with the
noisy elements of integration. And in every case in my experience, the
requirement for your common semantics metamodel to be importable will
affect some aspects of its characterization of certain concepts. (UML,
for example, has the wondrous PackageMerge, which basically does what
rdf:about does, but in a way only UML people could describe.) (019)
-Ed (020)
P.S. I have to say that John's example takes me back a few years. I
haven't dealt with the 360/370 series assembler since 1972. It is
amazing how much junk I stuffed into my brain in my youth and haven't
forgotten, while much more valuable knowledge acquired then and since
has vanished. :-) (021)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (022)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (023)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (024)
|