luajit-ffi

[Alex Rønne Petersen]

On 01-05-2012 17:50, so wrote:
> On Tuesday, 1 May 2012 at 15:32:40 UTC, Alex Rønne Petersen wrote:
>> On 01-05-2012 17:24, so wrote:
>>> http://luajit.org/ext_ffi.html
>>> https://github.com/malkia/ufo
>>>
>>> How awesome is Mike Pall?
>>> I didn't dive into details of the code, but if he can do this with a
>>> dynamic language, why on earth D still need manual C bindings while
>>> having ABI compatibility? So luajit comes with a C compiler?
>>
>> Parsing a C header is relatively easy; don't need a full compiler for
>> that. It's what htod does. I don't know what you mean by "manual
>> bindings", but keep in mind that:
>>
>> 1) We *don't* want to embed some kind of crazy C syntax in D.
>> 2) In D, we want statically bound C function calls. Lua is a dynamic
>> language.
>
> It has nothing to do with syntax, D already can call C functions directly,
> and have all the structures.

What are you talking about? The link you posted clearly shows that 
LuaJIT has a C parser built in. It has everything to do with syntax 
(note that FFI is not anything spectacular or innovative; see libffi, 
Mono, Lisp, ...). And no, D does not "have all the structures". If it 
did, we wouldn't be redefining them in D bindings.

>
>> 3) LuaJIT will have the same problems as htod: Preprocessor definitions.
>
> We can just support enum and simple alias capabilities of C PP and most
> if not all the popular C libraries would be in D arsenal. I haven't seen
> many serious C APIs that exploit PP more than these simple tasks.

What does enum have to do with the C preprocessor? Anyway, it's not that 
simple. Any arbitrary symbol can have multiple definitions depending on 
what path you take in the preprocessor forest.

-- 
- Alex