Hello!
"Michael Gran" <spk...@yahoo.com> writes:
> commit 4d9dfb466ad6fdc9bd42ae7ed5a47dcedec5981a
> Author: Michael Gran <spk...@yahoo.com>
> Date: Tue May 26 08:56:06 2009 -0700
>
> move reader encoding parameters to fluids
>
> * libguile/ports.c: only use accessors functions for
> reader encoding parameters
> * libguile/strings.c: move scm_i_port_encoding and
> scm_i_conversion_strategy into fluids, and make
> accessor functions for the new fluid variables.
> * libguile/strings.h: remove macro SCM_PORT_ENCODING
> * libguile/posix.c: only use accessor functions for
> reader encoding parameters
Besides the broken indentation, this log doesn't correspond to a GNU
change log. It should mention all the changes that have been made
(variables added, removed, etc.), not why changes have been made (info
"(standards) Change Logs"). It really helps when looking for a specific
change.
> +const char *
> +scm_i_get_port_encoding ()
> +{
> + SCM encoding;
> + if (!scm_port_encoding_init)
> + return NULL;
> + else if (!scm_is_fluid (SCM_VARIABLE_REF (scm_port_encoding)))
> + return NULL;
> + else
> + {
> + encoding = scm_fluid_ref (SCM_VARIABLE_REF (scm_port_encoding));
> + if (!scm_is_string (encoding))
> + return NULL;
> + else
> + return scm_i_string_chars (encoding);
> + }
> +}
My understanding was that you were initially willing to attach encoding
parameter to individual port objects. I know I did mention fluids, but
now that I see it, I think that having encoding info attached to
individual ports would be more logical (sorry if I caused confusion).
Concretely, that would mean adding an `encoding' field to `scm_t_port'.
What do you think?
Just to be clear: I think that this proposal is an arrangement to keep
the current port API intact while still allow it to be Unicode-capable.
In the long run, I think the R6RS port API, where transcoders (not
ports) encapsulate encoding settings, is superior.
Thanks,
Ludo'.
