That's exactly what Lukas did propose.
This imply that syntax inside angle brackets follows Smalltalk Syntax (apart implied receiver). 
Unfortunately this is not the case for FFI nor eventual other extensions like andrews sql: or any other external language interfacing...
Unless the un-smalltalkish syntax is quoted... in a string for example <cdecl: 'int myFunc()'>

But that breaks FFI backward compatibility.
Eventually a backward compatibility package and automatical syntax transformer could solve the compatibility/transition problem... But i did not ear any echo in favour of it...

Angle brackets are so far used in Smalltalk
- for glue with internal vm (primitive:)
- for glue with external libraries (FFI, DLLCC ...)
- for adding meta-level information (not code, rather pragmas), like this is a menu, this is an exception handler, this method should be called when...

Maybe as future interfacing glue with other languages like andrews' sql:

While primitives and pragmas follows easily Smalltalk syntax, that is not the case of external glue.
So how to have both a generic parser for pragmas and a generic parser for external glue without quoting?

Andreas proposed a compiler client registering mechanism so as to solve FFI/Compiler unmodularity.
I have not understood yet how Andreas proposition does solve generic pragmas (with muliple keywords and without the need to register...)
Maybe there is a solution: first keyword is checked against registry. If not registered, Smalltalk syntax is assumed so as to enable generic unregistered pragmas...
But the registering stuff would be used only for FFI by now... Is it really worth ?

Nicolas


Jecel Assumpcao Jr a écrit :
> I haven't been keeping track of this discussion and haven't looked into
> the FFI/pragma/primitives issue at all (so feel free to ignore what
> follows), but I would like to make a small comment based on my
> experience in trying to simplify programming languages (Smalltalk in
> particular). One way to do things is to define a syntax to embed in the
> source messages to be sent to the compiler object itself. So something
> like
> 
> <primitive: 32> blah blue
> 
> would cause the expression between < > to be compiled separately and
> executed as if it were "thisCompiler primitive: 32". The compiler is
> free to do whatever it wants (this is the "object way") and then it can
> continuing parsing the rest of the text. Adding methods to Compiler will
> automatically extend what it can do without having to mess with the
> parser.
> 
> Some people would like for Smalltalk to be much more declarative (the
> bane of "doIts"!) and this proposal goes in the opposite direction. It
> actually has a Forth-like flavor to it. But if you want simplicity, this
> is one way to get it.
> 
> -- Jecel
> 
> 



________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com