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