Now that Factor has first-class struct objects and a growing set of C library bindings, we're heading toward a situation where C type definitions might conflict between vocabularies. To head off this problem, I've changed it so that C types are identifiable by words in addition to by strings. This way, they're scoped to a vocabulary and conflicts can be managed with USING:, QUALIFIED:, and FROM: as with other words. The primitive types (int, char, void*, and so on) are defined in alien.c-types. TYPEDEF: and STRUCT: define C type words in the current vocabulary. FUNCTION:, TYPEDEF:, and STRUCT: will transparently look up C types as words instead of strings if possible, so code that only defines new typedefs, structs, and C function bindings shouldn't need to change. To make this change smooth, code that treats literal strings as C types will continue to work for now, but new code should use the words if possible.
One upshot of this change is that there are new potential ambiguities between the "alien.c-types:float" C type and the "math:float" class, and the "alien.c-types:short" C type and the "sequences:short" word. I'm planning to make some changes to mitigate this issue: - Words for allocating arrays of C objects (<c-object>, <c-array>, malloc-array, and so on) as well as utility words such as byte-length, c-bool>, etc. will move soon to an "alien.data" vocabulary, leaving "alien.c-types" containing only the primitive C types. This should eliminate references to alien.c-types in the vast majority of code that doesn't need the core C types. - I'm thinking about moving the number classes (integer, float, complex, etc.), which are currently all in the "math" vocabulary, into the appropriate subvocabularies of math. integer, bignum, and fixnum will live in "math.integers", float will live in "math.floats", complex will live in "math.complex", and ratio will live in "math.ratios" . Most code that uses the "math" vocabulary doesn't need to directly reference any of the number classes, so with this and the "alien.data" refactoring, the only time you should have a "float" word ambiguity is in the tiny set of cases in which you explicitly need both the float C type and the float Factor class. "short" isn't used terribly often as either a word or a C type, so I don't think it's much of a problem. Does anyone have any objection to the above changes? -Joe ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
