[M3devel] UI, Trestle, native... Cocoa??

[Darko]

The only specification there is is the headers. The reference manual is a collection of annotated headers, much like M3's library documentation. Why introduce an intermediate representation? The APIs are usually quite straight forward and use a very limited subset of C, namely constant, type and function declarations which can readily be parsed. More problematic things like elaborate macros are seldom used and often can be taken literally instead of being evaluated properly. The trickiest things to parse are function pointer declarations, and there are usually so few of those that you can do them manually.

I don't understand where the payoff is in doing anything else when there is no way of reliably automating it and making it output something clean, putting you back to square one and having to hack anyway. A hacked parser of a C subset is the most direct and reliable route I think. I already have a little "programmable" parser which is half way there. It understands expressions with function call syntax and lets you define infix, postfix, prefix and groupfix (eg "{ ... }") operators with precedence. With a couple of extensions I think I can make the headers look like a series of simple declaration expressions. Throw in an exception mechanism which lets you insert hand made expressions when you encounter specific symbols and it's done (plus generating the M3 interfaces, of course).


On 29/09/2010, at 12:50 AM, Mika Nystrom wrote:

> Darko writes:
> ...
>> Several APIs I've done are by hand using several regular expression =
>> search and replaces. Automating it is relatively easy because it doesn't =
>> have to be completely general, it only has to parse the header files you =
>> are targeting, not every C syntactic construct, which would be a very =
>> bad trip. When I did the Mac Carbon APIs I had a file of exceptions =
>> which handled the "too hard basket" of declarations. Trying to use the =
>> more powerful tools just means you have a steep learning curve and you =
>> end up with something  messy and unpredictable which you have to hack =
>> anyway.
> ...
> 
> My advice would be not to parse C at all.  Just translate the reference manual's
> specs into some specification language (I use Scheme or Modula-3 but you could
> use XML) and generate glue code in both C and Modula-3.  It's a lot saner...
> you can use your regex translation machine the first time of course, but then
> maintain the linkage in a language that actually specifies things properly.
> 
>      Mika