Introduction and misc ideas

[Brian T Rice]

On Thu, 6 Jun 2002, Alexis Read wrote:

AR>On Thu, 6 Jun 2002, Armin Rigo wrote:
AR>
AR>> Hello,
AR>>
AR>> Alexis Read wrote:
AR>> > Language independent aka inventing a new 'superset' language no?
AR>>
AR>> I do not agree that language-independance means inventing a new superset
AR>> language. We need ways to express bridges between them, and even
AR>> imperfect bridges when the concepts do not match a priori. I dislike the
AR>> idea of taking a single (however powerful) language as a foundation.
AR>
AR>Ok, so the question then is: how do we express bridges between them?
AR>One commercial way of expressing bridges is via CORBA. CORBA has an Object
AR>Management Architecture (OMA) which uses an OMG Object Model. The OMG
AR>Object Model defines common object semantics for specifying the externally
AR>visible characteristics of objects in a standard and
AR>implementation-independent way. In this model clients request services
AR>from objects (which will also be called servers) through a well-defined
AR>interface. This interface is specified in OMG IDL (Interface Definition
AR>Language).
[Omitted details about the ultimate fuzziness of the 'superset language'
idea]

Basically, you mean a kind or kinds of meta-language. Maude brings this up
in several of its core papers as one of the advantages of its model.

AR>> > XSLT has no reflective capability that I can see, hence extending the
AR>> > language won't be that clean.
AR>>
AR>> I have found a stricking closeness between John Hughes's paper (link in
AR>> previous e-mail) and "Reflection-Oriented Programming" by Sobel and
AR>> Friedman, and althought Hughes' arrows seem to allow a more abstract and
AR>> more powerful way of doing what Sobel and Friedman do, he never talks
AR>> about reflectivity. In fact I guess that the arrows formalism could be
AR>> the correct way to introduce reflectivity in any functional language
AR>> that can support it.
AR>
AR>The arrows formalism I guess can be thought of as a construct which can
AR>describe syntax and semantics as above, the thing is, working with this
AR>formalism is akin to working in a new language.
AR>
AR>I think that introducing reflectivity via arrows is Brian's intention so
AR>he may have more to say on the subject.

I do, and I am following this thread with interest, but both you and Armin
have been covering the right points so far. Just consider me in agreement,
but ask questions if something seems specifically unclear.

I will re-emphasize that the Arrow set of ideas includes being a
meta-language while not being a language in itself. The point there being
that pinning Arrow down as implementing certain concepts is too
restrictive for the purposes of implementing Tunes.

AR>The other formalism that seems to be as powerful, is rewrite logic, which
AR>has been developed further in CafeOBJ, Maude, ELAN and BOBJ. The
AR>capabilities of Maude in particular have reached such a point where it is
AR>almost usable to regular programmers.

Except for the syntax. :) Which is why I'm suggesting a strategy of taking
the underlying engine and stripping off the syntax and giving it a Lisp
interface (the point being to take advantage of it in Arrow directly of
course).

AR>see the link I gave last time for Maude. The semantics are somwhat similar
AR>to VHDL and ADA so if you're familiar with them, its easy to learn.

Thanks for pointing that out. It hadn't occurred to me to emphasize the
approach to Maude that takes its modules as ADTs to leverage an existing
comfort that programmers already have with the subject. Maude just has
some very nice semantics for building and combining ADTs. Whether it's
algebraic rewrite or not could be considered by the programmer to just be
a strategy to get the better overall results. Perhaps there's even a good
basis for a Tunes explanation strategy.

AR>> Armin.
AR>
AR>Alexis.

Thanks guys, I'll get more involved as I can and keep working on my code
and documentation improvements.
~