Bux fixes, more progress, beginnings of a tutorial

Okay, here's some much-fixed code for Arrows, along with a 
much-updated tests file. Everything in the tests works fine, along 
with a few other things. It also works as a small tutorial for basic 
arrow concepts. I suggest trying to use InductionGraph by making a 
new instance, assigning it to a variable, and then sending it some 
InductionGraph-y messages to test it out. I haven't tested the whole 
thing, but much of it works.

Incidentally, Arrow is very difficult to architecture: a lot of what 
it is is very related to a lot of AI projects of the past. A lot of 
the code has to resort to brute-force searching when the proper 
meta-information isn't there beforehand. So basically the coding aim 
is to make a lot of common programming language semantics available 
to be easily done within the framework, and to not prevent any other 
semantics.

As coding continues I am more convinced that an OCAML implementation 
would be ideal for achieving some good performance before 
self-hosting becomes feasible. This will take some time, but should 
also be quite as readable as the Smalltalk version (I hope so, 
anyway).

There are a few changes and architectural features I have not been 
showing, mostly because they have been in constant flux and often 
aren't very readable... they're mostly hack-based ideas, but should 
be coming together soon. As I study Maude more closely as well as a 
lot of the suggested resources mentioned here earlier, a strategy is 
starting to become clear (it only took 7 years :P).

One last note: Arrows is officially reflective, since recently I have 

Inductive and Coinductive graphs

Hello,

     I already sent this question to Brian. In his
Arrows code, he has Inductive Graph and Coinductive
Graph classes (in Smalltalk).

- what are these concepts? I.e. what is an inductive
     graph and what is a coinuctive graph. Please 
     point at something to read, paper, book, URL...

- are these dual categoric concepts like initial
     object and final object?

Regards, Vasili

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

FW: Concepts: Inductive vs Coinductive

Hi all,

I noticed the other day that the original message was forwarded to the list,
but not my reply. Since I can't access any of my usual accounts or the
internet at the moment, I'm forwarding this for general information. Also,
I've acheived a few breakthroughs in the Arrow architecture design
(basically resulting in a lot of broken cases being cleaned up, bugs wiped
out, and the design actually has a coherent structure) so that you should
expect a 0.1 release by the time I return on June 22, with a preliminary
release due in a week. There are more extensive tests to document and
ensure, which will take most of the time necessary for the work. The rest
will be devoted to shifting around (re-factoring into a design that makes
sense) my make-shift and very preliminary pattern-matching system.

I'm also focussed on getting a Map graph type implemented for Arrow, to use
symbol->value associations as the first blocks of a real programming
language building system. (Obviously something using a cons-cell based
syntax with variable semantics built up gradually.)

(I am interrupted now. Will talk later.)
Thanks,
~

> -----Original Message-----
> From: RE01 Rice Brian T. EM2 
> Sent: Thursday, June 07, 2001 10:23 PM
> To: 'Galchin Vasili'
> Subject: RE: Concepts: Inductive vs Coinductive
> 
> 

Arrow Version 0.1 Release

Wow, guys. :)

That's all I can say. Check out the new protocols, cleaned up code, 
bug fixes, neatly laid-out class hierarchy (select 'ArrowStub' and 
hit alt-h for a browser on the class hierarchy for the large majority 
of the architecture's classes), and some new cool operators.

It's at the usual place: http://tunes.org/~water/arrow

Please ignore the project file until I put together one with the 
updated code and some more useful code views. This actually can 
probably wait for the more important work on the architecture.

This also means that any further changes to the system I will list 
explicitly and track subversions. I'll write out what the road map is 
for reaching 1.0 either tomorrow or when I return home on this coming 
Thursday. I'll say for now that between now and v1.0, Slate will be 
implemented as a subset of Arrow. :)

The new ArrowTests.text has a new operator >> at the end, and arrows 
and graphs respond to +, |, & appropriately. Everything is lazy, with 
the exception of #anyOne, the existential quantifier, because it 
needs re-writing in an intension system and self-hosted pattern 
matcher that I am cooking up at the moment. Also coming is a 
SEXP-eating REPL and a basic transcript app. Arrow frames are still 
not done, but functional, and SmalltalkMOP is usable right now.

If something doesn't work, let me know immediately so I can address 
it. There are a few bugs I know of, but I don't want to have to 
bother you with them unless you run into them yourself. Most of them 

Arrow road-map

Hello again.

