collaboration

[RE01 Rice Brian T. EM2]

What follows are just some quick responses, as I am still reading your
documentation (in the little bits of time I can use of this shared
computer).

> RRBTE> Basically Arrow is a system that models everything as
> RRBTE> Cons-cells, but lacks Lisp's semantic model. Right now, it
> 
> Not bad - you want to start reading the askemos code from place.scm.
> I feel there are even more simillarities than I expected.

It seems so. You also have considered the networked environment more than I
usually consider things, so maybe this 'voting' scheme might make sense to
me as well once I consider the issues.

> RRBTE> implements Relational Algebra lazily (flawlessly on my own copy
> RRBTE> of the code, but the copy on the Tunes server is outdated and
> RRBTE> buggy - still it is self-documenting). Relational algebra
> RRBTE> relates quite well to concurrent equational membership rewrite
> RRBTE> logic semantics (whew! :) that Maude has, though. Equational
> RRBTE> rewrite logic is just the logic of term replacement in symbolic
> RRBTE> equations as an evaluation/proof model. 'membership' refers to
> ...
> 
> OK, too much.  What I would need was again a pointer where to start
> reading from, without so much patience.

Well, I can re-iterate about Maude: http://maude.csl.sri.com,

but that is still fairly heavy material. There are links from there to other
sites explaining the basics of rewriting logic and why it's an interesting
perspective on computation. Basically if you've used Prolog, you can
consider rewrite to be a more general pattern-matching / unification
approach to specifying things.

> >> Askemos defines a virtual machine at document level, wich works
> >> within an abstract infromation space.
> 
> RRBTE> Document level? Perhaps you can restate this as specification
> RRBTE> level, without-loss-of-information.
> 
> Ehm, by "at document level" I mean that an operation is specified,
> which like result=function(state, message) -- where result, function,
> state and message are pieces of information each expressed as an XML
> document.
> 
> That way we have an operation abstract enough to ignore usual OS
> issues.

Okay, I may have found a difference point to mention here: basically the
abstraction level I'm looking for is at the level of category theory. As far
as I am concerned, the abstraction from "usual OS issues" is a side-benefit
and something that I don't find worthwhile to mention to people as I
introduce them to the concepts I'm working on. This is mostly because I
don't want to advertise something that depends on the results of research I
haven't completed yet: it's not yet known how such an abstraction level can
be acheived or what qualifies such an abstraction level differently from
anything we have now (including Lisp's).

I do this for much the same reason that I don't use the word "reflection"
(let alone "artificial intelligence" *snicker*) in demos even when that's
precisely what I'm demonstrating: knowledgable researchers are too familiar
and focussed on the negative results in the area, and people who aren't
experts often react like I'm waving a magic wand (for better or for worse).
So I use terms from category theory like homomorphism (cata-, ana-, etc.).
Of course, it's not much better a term, but explaining things as being parts
of some kind of network places it more correctly in people's conceptual
spaces: the current technology market scheme works around network-building
(in a hardware and middleware context).

> /Jerry

Thanks for the .tar.
~