[self-interest] Merlin and Self

[Brian Rice]

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/