Bursting in [was: Maude licensed under GPL, 2.0 approaching...]

[Felix Holmgren]

This is a multi-part message in MIME format.

------=_NextPart_000_1A95_01C33293.29141870
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I'm another one of the people who on this list are called "lurkers" and
on the cliki called "learners". The reason I come bursting in now is
simply that I have some links to contribute. The reason I haven't done
it before is that I don't really have much time to give, and the project
hasn't (at least until recently) been at a stage where I could choose
some task/issue to concentrate on -- and (as I'll discuss later) it's
been pretty hard to see just what stage it HAS been on. I'll take the
opportunity to blurt out some other thoughts. First the links:

Grigore Rosu's got two papers on implementing behavioral rewriting
methods, with a special focus on extending Maude; exactly what Alexis
has been talking about. They are called "On Implementing Behavioral
Rewriting" and "Towards Behavioral Maude: Behavioral Membership
Equational Logic". I haven't read them closely and they contain a lot of
duplicate material from other papers, but there is some stuff on using
the reflective capabilities of Maude to implement behavioral rewriting
which should be of great interest. Both papers can be found at
http://gureni.cs.uiuc.edu/~grosu/publications.html

Another system that is not mentioned anywhere on the Tunes sites is
Expaner2. It is based on Swinging Types, which is another framework that
integrates visible/hidden sorts, inductive/coinductive properties etc.
Pretty impressive stuff that might be useful to develop/test the Tunes
concepts, even if it can't be directly used to implement Tunes.
http://ls5-www.cs.uni-dortmund.de/~peter/Swinging.html
http://ls5-www.cs.uni-dortmund.de/~koeppen/Expander2

I'll put these links on the cliki when I have the time, if no-one else
does it.

Now my (seemingly) random notes:

1) About the discussion on how to educate newbies: the stuff you're
involved in is advanced enough that no-one who's not thoroughly
motivated will get even halfways to understanding the issues at hand. To
people who have that kind of interest, it will matter little whether
there is some kind of curriculum, complete with exercises and projects,
or not, since they will be the kind of people who find their own way of
learning anyway. The wealth of information and links on the Tunes sites
is a really great resource in itself for someone who wants to get into
this kind of work. I think it's better to concentrate on expanding this
(with an increasingly clear focus on the particulars of the project)
instead of trying to tap into the psychology of a stereotypical Newbie.
However, as the specs and code get more concrete (which I hope they will
soon) it's of cource crucial to document everything really well, so that
people who might not be able to contribute much in terms of mathematical
foundations for the project can start contributing in implementing basic
algorithms, building libraries, etc. (I know the old argument that
someone who only knows about writing database queries or whatever can't
contribute anything anyway, but there *are* a lot of people between
these two poles who might be able to contribute a lot once it's clear
what's to be done.)

2) From Alexis' post:
>My take on the def of an object vs the cliki version is that every
object
>has attributes (that make up its data type) - these are the defining
>properties of it. For every object there is a supertype for
representing
>the object's attributes and so on up the abstraction tree. Providing
that
>the reflection implementation is 'complete', you have abstracted your
>object concept (I'm probably stating the obvious here!)
A couple of thoughts regarding this:
A) A user-defined attribute that states some desired treatment of an
object should of course contribute to determining it's type, but so
should *all* of its structure and (behavioral) properties. Sometimes
dispatch might only be required to take into account the (arbitrarily)
user-defined "tag" attributes of objects (such as their names or
inheritance graphs), or some infered properties of its functions
(argument and return types); generally, though, it should be possible to
dispatch on *any* (provable) property of objects, including behavioral
properties. It seems to me that this is the only way to keep the object
concept fully abstract. If types are ultimately determined by atomic
attributes, everything can clearly not be an object. (I'm not sure what
Alexis meant by "and so on up the abstraction tree"; where does it end?
If it's a tree, can it really support a fully abstract view of objects?)
The meta-object system must definitely allow for this kind of dispatch
to be truly useful (and not just a messy code structuring tool which
mixes up static and dynamical aspects of programs).
This is (a version of) the issue that originally got me into the search
that finally took me to Tunes. Since I'm pretty unsure about this stuff,
I'll stop here, but I'd be grateful if someone gave me the official (ha
ha) Tunes perspective on this. Perhaps a classical type system should be
kept separated from the sort of "conditional membership" I'm talking
about? I'm know I'm unclear on the terminology etc (and a little bold on
issues I'm not too sure about), but I'm just trying to get to the inside
of the Tunes perspective.
B) How can there really be any uncertainty about the Tunes definition of
"object" at this point? The pre-pre-draft spec that Brian published was
a great step forward, but where is all the background material? The
stuff on the web page and cliki doesn't come near giving a background
for understanding what kind of decisions and considerations were
involved in writing the draft. Maybe I'm being ignorant about the unique
Tunes approach towards collaboration, but it seems to me (as it has to
many before me) that the time is ripe to simply set up a priority list
of issues to be decided upon (if only temporarily, and to see what
different takes there might be), and make a first test specification of
the basic system. That would make it possible for people like me (who
have some basic idea of what is to be accomplished, but not about at
which points the process is halting, and exactly why) to contribute in a
systematic way, not only by writing code, but also in working out the
conceptual problems once they have been clearly identified. Right now,
it's hard to get an idea about what is commonly agreed upon
Tunes-wisdom, and what is completely up in the air.

3)
>> This could be a god news for this project: are we gradually
approaching a
>> shared agreement about Maude as good platform to bootstrapping (at
least
>> some aspects of) Tunes?
>Check the posts from 2 years ago- people were talking about this then.
>Alexis.
Don't get me depressed. I can't see how anything more than Maude 2
(implementing something like BMaude) should be necessary to implement
the basic interfaces and protocols. Also, the concepts (although they
are hard to extract from the Tunes sites) are not too unclear. It would
be great if some insider right now stated why the project is not moving
much: is it because of theoretical/conceptual problems or because of
administrative/cooperative problems? If the former, which concepts need
to be refined and decided on first? If the latter, what is the least
common ground shared? What is the basic point of divergence?

