[gambit-list] Character encoding and the repl

Atticus atticus0 at posteo.org
Sat May 30 04:45:58 EDT 2015


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

Would be really convenient but I can also put the configuration into my
gambcini file.

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

I dont know if I understand that correctly. I assumed we are discussing
this change:

with t8 or f8, before:
(write "ü") -> "\374"
(read port) -> "ü"

with t8 or f8 after change:
(write "ü") -> "ü"
(read port) -> "ü"

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

Exactness and correctness > nice features, agreed. But I don't
understand whats not exact or not correct about the proposed change. It
seems to be just different. I'm quite inexperienced so it's possible that
I underestimate the implications of the change.

Also it's not that important or a priority for me, and as you said,
I can easily change the readtable-max-unescaped-char-set so I have nice
looking utf-8 character when reading non-english data into the repl. So
no problem for me :)

It would be interesting to hear more opinions on that matter.


Adam <adam.mlmb at gmail.com> writes:

> 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
> want.



More information about the Gambit-list mailing list