FFI syntax (was: Re: [Vm-dev] Re: testing MT and reentrant)

Colin Putney colin at wiresong.com
Fri Mar 25 18:03:33 UTC 2011


Looks like a bit of interpretation is necessary here.

Lukas wrote:

>> I don't like it to have methods polluted with meaningless symbols
>> (that will also show up in senders/implementors).

Igor replied:

> That's exactly why i like it. Now i could use standard tools to figure
> out which FFI function using
> some fancy type(s).
> And that's exactly why i using symbols in primitive names:
>
> <primitive: #primName module: #moduleName>
>
> So, i can quickly access them. And it is _not_ meaningless. Its handy.

Igor is right, using named primitives make it easy to find out where
primitives are called, since they show up as senders. However,
consider Eliot's example from earlier in the thread:

#(int (struct { field : 8; fence : 8; gate: 16; } arg))

Here you get a lot more than the module name and the primitive name.
You also end up with a bunch of C keywords, identifiers and
punctuation in the symbol table:

#':'
#';'
#'{'
#'}'
#arg
#fence
#field
#gate
#int
#struct

That *is* pretty meaningless. You can get spurious senders of things
like #field and #gate, but at the same time, you can't easily search
for FFI calls that include 'struct { field : 8; fence : 8; gate: 16;
}' in them.

>> I doubt that the symbol hack will make parsing much simpler, because
>> you still need to analyze the token sequence.
>>
> Yes, that's what my class does.  It is reusing smalltalk parser as a tokenizer.

Lukas' point is that this hack doesn't actually buy us much. We get a
scanner for free, but that's the easy part. The hard part is
implementing the parser.

If the point of all this is to take advantage of the fact that Igor
has already done the hard work of implementing a parser for C
declarations, why not choose a cleaner syntax, write a scanner for it,
and adapt Igor's parser to fit?

I mean, we already have a quick-and-dirty syntax. It works fine. If
we're going to replace it, we'll have to maintain backward
compatibility during the transition period, deprecate the old syntax,
encourage/help people migrate to the new syntax etc. Do we really want
to do that for something that still doesn't get us proper C
declaration pragmas?

Colin


More information about the Vm-dev mailing list