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.dema...@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.dema...@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?

Christophe.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to