the situation:
some projects out in the wild use DEFCENUM with e.g. :DOUBLE base-type. this is not in adherence with the C standard (only integer types are valid enum types, and it's at least int sized). my refactoring of enums introduced an explicit check for this, and it broke some projects in ql. to alleviate that i've commented out this new check in master.
the question:
should we roll with this? does anyone see any problems or potentially surprising behavior? e.g. with the semantics of the enum increments and the double base type? or something else?
On Wed, Feb 24, 2016 at 7:29 PM, Attila Lendvai attila@lendvai.name wrote:
some projects out in the wild use DEFCENUM with e.g. :DOUBLE base-type. this is not in adherence with the C standard (only integer types are valid enum types, and it's at least int sized). my refactoring of enums introduced an explicit check for this, and it broke some projects in ql. to alleviate that i've commented out this new check in master.
the question:
should we roll with this? does anyone see any problems or potentially surprising behavior? e.g. with the semantics of the enum increments and the double base type? or something else?
It sounds a bit silly at first, but from CFFI's point of view, a DEFCENUM is really just a mapping between symbols and... something else.
What would we gain from being a bit more draconian about the base type?
On Wed, 2016-02-24 at 19:35 +0000, Luís Oliveira wrote:
On Wed, Feb 24, 2016 at 7:29 PM, Attila Lendvai attila@lendvai.name wrote:
some projects out in the wild use DEFCENUM with e.g. :DOUBLE base-type. this is not in adherence with the C standard (only integer types are valid enum types, and it's at least int sized). my refactoring of enums introduced an explicit check for this, and it broke some projects in ql. to alleviate that i've commented out this new check in master.
the question:
should we roll with this? does anyone see any problems or potentially surprising behavior? e.g. with the semantics of the enum increments and the double base type? or something else?
It sounds a bit silly at first, but from CFFI's point of view, a DEFCENUM is really just a mapping between symbols and... something else.
What would we gain from being a bit more draconian about the base type?
We gain being standards-compliant. A C enum is an int, period.
What would we gain from being a bit more draconian about the base type?
We gain being standards-compliant. A C enum is an int, period.
i kinda agree.
but on the other hand:
it's pretty useful where i've seen it in the wild, in cl-glu: there are a bunch of #define's with increasing values, and a function that accepts those values, but in a double typed argument. with a relaxed defcenum, or equivalent, one can continue using the automatic keyword-symbol->value mapping.
maybe add another, more relaxed costruct? a cffi:defenum?
but on the other hand is the added complexity worth it? is a use-case like this frequent enough to warrant it?
this all more or less boils down to the following fundamental question: should CFFI try to mirror the C standard on the lisp side? or should it be more permissive where the cost of being permissive is low (e.g. in introducing latent bugs or other programmer surprises)?
What would we gain from being a bit more draconian about the base type?
We gain being standards-compliant. A C enum is an int, period.
i kinda agree.
but on the other hand:
it's pretty useful where i've seen it in the wild, in cl-glu: there are a bunch of #define's with increasing values, and a function that accepts those values, but in a double typed argument. with a relaxed defcenum, or equivalent, one can continue using the automatic keyword-symbol->value mapping.
maybe add another, more relaxed costruct? a cffi:defenum?
but on the other hand is the added complexity worth it? is a use-case like this frequent enough to warrant it?
this all more or less boils down to the following fundamental question: should CFFI try to mirror the C standard on the lisp side? or should it be more permissive where the cost of being permissive is low (e.g. in introducing latent bugs or other programmer surprises)?
CFFI should implement the C standard, and anybody who wants additional semantics can implement them. It's not like Lisp is insufficiently expressive for those who need it. The number of users who will be confused by slightly different semantics will be much more than those who actually have an use for enums backed by doubles, or similar extensions. We've already made a big mistake with DEFBITFIELD being what it is now.
-
Attila Lendvai -
Luís Oliveira -
Stelian Ionescu