On Sat, Oct 3, 2009 at 6:09 PM, Christophe Rhodes <csr21@...> wrote:
> Since I have your attention, can I draw your attention to commit
> 65367ef26f08132ea6d8e2eb4c3ebbca0ca21bd2, and in particular the diff
> around WRAP-EXTERNAL-FORMAT-FUNCTIONS; I've taken your nice
> external-format structure with its sane protections, removed all those
> protections, and fiddled about with the insides. Would there be a
> better way? (In particular, I lose the interned nature of external
> formats by doing this).
FWIW, I wasn't concerned about the internability of things; my concern
with the restructuring was to make it equally efficient to use any
name for the external format and to save space. I don't think there's
a good way to accomplish what you want to do and not duplicate the
external-format structure along the way. (Returning the functions as
multiple values was the only way that occurred to me, but it's rather
I do think there are some lurking bugs in that patch. For instance,
if you use an invalid external-format name like (:FOO :REPLACEMENT
#\Space), GET-EXTERNAL-FORMAT now dies a horrible death.
> The next step in my path is to teach each external format about a
> sensible default replacement character, and then to make the streams
> opened for the terminal (and stdin/stdout/stderr) to use a
> replacing external-format rather than a harsh one, so that you don't get
> into the state of wedging your system because there's something on some
> stream that is illegal for the external format. The octets code will
> need to be taught about this :replacement external-format too.
I approve of this design goal.
My eventual plan with separating things out like I did was to make it
easier for the external formats to be autoloaded from disk when
necessary. We have a lot of external formats and du estimates
obj/from-xc/src/code/external-formats at 4.5MB on my x86-64 machine.
Pulling (most of) that out of the default core image would save ~10%
of core space, which I think is a worthwhile thing to do.
(Autoloading more things from disk is also a worthwhile goal, but
doing the external formats is much easier, since the functions
involved are never referenced directly.)