On Mon, Mar 24, 2014 at 10:00 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
Hi Eliot,

Le 20 mars 2014 � 17:04, Eliot Miranda a �crit :

On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
Hi Eliot,

Le 19 mars 2014 � 16:25, Eliot Miranda a �crit :

Hi�Christophe,

On Mar 19, 2014, at 1:45 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:


Le 18 mars 2014 � 19:50, Eliot Miranda a �crit :

On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
Why arguments should be read only?
They are just temporary variables with an initial value.

Read the blue book. �It was a decision of the language designers to forbid assignment to arguments to allow debugging. �The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. �It is an anachronism and should be forbidden also.

Thank you for the explanation.
I'm just curious why it is so difficult to implement a debugger if arguments are assignable?
If you need to restart the execution of a method, and so you need to get the initial value of the argument, I understand you cannot find the value anymore in the method context but it is available in the caller context, no?
As I never implemented a debugger, I cannot figure out the difficulties.

the args are no longer available; they get moved from the caller context to the callee. �If you think about stack frames then what happens is that the slots containing the outgoing arguments are used as the slots for the�incoming arguments. �So if arguments are assigned to they are indeed lost.

ok, I understand. Thank you for the explanation.


But look at how many methods in the system (or in any system). �The proportion of methods/functions/procedures that could be written to assign their arguments is very small so the Smalltalk trade off is a good one.

I agree we don't really loose something. You can always assign arguments to temporary variables and update temporary variables. My point was just: if possible, why don't do it?

It's that tricky trade-off between value and cost. �Is it worth it? �Does doing it provide as much value as doing what it displaces (opportunity cost). �IMO it simply doesn't provide enough value, and there are different priorities in the compiler. �But if you disagree implement it your self and then it'll be done.

It looks like "My point was just: if possible, why don't do it?" was misunderstood.
I wanted to say: if available for free (no work needed, why forbid it?). You gave a very good reason and I also think that the cost does not worth the value. :)

Agreed. �Good discussion.

--
best,
Eliot