On 10/24/07, Igor Stasenko <siguctua at gmail.com> wrote:
>
> This having a perspective, only if you have unlimited memory resources
> and zero cost memory allocation.

I don't understand.

> Lets look more precise on this. I will write only in ST(i don't know
> Erlang), and assuming that i understood well your concept , by having
> following ST code:
>
> SomeClass>>setVars
> self setVar1: value1.
> self setVar2: value2.
> ...
> ^ self
>
> here at each message send , instead of writing to receiver memory, we
> do copy-on-write cloning.

No, this is exactly what we *do not* do.  As I have mentioned several
times, I want message passing to be explicit.  I had hoped the Erlang
code would be clear, since it wasn't here is the same thing again in
proposed Smalltalk code:

SomeProcess>>run   "arbitrary name, doesn't have to be run or anything
like that"
  self breakupStructureWith: 10000.
  self buildNewStrucureFrom: 10000.
  ^ structure

SomeProcess>>breakupStructureWith: aProcessCount
  |rest|
  rest := structure.

  1 to: aProcessCount do: [
    rest := splitAndSend: rest ].

SomeProcess>>buildNewStructureFrom: aProcessCount
  1 to: aProcessCount do: [ |data|
    data := self process receive.
    self addDataToStructure: data.

Ok.  Not optimal code in either case, but this Smalltalk code is the
equivalent of what the Erlang code above did.  Note that in ST I'm not
passing the structure around or doing recursion because in ST I can
modify variables.  Also Note that in the Erlang example and this
example the actual send was not shown.  The function (split_and_send
and splitAndSend respectively) were not shown because I didn't want to
write a bunch of code breaking up some imaginary structure.

These are all just normal message sends.  The only interprocess stuff
is the unshown send (I had planned to use the binary message #!) and
the receive method.

> So, each time we modifying object we got a modified copy instead
> modifying original.

Why?  Inside a given process I don't see a reason to disallow regular
mutability.