'read' can occur strictly before interpreting any of S-expressions, and reading in incorrect encoding can
cause an I/O error so you may not have a chance to interpret those forms.
Technically the encoding info should be a metadata of a file, not in the content of the file, so the "coding" comment
is certainly a kluge.  What I thought is that it might be useful to codify the current practice.

BTW, the "magic encoding comment" is supported in a few languages:

Python: https://www.python.org/dev/peps/pep-0263/
Ruby: https://idiosyncratic-ruby.com/26-file-encoding-magic.html





On Sun, May 12, 2019 at 1:50 AM Lassi Kortela <xxxxxx@lassi.io> wrote:
> have problems that do not occur with comment parsing (e.g. when using
> non-ASCII-superset multi-byte encodings such as UTF-16 or Shift-JIS)?

I had that wrong -- from skimming Wikipedia, Shift JIS, EUC-* and Big5
are almost strictly ASCII-compatible in the 0..127 range (trail bytes
that can overlap ASCII characters are almost the only exception).

Would it be problematic to read the first S-expression from a Shift JIS
/ EUC-* / Big5 coded source file assuming that it's (extended) ASCII?
Then if that form is something like:

     (declare-file
       (coding "Shift_JIS")
       ...possibly other declarations here...)

The file would be read again as Shift_JIS?