# Is a transliteration tool enough to grant count as SBCS?

Prompted by this. I'll speak about Dyalog APL here, but this could really apply to any language.

### Background

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.

• I think so. It's not different from running JavaScript through Babel. Babel doesn't make it a different language, it's still JavaScript; the APL transpiler is the same. – Pavel Dec 6 '17 at 0:35
• Discussion about this post is going on at chat.stackexchange.com/rooms/69777/… – Pavel Dec 6 '17 at 1:03

## Yes, it is valid

Consider C. In order to run a C program, it is first passed through a compiler (like gcc or clang), then a linker (like ld or gold), and then the resulting executable is run. We have no problem with this (but we require the compiler to be specified, since different compilers implement the language differently, and thus by our rules they implement different languages).

Thus, passing a SBCS-encoded program through a decoder, and passing that output to the actual compiler/interpreter/whatever, is also valid. It's simply another compilation step.

## However...

Use of such a transliteration needs to be clearly mentioned in any answers, to distinguish them from answers which do not make use of the tool. The tool plus the compiler/interpreter/whatever form a different language by our rules (since the implementation defines the language), and so such answers need to be clearly distinguished.

One would not argue that Japt is not a programming language. One would also not argue that it is the same language as JavaScript (despite transpiling to JavaScript before being executed). The same logic applies for any transliteration tool.

• What's to stop me from saying I have a program in Py-lz that is "encoded" in lz level 9? – NoOneIsHere Dec 7 '17 at 20:09
• @NoOneIsHere Nothing at all. But don’t expect such an unimaginative solution to be received well by the community. It’s not much different than using Bubblegum. – user45941 Dec 7 '17 at 22:37
• Where is the rule that "we require the compiler to be specified"? I've certainly seen that done sometimes, but it doesn't seem to be a rule that is enforced. – James Holderness Dec 7 '17 at 23:20
• @JamesHolderness The rule isn’t enforced as much as it should, but because each compiler implements a different language, the compiler should be specified. We usually either assume a common default or don’t worry about it if the code works in multiple implementations. – user45941 Dec 8 '17 at 0:08
• But there's no meta post or anything like that? It's just an unwritten convention? – James Holderness Dec 8 '17 at 0:57
• @JamesHolderness codegolf.meta.stackexchange.com/a/7833/45941 - since the implementation defines the language, it’s common sense that you need to specify the implementation used. – user45941 Dec 8 '17 at 0:58
• @NoOneIsHere And it probably won't beat solutions written in languages designed to be short, either. Human intelligence » computer intelligence... – user202729 Dec 9 '17 at 9:51