Is a transliteration tool enough to grant count as SBCS?

12:28 AM

@Adám The fundamental difference is that the translation is part of the Jelly interpreter, while your wrapper is not. If there's a way to modify APLK0=utf8 APLT1=utf8 APLT2=utf8 to take a different encoding, that would be something else. I really think you should take this to meta.

Adám

0

Q: 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 a...

@Dennis AFAICT, the translation is in the wrapper, not in the interpreter.

Dennis

← 11 messages moved from talk.tryitonline.net

Pavel

@Adám If it's decided that this is valid, there should be a standard loophole to prevent people from DEFLATEing their code and claiming that as a transpiler.

Dennis

@Adám I consider all Python files in that repo "the interpreter". If Dyalog APL starts shipping with your transliteration tool, it would be the same situation. But once you need external tools to run the code, you have a different language. Imho, anyway.

Yes, it is. It just imports jelly.py, which could function as a library as well.

Pavel

@Dennis Does it really matter that it ships with Dyalog? Babel doesn't ship with your browser, but we still consider Babel'd code to be JavaScript.

Dennis

12:40 AM

You still have to mention Babel in the answer though.

Adám

@Dennis How is Dyalog APL then even a valid language at all, as it requires a bash wrapper to enable running on TIO?

Dennis

PPCG rules are completely independent of TIO. Dyalog APL doesn't need a wrapper on my desktop computer.

Adám

@Dennis So too can you type the symbols from my post into desktop APL and it will run just fine. The fact that I (can) store the code one way or another should not matter.

Pavel

inb4 counting Dyalog APL in keystrokes

Adám

@Pavel Another possibility is counting Dyalog in delta-⎕WA (Workspace Available). This is the actual space used during normal operation and will take advantage of tokenisation and data packing. E.g. there is a 600 byte difference between the function {(+/∨\' '≠⌽⍵)↑¨↓⍵} and the function {(+/⌈\' '≠⌽⍵)↑¨↓⍵}.

Pavel

12:50 AM

@Adám I can't see any difference...

Adám

@Pavel Better?

Pavel

Yes, but I have no idea how that makes a 600 byte difference.

Adám

And a list of 8000 twos takes 678% more space than a list of 8000 ones.

Pavel

Is that because of bit arrays?

Dennis

@Adám REPLs somehow blur the lines, yes.

Adám

12:52 AM

@Pavel Yes.

@Dennis And workspaces too. The traditional way to store APL code and data is in highly optimised binary files where identical data and code can be shared among multiple symbols.

In the REPL, as soon as I close the editor (or press Save), my program is tokenised, and even the non-SBCS built-ins are mapped to single-byte tokens (although we are getting close to running out of those). There is a secret way to access the tokenised code, but I'm not at liberty to reveal it.

Dennis

Too bad, because that would definitely count.

Pavel

Yeah, saying "Trust me guys this code can be compressed into 15 bytes I just can't tell you how" doesn't really work.

Anonymous

3:17 AM

IMO, allowing transliteration is something we already do, and thus should allow in this case. Every program written in a compiled language goes through a transliteration step before being executed. A tool that translates from a SBCS to another encoding before running the code is just a compiler for our purposes. It should probably be mentioned in the language header to distinguish those answers from "pure" answers, though.

Adám

8:02 AM

@Mego So can I write #APL (Dyalog Unicode), 15 SBCS bytes as my "compiler" is conveniently called "SBCS"? Or maybe #APL (Dyalog Unicode), 15 bytes* with a footnote saying * using SBCS?

Anonymous

The former would be clearer, but both would be acceptable IMO

Anonymous

It's just like how C and C++ submissions are supposed to indicate which compiler is used (though gcc is often implicitly assumed)

Adám

@Mego Playing Devil's advocate: But this also means that it would be valid to write Python 3, 123 bytes* footnote: * using 7-zip

Anonymous

Sure, but nothing in our current rules forbids that

Anonymous

It's not much different from using Bubblegum

Adám

8:16 AM

@Mego OK, one last Devil's Adv.: Right now, SBCS uses a fixed transliteration. Potentially, I could let the desired character set be a configuration option at "compile" time. This would mean that even challenges requiring up to about a hundred non-ASCII symbols would be solvable with Dyalog APL using a SBCS. OK?

Anonymous

IMO each configuration would be considered its own language as per this meta consensus

Adám

8:38 AM

@Mego … effectively turning "Dyalog APL (with SBCS)" into a MetaGolfscript familiy of languages.

Anonymous

@Adám Well sure, but that's why we have the loopholes post on meta - to keep things from getting too crazy

Anonymous

There's always going to be opportunities to abuse rules that aim to be inclusive. But we generally choose to close those loopholes one-by-one, rather than have a stricter set of rules that disallow languages/approaches that should be valid.

Transcript for

Is a transliteration tool enough to g…