[gambit-list] Character encoding and the repl

Adam adam.mlmb at gmail.com
Sat May 30 03:19:52 EDT 2015

What could maybe be something, would be to add another -: option to Gambit,
that instructs Gambit to use a
non-default(non-127) readtable-max-unescaped-char-set setting.

Like, -:eN  (e as in "escape" and "N" as in "nothing", meaning #\U0010ffff).

This would make the escaping behavior you seem to be hinting at, more
easily accessible (i.e. more easy to get going than to need to include the
whole script you printed out before in an -e ... - argument).

2015-05-30 12:13 GMT+05:30 Atticus <atticus0 at posteo.org>:

> > Should the external representation of strings depend on the character
> encoding of the output port?  In other words, if the character encoding of
> the byte output port is
> >
> > - ASCII then characters whose code are >= 128 would use escapes like \374
> > - ISO-8859-1 then characters whose code are >= 256 would use escapes
> > - UCS-2 then characters whose code are >= 65536 would use escapes
> > - in all other cases escapes would not be used because all Unicode
> characters can be encoded
> Imho yes. But to be clear, let's say the external representation of
> scheme strings depends now on the character encoding of the output port
> and I have the above explained situation, I have an utf-8 port and need
> to print to ASCII only, then I can still do that by changing the output

Atticus, you're forgetting that the "external representation" discussed
here regards only the escaping applied in the serialization of objects.

This is a really sensitive thing where exactitude and correctness in any
real use must have priority over extra nice features.

The character encoding of the output and input port here is the same, and
setting Gambit in -:f8 to be able to read UTF-8 encoded sourcecode files,
and -:t8 to be able to input unicode chars directly in the REPL, is
generally a good thing -

And there's no reason that that would somehow be related to that escaping
behavior would change.

Again, the direct output is always done unescaped:

gsi -:t8
(print "\374\n")

If you want unescaped object output occasionally only, you could implement
your own write/pp routine with readtable-max-unescaped-char-set set as you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20150530/ab2e0cbd/attachment.htm>

More information about the Gambit-list mailing list