On Feb 14, 2010, at 6:37 AM, Igor Stasenko wrote:
On 12 February 2010 15:09, Lukas Renggli <renggli@gmail.com> wrote:
It is interesting to note that of course, after this was added to 3.9, there was someone *very hard* arguing that adding Pragmas was a very dumb idea...
Who that person was is left as an exercise to the reader of course ;-)
Hint: FFI has its own proprietary hardcoded pragma format. It unnecessary complicates the compiler even when not loaded. Not to mention that it breaks all tools that have their own parser, such as RB for example.
I'd like to discuss, what changes to compiler we may introduce to allow FFI to handle pragmas in non-intrusive manner.
Very simple: FFI just needs to use the pragmas as introduces in 3.9, than remove all knowledge about FFI from the Compiler. Problem solved. Isn't that beautiful? < cdecl: void 'InvalRect' ( MacRect ) module: 'InterfaceLib'> of that would be changed so that the stuff inside the <> would be a standard Smalltalk Message expression, problem solved. to illustrate... using the SMaCC grammar of the NewCompiler (a bit simplified) as extendend for Pragmas, Primitives and FFI by Mathiue Suen. A method in Squeak has Pragmas: Method: | MethodPattern Temporaries Pragmas Statements {#methodTempsPragma:}; So they are difined like this (we can have multiple ones): Pragmas: "<" PragmaMessage ">" {#pragma:} | Pragmas "<" PragmaMessage ">" {#pragmas:} So it's quite simple: there is one message expression inside... simple. But there is FFI. Primitives are there, too, but that's not really a problem: they fit in the Pragmas. primitive: 15 is a valid message in Smalltalk. (Math did the gramar for primitives to have nice error messages, but that's not needed) PragmaMessage: Apicall {#messagePragma:} | Primitive {#messagePragma:} | MessagePragma {#messagePragma:}; How Primitive and MessagePragma are done is not important. But we need Gramar rules just to be able to parse FFI: Apicall: TypeCall ExternalType IndexName "(" ParameterApicall <rightParentheses> {#externalCall:} | TypeCall ExternalType IndexName "(" ParameterApicall <rightParentheses> "module:" <string> {#externalModuleCall:}; IndexName: <string> {#externalFunction:} | <number> {#externalIndex:}; TypeCall: "apicall:" {#callConvention:} | "cdecl:" {#callConvention:}; ParameterApicall: ExternalType {#parameterExtCall:} | ParameterApicall ExternalType {#parametersExtCall:}; ExternalType: <name> {#externalType:} | <name> "*" {#externalTypePointer:}; And this is *always* in the Grammar. Even when FFI is not loaded! (a nice example where our simple notion of modularity brakes down completely). No the solution here is simple: a small trivial modification to FFI to use the Evil Pragmas as introduced by the Dumb People (tm) in 3.9: < cdecl: 'void InvalRect ( MacRect )' module: 'InterfaceLib'> or *whatever*. just something that is a valid Smalltalk message expression... can't be hard, can it? Ah. And and about "notion of modularity"... of course the problem "how can I extend the language from my package without having to spread code over the parser, compiler, debugger, browser..." is intellectually an interesting one. And, oh, we are payed for finding these kind of Problems and especially solving these Problems in a way that goes beyond of just doing a pragmatic and simple solution (aka what I described here). (They call it "Academic Research". Involves mostly a programming language called TeX and can be very boring at times but it's complementary to the practical world... in a very interesting way). And int his context the result is, of course, tataaa....: Lukas' Helvetia: http://scg.unibe.ch/research/helvetia/languageboxes See? So *everything* fits together... research and non-research, problems and solutions (on multiple levels), progress in the small and the large! Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.