Hello, Michael,

First, welcome to the Self community.

I should add that I am working on "Slate" which is like Self but with multi-methods and without object literals. It actually looks more like Smalltalk-80, but anyway it's really powerful, and we will provide a Morphic style environment in it for dynamic media. We're taking a superset of Morphic and CLIM-style ideas and merging them; which is pretty revolutionary, in my opinion, but it's hard to convey those benefits as the number of grokking users of both Morphic and CLIM number in the single digits, and the communities have no (acknowledged) shared history or motivations.

The core code is largely done, but we are working on core VM and environment support issues before deploying this. This is also a part-time project for both its' creators, but we want to change that into a paying gig. Our general stance is that Smalltalk-80 is not nearly powerful enough to do this stuff, although Squeak tries, and that Self, while a great demonstration in its time, is largely not suited to move on. In a lot of senses, we don't think Self is powerful enough, either, or too powerful in the wrong ways. Now I get to back these (semi-inflammatory) words up by delivering further Slate releases.

We are heavily inspired by Jecel's ideas, and discuss with him on our chat channel.

The site is http://slate.tunes.org/

There are a gaggle of prototype-based languages these days that claim to be Self-inspired, but largely they throw everything out but the prototypes.

PS: There is also activity at Sun about Self these days, although those involved are pretty quiet about the whole thing. I'm not sure I'm even supposed to share the info, but I'm opposed to the "closed doors" mentality, because I think there's effort being duplicated and/or wasted. Anyway, they're bootstrapping Self in itself, calling the compiler or effort "Klein", which I've often wondered whether it was a play on Slate's "Mobius" implementation framework or just too irresistible a pun to make for any party.

On Jun 18, 2004, at 4:42 PM, Michael Latta wrote:

Thanks for more pointers, I will check them out.

On your example below. In the presence of concurrency I would expect the result to be unpredictable. I do not think that is a bad thing. It does make it harder to program, but is not incorrect. The goal of making concurrent programming as easy as sequential programming will be quite an achievement. I look forward to your work on this. If I head in that direction I will let you know.

Michael

On Jun 18, 2004, at 4:29 PM, Jecel Assumpcao Jr wrote:

...

On Friday 18 June 2004 14:47, Michael Latta wrote:

...

Did you ever incorporate the concurrency ideas from TinySelf into your Merlin product? Many of the Merlintec pages are very out of date (the english ones anyway). What is the current status?

Sorry about the ugly and outdated pages. Unfortunately it will be a while before I get around to fixing that.

I am currently finishing a 16 bit implementation of a Self processor (see http://www.merlintec.com:8080/Oliver), but that has a very traditional parallelism model (lightweight threads).

The 32 (and 36) bit version is still in the design stage and does implement task switching in hardware using ideas from TinySelf 1. The main difference is that instead of having every single object run in parallel with all the rest, they are divided into groups which share a single message queue and execution stack. So messages within a group are sequential. A very poor and short description can be found in http://www.merlintec.com:8080/Software/Parallelism

The main issue is "what is an object't state?" Just the bits in its slots? The bits in the slots of object it points to? The bits in the parents? We don't want the state to become inconsistent, so we must avoid concurrent changes to that state.

Microlingua seems to have combined ideas from Slate and TinySelf to solve the problem in a way very similar to what Eiffel (from where I originally borrowed the idea) did: http://www.whysmalltalk.com/Smalltalk_Solutions/ss2003/pdf/rabb.pdf

Here you lock the receiver and all the arguments before executing a method. I don't think that is enough -

  mySubObj counter: mySubObj counter + 1.

Since mySubObj is not the receiver nor an argument, it is not locked. Or actually, it is locked for "mySubObj counter", then unlocked and later locked again for "mySubObj counter:". Another object might point to it and be executing this code at the same time.

A drastic solution is to forbid sharing mySubObj, which is what Eiffel did. You had active objects and passive objects. The active ones were generally the roots of object trees, while the passive ones were the rest. A proper program must avoid having a passive objected pointed to by more than one active object. That is hard to enforce.

I hope my solution works better, but haven't really given it much thought yet since my focus has been on the 16 bit project. But it is still an ugly hack and I would love to see a better idea. It should be enough to keep half a dozen processors busy, however.

-- Jecel

Yahoo! Groups Links

Yahoo! Groups Links

-- Brian T. Rice LOGOS Research and Development http://tunes.org/~water/