On 26/ago/2005, at 23:06, Rayiner Hashem wrote:
What are the ramifications of the anonymous type stuff? In particular, does this mean that defctype behaves more like C's "typedef" (in that the source type doesn't yet need to be defined)?
Hmm, I was going to say no. But actually that'll work for DEFINE-FOREIGN-TYPE.
CFFI> (define-foreign-type foo () 'bar) FOO CFFI> (defctype bar :boolean) BAR CFFI> (translate-from-c 0 (parse-type 'foo)) NIL CFFI> (translate-from-c 666 (parse-type 'foo)) T
That won't work for types defined with DEFCTYPE because of some (premature?) optimizations though:
? (defctype foo unexistant-type)
Error in process listener(1): Unknown CFFI type: UNEXISTANT-TYPE.
This has nothing to do with anonymous types anyway.
Could any of the new type system changes achieve that result? The dependence of defctype on having its source type already defined makes handling automatic declaration generation quite complicated in a lot of idiomatic C code.
Use DEFINE-FOREIGN-TYPE instead of DEFCTYPE then, I'll remember to keep that feature when I refactor this stuff.
Since the dependence graph of C type definitions might have cycles, it becomes impossible to impose a total ordering on definitions. This isn't a problem when typedefs are fully resolved to their target types (as Verrazano does currently), but is a problem if you want the C-FFI binding to more closely resemble the C header file with regards to type naming.
Heh, I'm glad I helped then. My previous version of this type system didn't do that, but I noticed that it wouldn't always behave correctly because types defined with DEFINE-FOREIGN-TYPE can eventually resolve to different types depending on, say, its arguments.
(define-foreign-type type-picker (type-number) (case type-number (1 :int) (2 :float)))
(now this was a crappy example... Kenny I'll try to come up with better examples for the manual, heh. I'll probably search real life examples.)