I ended up writing the same old post that everyone else seems to have
written at one time or another, but I promise I will not write anything
like it again. If all the knowledge and good judgement you people have
aquired over the years could be communicated just a little more
efficiently, I'm pretty sure no-one would have to write this kind of
post again.

I'll just finish with a quote (from Tao Te Ching, stanza 27, Following
the Tao):
[...]
Knowing that virtue may grow from example, 
this is the way in which the sage teaches, 
abandoning no one who stops to listen. 
Thus, from experience of the sage, 
all might learn, and so might gain. 
[...]

Okay, whatever happens: thanks for everything so far.
/Felix 


------=_NextPart_000_1A95_01C33293.29141870
Content-Type: text/html
Content-Transfer-Encoding: 7bit

<HTML>
<BODY>
I'm another one of the people who on this list are called "lurkers" and on the cliki called "learners". The reason I come bursting in now is simply that I have some links to contribute. The reason I haven't done it before is that I don't really have much time to give, and the project hasn't (at least until recently) been at a stage where I could choose some task/issue to concentrate on -- and (as I'll discuss later) it's been pretty hard to see just what stage it HAS been on. I'll take the opportunity to blurt out some other thoughts. First the links:<br>
<br>
Grigore Rosu's got two papers on implementing behavioral rewriting methods, with a special focus on extending Maude; exactly what Alexis has been talking about. They are called "On Implementing Behavioral Rewriting" and "Towards Behavioral Maude: Behavioral Membership Equational Logic". I haven't read them closely and they contain a lot of duplicate material from other papers, but there is some stuff on using the reflective capabilities of Maude to implement behavioral rewriting which should be of great interest. Both papers can be found at http://gureni.cs.uiuc.edu/~grosu/publications.html<br>
<br>
Another system that is not mentioned anywhere on the Tunes sites is Expaner2. It is based on Swinging Types, which is another framework that integrates visible/hidden sorts, inductive/coinductive properties etc. Pretty impressive stuff that might be useful to develop/test the Tunes concepts, even if it can't be directly used to implement Tunes.<br>
http://ls5-www.cs.uni-dortmund.de/~peter/Swinging.html<br>
http://ls5-www.cs.uni-dortmund.de/~koeppen/Expander2<br>
<br>
I'll put these links on the cliki when I have the time, if no-one else does it.<br>
<br>
Now my (seemingly) random notes:<br>
<br>
1) About the discussion on how to educate newbies: the stuff you're involved in is advanced enough that no-one who's not thoroughly motivated will get even halfways to understanding the issues at hand. To people who have that kind of interest, it will matter little whether there is some kind of curriculum, complete with exercises and projects, or not, since they will be the kind of people who find their own way of learning anyway. The wealth of information and links on the Tunes sites is a really great resource in itself for someone who wants to get into this kind of work. I think it's better to concentrate on expanding this (with an increasingly clear focus on the particulars of the project) instead of trying to tap into the psychology of a stereotypical Newbie. However, as the specs and code get more concrete (which I hope they will soon) it's of cource crucial to document everything really well, so that people who might not be able to contribute much in terms of mathematical foundations for the project can start contributing in implementing basic algorithms, building libraries, etc. (I know the old argument that someone who only knows about writing database queries or whatever can't contribute anything anyway, but there *are* a lot of people between these two poles who might be able to contribute a lot once it's clear what's to be done.)<br>
<br>
2) From Alexis' post:<br>
>My take on the def of an object vs the cliki version is that every object<br>
>has attributes (that make up its data type) - these are the defining<br>
>properties of it. For every object there is a supertype for representing<br>
>the object's attributes and so on up the abstraction tree. Providing that<br>
>the reflection implementation is 'complete', you have abstracted your<br>
>object concept (I'm probably stating the obvious here!)<br>
A couple of thoughts regarding this:<br>
A) A user-defined attribute that states some desired treatment of an object should of course contribute to determining it's type, but so should *all* of its structure and (behavioral) properties. Sometimes dispatch might only be required to take into account the (arbitrarily) user-defined "tag" attributes of objects (such as their names or inheritance graphs), or some infered properties of its functions (argument and return types); generally, though, it should be possible to dispatch on *any* (provable) property of objects, including behavioral properties. It seems to me that this is the only way to keep the object concept fully abstract. If types are ultimately determined by atomic attributes, everything can clearly not be an object. (I'm not sure what Alexis meant by "and so on up the abstraction tree"; where does it end? If it's a tree, can it really support a fully abstract view of objects?) The meta-object system must definitely allow for this kind of dispatch to be truly useful (and not just a messy code structuring tool which mixes up static and dynamical aspects of programs).<br>
   This is (a version of) the issue that originally got me into the search that finally took me to Tunes. Since I'm pretty unsure about this stuff, I'll stop here, but I'd be grateful if someone gave me the official (ha ha) Tunes perspective on this. Perhaps a classical type system should be kept separated from the sort of "conditional membership" I'm talking about? I'm know I'm unclear on the terminology etc (and a little bold on issues I'm not too sure about), but I'm just trying to get to the inside of the Tunes perspective.<br>
B) How can there really be any uncertainty about the Tunes definition of "object" at this point? The pre-pre-draft spec that Brian published was a great step forward, but where is all the background material? The stuff on the web page and cliki doesn't come near giving a background for understanding what kind of decisions and considerations were involved in writing the draft. Maybe I'm being ignorant about the unique Tunes approach towards collaboration, but it seems to me (as it has to many before me) that the time is ripe to simply set up a priority list of issues to be decided upon (if only temporarily, and to see what different takes there might be), and make a first test specification of the basic system. That would make it possible for people like me (who have some basic idea of what is to be accomplished, but not about at which points the process is halting, and exactly why) to contribute in a systematic way, not only by writing code, but also in working out the conceptual problems once they have been clearly identified. Right now, it's hard to get an idea about what is commonly agreed upon Tunes-wisdom, and what is completely up in the air.<br>
<br>
3)<br>
>> This could be a god news for this project: are we gradually approaching a<br>
>> shared agreement about Maude as good platform to bootstrapping (at least<br>
>> some aspects of) Tunes?<br>
>Check the posts from 2 years ago- people were talking about this then.<br>
>Alexis.<br>
Don't get me depressed. I can't see how anything more than Maude 2 (implementing something like BMaude) should be necessary to implement the basic interfaces and protocols. Also, the concepts (although they are hard to extract from the Tunes sites) are not too unclear. It would be great if some insider right now stated why the project is not moving much: is it because of theoretical/conceptual problems or because of administrative/cooperative problems? If the former, which concepts need to be refined and decided on first? If the latter, what is the least common ground shared? What is the basic point of divergence?<br>
<br>
I ended up writing the same old post that everyone else seems to have written at one time or another, but I promise I will not write anything like it again. If all the knowledge and good judgement you people have aquired over the years could be communicated just a little more efficiently, I'm pretty sure no-one would have to write this kind of post again.<br>
<br>
I'll just finish with a quote (from Tao Te Ching, stanza 27, Following the Tao):<br>
[...]<br>
Knowing that virtue may grow from example, <br>
this is the way in which the sage teaches, <br>
abandoning no one who stops to listen. <br>
Thus, from experience of the sage, <br>
all might learn, and so might gain. <br>
[...]<br>
<br>
Okay, whatever happens: thanks for everything so far.<br>
/Felix
</BODY></HTML>
<BR> 
------=_NextPart_000_1A95_01C33293.29141870--