On Monday 10 November 2003 11:52 am, Eric Merritt wrote:
> I am a big erlang fan an thought I would chime in.

>  Multi-threading is easy because no process has direct
> access to another processes state. You can only send
> messages to and receive messages from a process. Those
> messages get queued up in a mailbox and are processed
> one by one. This gets rid of things like semaphores,
> mutexs, etc that makes multiprocess programing in the
> mainstream world so difficult.

This is easy to do in Squeak, too. Shared state can be avoided, though you'd 
be using semaphores internally (in the queues). But the programmer would not 
see them.

>   Pattern matching just rocks. I think it simplifies
> quite allot of things. Unfortunately I dont really see
> how it could work in an OO language.

There is a paper in the recent OOPSLA proceedings about a pattern-matching 
version of Java. This could be done easily in Squeak as well.

http://www.cs.washington.edu/research/projects/cecil/www/pubs/hydroj.html

>  Just to close up, I would love to see squeak adopt
> some things from erlang. Following is a list.
>
>  1) Erlang style message passing.
>   This could probably be implemented in Squeak right
> now without any problems. What you wouldn't get is the
> message processing via pattern matching. You also
> couldn't make sure that you only processed messages
> coming from the local mailbox.

Why not? If you subclass ProtoObject for the (publicly visible) message 
receivers and make it impossible to get to the actual active objects you've 
done about the same thing.

>  2) Cheap preemptive multi-threading.
>    From what I understand from previous discussions on
> this list, this would be a major undertaking requiring
> big changes to the VM and massive refactoring of
> existing code. That being the case I don't see this
> happening anytime soon.

What do you mean? We *have* cheap preemptive multi-threading in Squeak.
Am I missing something?

>  3) Transparent non-blocking IO.
>   All IO in erlang is non-blocking (this may not be
> the case for linked in drivers). Basically this is
> completely transparent to the erlang programmer. The
> system takes care of starting and stooping a process
> that can't read or write data. I know so little about
> the Squeak IO system that I can't really comment on
> the relevance of this to Squeak.

I don't understand. If you stop a process that can't read data, you've blocked 
it. How is this "non-blocking"?

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE