Hello,
I just had another go at simplifying the type system. Here's an overview of what changed:
1 - (DEFCTYPE new-type base-type) becomes just a simple way of defining an alias. The user cannot define translations for new-type and there will be no translation overhead unless base-type already has translations. This removes the need for the :TRANSLATE-P optimization option.
2 - The new macro (DEFINE-FOREIGN-TYPE new-type supers slots &rest options) becomes the canonical way of defining complex types with translations. This is a thin wrapper around DEFCLASS.
2a - The new macro (DEFINE-PARSE-METHOD type-name lambda-list &body body) will be used to parse the type specifications (e.g. '(:string :encoding :utf-8)) and should return an instance of a subclass of FOREIGN-TYPE.
2b - Translator/expander methods should now specialize on type instead of using EQL specializers. So now the type specifications can easily take options through the above parse-method, save them in some slot (defined through DEFINE-FOREIGN-TYPE) and -- here's the big advantage -- the translators can have a look at those options and take appropriate action.
2c - For the simple case where the user wants to define a translation but doesn't need to parse options, DEFINE-FOREIGN-TYPE takes a (:SIMPLE-PARSER name) option that will automatically generate:
(define-parse-method name () (make-instance 'some-type))
3 - The translator generic functions no longer have that ad-hoc method combination. If the user wants to chain the translations of her type's superclasses then she should invoke CALL-NEXT-METHOD explicitly. I believe this method combination of ours was crippling inheritance. Compare the new :string+ptr type definition with the previous one for an example of what I mean.
A side-effect of these changes is that we no longer need two separate mechanisms for dealing with real types (instances of FOREIGN-TYPE) and user types (plain symbols). That translates into ~100 less lines of code.
Here's the patch: http://common-lisp.net/~loliveira/patches/more-foreign-types.diff This is heavily backwards incompatible wrt the type system interface so I'll wait and see if there any objections before I commit it.
Comments and suggestions are welcome, as usual.