> I liked the early gcc response to #pragma.  The spec stated that a
> compiler could do whatever it wanted when it saw a #pragma, so gcc tried
> to run a variety of games and threw a segmentation fault if it failed to
> find any of them.
>
>                 - Peter

Yes, early, but then they added their own __attribute__...

> Which is precisely the reason why I originally called them "annotations"
> instead of pragmas.
>
> Cheers,
>    - Andreas

As everybody, I dislike pragmas for they are compiler dependent, not part of 
the language definition itself, and lead to portability problems
(already upset by structure alignment in {} and its damn pragmas).

Inside squeak, portability is not a problem, you can change the compiler, and 
you can make this change a prereq when loading into another image.

Problems will raise when you want to move outside Squeak.
But in this case, Squeakers will also get problems with the {a. b. c.} 
extension, Dolphiners with the ##() extension etc...

So, at inter-dialect level, pragmas, annotations or whatever syntax extension 
will lead to portability problem, because they are not standard.
The difference between #annotations and #pragmas might not be so thick from a 
pragmatic point of view...

------------------------------------------------------------------------
The facts:
Without byte code optimization, Smalltalk would not be efficient at all.
Byte code optimization makes Smalltalk not as extensible as it should be.
This problem exists in other Smalltalks.

The solutions:
- Nobody likes the pragma. OK.
- Lukas does not like blocks evaluated once and only once. OK.
- Bryce and Peter suggested unoptimizing only #and/#or:, and that is the 
simpler solution by now. In a 3.8 image just :

MessageNode>>transformAnd: encoder
    ^false
MessageNode>>transformOr: encoder
    ^false

Maybe the not optimized and: won't break performance noticeably... worth 
trying...

A work around to get both optimized and notoptimized code on a class basis is 
this one (mostly 3 classes and 4 messages):
- declare  compilerClass ^NotOptimizedAndOrCompiler as class method where you 
intend to use your fuzzy logic and: extension...
- NotOptimizedAndOrCompiler will arrange to use NotOptimizedAndOrParser
- NotOptimizedAndOrParser will use NotOptimizedAndOrMessageNode
- NotOptimizedAndOrMessageNode will only redefine above transformAnd: 
transformOr: methods
- maybe have to change a few more refs of MessageNode... (turning isMemberOf: 
into isKindOf: and other things like that)

> The clean solution is to dynamically inline message sends so the
> simple unoptimised version of and: is as fast as the optimised
> version. A system with dynamicly inlined messages would be much
> faster for other things as well.
>
> Bryce

Waouh. At the VM level ? That one is far above my skills...
Isn't it the kind of optimization in VW VM ?
My understanding of efficiency problem when not open-bytecoding #and: is the 
creation of BlockContext.
Inlining send you gain creation of a MethodContext but not of a  BlockContext.
But if you also gain speed elsewhere, that's surely better...

Nicolas