ncellier at ifrance.com wrote:
>> 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.
> 
> I wanted to speak of standardization of these present and future pragmas extensions which are apparently existing but still not that stable as i understood this thread...

The syntax for FFI specs[*] has been stable since their inception. The 
FFI is now available for some six years (pretty much exactly so I think 
- the first version was in 2.8 IIRC which was released in 2000) and it 
hasn't changed since. I think this qualifies for "stable" ;-)

[*] I dislike using the term pragma as being a gross mischaracterization 
of what primitives and FFI specs are. Pragmas, as most of the 
definitions agree (see http://www.google.com/search?q=define%3A+pragma) 
refer to "non-code" information, i.e., information that does not 
directly produce compiler output. This is not true for both primitives 
and FFI specs both of which result in direct compiler output which 
really means they are plain old source code, not pragmas (the fact that 
you can add fallbacks for failing primitives really doesn't change that).

> Of course, I should have spoken of language design (goal) rather than Compiler's (implementation).
> But this confusion was intentional, cause my feeling is that simplicity can also be a goal per se, especially if software is to evolve.

Simplicity in the language or its implementation? ;-) Regardless, I 
agree both is true. However, incompatible changes in syntax come at a 
high cost which is why they are usually coupled with some very tangible 
benefits. I have yet to find a language that would break syntax 
compatibility in a widely deployed part merely for the argument of ... 
well what exactly? Making it simpler? I didn't think that was the claim 
as the change isn't really simplifying anything. Neither for the user 
(who has more to type) nor for the system (since the same code is parsed 
twice; once by the pragma parser, and the second time by the FFI 
parser). This doesn't exactly qualify as "simpler" now, does it?

> You perfectly know that historical design and backward compatibility will lead you through bypaths and indirect crooked ways... And maintainability dead ends might well prevent you to meet the crown. We have enough external constraints so as to avoid super imposing our own made. Just my experience and it's worth 2p.

Part of what I'm fighting here is this attitude of "well, really the 
ONLY way to deal with problem X is to completely break it and require 
everyone to start over". I nearly lost it when I read the original 
proposal - such a disrespect for the amount of work that people put into 
getting this (hard!) stuff working is simply unbelievable.

> But that's just generalities, and your solution indeed sounds a good way for resolving FFI modularity, regarding Compiler's interaction. How compatible is it with Lukas' ideas ? That is the question.

Quite bluntly, I think this only depends on how desperately Lukas wants 
to change the FFI syntax. If that's the goal, the proposal will be 
unacceptable (and consequently so will be any other and we'll stall). 
Anything else can be worked out.

Cheers,
   - Andreas