From: Anton K. <an...@sw...> - 2011-08-11 18:16:32
|
Gabriel Dos Reis <gd...@in...> writes: > I've put a temporary workaround for the code that generates the MAP > with %String, but we use other deftypes in many other object creation > contexts and now I am bit nervous about SBCL's interpretation. It > would be great if something can be done about this from the SBCL side. I was suspecting exactly this use case, but I was unsure whether you go beyond object creation -- TYPEP, SUBTYPEP, function type declarations and the like. When the prevailing (or the only) use of deftypes is object creation, there /is/ a perfectly portable solution: let your DEFTYPE expand to (VECTOR CHARACTER), not to a string. Such types are /required/ to work in a conforming implementation (for any vector element type) -- and this requirement is much more clear than the remark about 'STRING specifiers. The problem with 'STRING is that it's /realy/ a hairy type. It's not an unicode-aware sibling of 'BASE-STRING (that would be (VECTOR CHARACTER) -- exactly what you need). 'STRING is about something that has /doubts/ whether it wants to be unicode-aware or ascii-only. Using it for object creation doesn't have any natural, obvious semantics: imagine that you're talking to malloc(), asking it to "please, allocate 4096 bytes of memory -- or 2048, i'm not sure yet". We can't even express it for C and malloc(); but the straightforward meaning of (MAP 'STRING ...) is very much like this! > My expectation is based on the fact that a deftype is just an abbreviation, and > in many (all?) other contexts where I use a deftype as a type specifier, it > expands to its body. It may be useful to read the RECURSIVE-DEFTYPE issue writeup (just follow the link from CLHS page on DEFTYPE). There was a /discussion/ whether non-terminating recursive type definition should be allowed. (it's a useful thing to have, not some remote theoretical construct: (DEFTYPE LIST-WITH-ELTS-OF-TYPE (INSIDE) `(CONS ,INSIDE (LIST-WITH-ELTS-OF-TYPE ,INSIDE)))). If expanding DEFTYPE fully were the only way for Lisp implementors, there would be no such discussion (btw, I seem to recall that recursive deftypes were actually supported by some /pre-Common/ Lisp). (And if it /were/ the only conceivable way, I would expect to find something like DEFTYPE-EXPAND it the standard: if the cost of full expansion were inevitable, why not reap the benefits of it?). -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia |