[Ecls-list] Major changes (help wanted)

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sat Jan 3 09:17:32 UTC 2009

On Sat, Jan 3, 2009 at 2:13 AM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
> If ECL supports user defined encodings, would it be useful to
> allow their specification in more functional way: user provides
> functions like octets-to-string for reading,
> strings-to-octets for writing.

There are problems with every approach. Defining Gray streams is out
of question, for two reasons. First, they are slower than native
streams. Second, it falls out of the specification: they do not behave
as file streams in many aspects, and OPEN must return a file stream. I
would like external formats to be something kind of simple and fast
that is provided by the implementation.

Providing functions instead of a mapping made of association lists is
another possibility. The problem is that this function must make a
conversion from bytes to Unicode and viceversa. I have been
researching this option for many encodings, such as the Japanese ones,
but I found no systematics in the mapping between the JIS codesets and
Unicode. Hence, it seemed to me that the function would still need to
have the "dictionary" in place, which is what flexi-streams suggested
to me.

In any case, I can easily extend the current code so that
1) There exists a new function ext:read-octect.
2) The decoding may be done via a supplied function that uses
ext:read-octet and outputs a sequence
3) The encoding may be done via another function that returns a
sequence for a given character.

But please check the current code to see whether it suits your needs.
Since I am not very proficient on these tasks, I may have not
implemented it 100% correct, but I think it fits most everybody's


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)

More information about the ecl-devel mailing list