Here's a rough outline of where I will start calling minor version 
numbers. When all of this stuff gets done, I'll update 0.X to 1.0 
following lots of bug-testing.

0.1
We're there. Lazy graph framework is there, composition, application, 
etc. are all lazy enough. Distinction of concrete and abstract 
arrows, basic frames, the Smalltalk MOP works in a very basic sense 
for immutable objects and literals.

0.2
The intension framework. This will likely not take up much code 
space, but result in a few refactorings, possible one or two new 
classes, and make frame assertions possible to interact in. Frame 
assertions (see AssertionGraph and ArrowFrame comments) will likely 
be the location for the basic pattern-matching mechanisms.

0.3
The interactive evaluator. This requires the implementation and usage 
of Dictionary-like (mappings from symbols to values - environments) 
graphs embedded into frames. The evaluator will use SEXP syntax and 
arrow semantics. If it's easily feasible, recursive embedding of 
environments will be implemented. Other issues may come up about this 
part of the design at that time or later: this can be re-designed a 
few times if needed. It may or may not be encoded within arrows and 
frames from the beginning, but self-hosting is an eventual goal for 
obvious reasons. There already are a Lisp interpreter and a Prolog 
interpreter to work from, as well as LIBRA. What will remain is the 

Survey - who's listening?

I'd like to know what people think about the direction I'm taking and 
whether my effort is in line with Tunes goals. Particularly, if any 
of the project founders have any input or mis-understandings about 
how the current package is supposed to achieve Tunes goals, I would 
like to know. Obviously there are many who are not familiar enough 
with Smalltalk other than to look and perhaps get roughly familiar, 
so I understand there's not a lot of deep comprehension possible yet. 
But I'd like to know what people think aside from "wait and see."

I'm taking from Lisp, Maude, and Libra, and I'm going for monads as 
well for linear state-passing and I/O etc., so those are all good 
points but I'd like to know if I've missed anything or need to 
explain something in particular.

Faré? Armin? I'd like comments from you two in particular.

Thanks,
~

Re: Survey - who's listening?

On Sun, 17 Jun 2001, Brian Rice wrote:

> I'd like to know what people think about the direction I'm taking and 
> whether my effort is in line with Tunes goals. Particularly, if any 
> of the project founders have any input or mis-understandings about 
> how the current package is supposed to achieve Tunes goals, I would 
> like to know. Obviously there are many who are not familiar enough 
> with Smalltalk other than to look and perhaps get roughly familiar, 
> so I understand there's not a lot of deep comprehension possible yet. 
> But I'd like to know what people think aside from "wait and see."

i guess im one of these... as i have serious holes in my background, not
to mention smalltalk. i guess my usefullness is limited to the point where
i can play with example slate code. but anyways, im listening, looking at
the class docs and such and find things very promising.

  keep up the good work Brian,

- 101.

[OT] Modal logic

Semantic Web

Hello everybody,

The Scientific American published in May a non-technical article:

"The Semantic Web",
http://www.scientificamerican.com/2001/0501issue/0501berners-lee.html) 

abount the development of a knowledge-system-based web over the current
WWW. 

Armin

RE: Survey - who's listening?

Armed with moderate intoxication, but leaving behind common sense and
dignity, Beren the One-handed rides into the fray.

I'm listening.
I have lots of questions but not sure how many I will be able to express.

My background may (or may not) have anything to do with my ignorance and my
questions... so here it is:
- electrical engineering at Uni (don't think I ever really used it in the
workplace)
- programming in C and assembler (both of these primarily for signal
processing apps)
- no formal set theory or logic (except boolean algebra)
- I have never used Smalltalk or Squeak, and haven't tried out Arrows (I
think I've got some sort of a grip on your Arrows intro)

Questions:
- does Arrows have some sort of equivalent to C's struct??
i guess what i'm asking is "how does Arrows implement complex
types/objects??"
on 2nd thoughts... how does set theory handle complex types??
- i don't understand your use of incidence, composition, elements...
is this set theory?? is it related to the first question??  are there any
papers i should read?? should i head off and join concatenative??
- where do you see Arrows fitting into the TUNES framework??
	- High/low level (or both)
- ummm, i've just realised that all my other Arrows specific questions
relate to this last one, which means i can shut up early... lucky dogs.

cheers,
SDH

PS How will slate be a subset of Arrows??
SELF looked very interesting
	- i understood it straight away
	- i could see limitations, but also scope for modifying it to avoid those
Can i see an example of (visionary) slate syntax??