Prompted by this. I'll speak about Dyalog APL here, but this could really apply to any language.
Dyalog APL has its own SBCS called
⎕AV. For backwards compatibility reasons Dyalog Ltd. is reluctant to change the character set. Lately, six new built-ins have been added to Dyalog APL and have been assigned the symbols
⍸ for mnemonic reasons, however these characters are not in
⎕AV. At the same time,
⎕AV contains 14 characters
§ which are neither built-ins, valid identifier characters, or ASCII, nor are they used when pretty printing structures. They are therefore highly unlikely to appear in Dyalog APL programs.
It has been accepted that
the only thing that matters is there must be an actual file with the claimed byte count that, when fed to your interpreter, runs the intended program. How you interpret the bytes (or bits) in that file as characters is entirely up to you, as is whether you internally or externally provide conversion methods between the unreadable binary file and the readable ASCII-only interpretation of the file.
Let's say I provide a tool which packs a UTF-8 source file into a file using a SBCS more appropriately chosen than
⎕AV, and can also unpack such files. Does this grant me the right to count Dyalog APL as one byte per character even when using the problematic six characters? Or would this constitute a "new language" and my posts using this would have to actually display the (unreadable) bytes?
Does it matter that the user has to take a few simple steps to "compile" his (unreadable) "source"?
Would it help if I modified TIO's Dyalog APL wrapper so that it can actually run such files given an appropriate flag — even though it would in fact always run in "UTF-8 mode" when using the tio.run interface?
Speaking against this being acceptable is that then any code golf submission could just be zipped (being the wide availability of unzippers).
Speaking for this being acceptable is that while Jelly has a wrapper which can translate Jelly-encoded files to UTF-8 before running, TIO actually always uses the UTF-8 mode, as the Jelly source says:
This option should be considered the default, but it exists solely for scoring purposes in code golf contests.