ncellier at ifrance.com wrote:
> Andreas and Lukas, sorry to put words in your mouth once again, but that's my understanding:
> 
> Lukas: make framework simpler, more uniform, and more easily maintanable in the future.
> This is a maintainer of Compiler and pragmas point of view.
> 
> Andreas: protect investment and avoid frequent swaps when no value added.
> This is the FFI user (and maintainer) point of view.
> 
> Both arguments seems receivable to me.

Right. And, as I've just shown, they are not necessarily in conflict - 
my last proposal (or possibly a variation thereof) addresses both.

> Simplifying implementation is something worth because without it, 
> Squeak will evolve slower and slower, and future maintainers who 
 > don't know the whole history won't understand the complexity and
 > will probably break things sooner or later.

While true, it might also be helpful to take some actual measures of the 
complexity in question. In this case we're talking about two methods 
(count 'em) with 50 lines of code in them. From my point of view it's 
ridiculous to break all FFI code in existence to "simplify" 2 methods 
with 50 loc.

> My feeling is that the Compiler maintainers should decide whether 
> or not the implementation should change, but in this case, it is
 > also their responsibility to provide a backward compatibility for
 > FFI users.

On that one I disagree. In a system with an existing and accepted 
syntax, a compiler writer cannot just make up new syntax or change 
existing one to simplify the implementation. Otherwise it would be 
equally reasonable for one compiler writer to drop assignment from the 
parser to simplify it and for the next one to drop cascades for the same 
reason. Syntax changes have to be defined and agreed on elsewhere.

> Couldn't we follow such procedures when making the code evolve in
 > uncompatible manner ?

Absolutely. If there were agreement that breaking the FFI syntax is 
valuable. That's the point I'm debating.

Cheers,
   - Andreas