Yes this is the question and the effort to be different.
I always thought this constraint was because of an optimization
in early days such as been able to depop without taking care.

Stef

On Dec 24, 2008, at 10:58 AM, <[email protected]> 
<[email protected] 
 > wrote:

> Stéphane Ducasse writes:
>> In that case we could change that. But then we would produce
>> incompatible code
>> also.
>
> Compatibility is less of an issue for this change as Pharo will accept
> more code rather than less. It will not stop us importing any code
> that currently runs on Squeak unlike enforcing lower case letters for
> instance variable names.
>
> It may be necessary to copy modified arguments with some optimised
> closure implementations but that shouldn't add much complexity. The
> current BlockContext implementation copies all it's arguments into the
> surrounding MethodContext.
>
> I think Eliot's closure implementation treats modified variables
> different to read only variables. However, to do this it needs
> to do the analysis to find which variables are read only in a block
> and which can be written to so even in this case writable arguments
> will add little implementation complexity and nothing in the VM/JIT.
>
> This is a language design point. Is the convenience of knowing that
> an argument is never modified worth more than the convenience of being
> able to modify the argument?
>
> Bryce
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to