2
\$\begingroup\$

Currently, Jelly has a code page that maps Unicode characters to bytes to avoid unprintables found in ASCII. Many of the characters used are multiple bytes (in UTF-8), but we score it as a single byte (as it represents a single byte).

Now, lets assume I write another "code page" that takes common language features in Python (or any other language), and maps them to shorter byte values.

For example, I could map print to 0x00, meaning that every print statement is now 1 byte. I do make the assumption that my python program doesn't have the null character in it, but I'm OK with that.

If you feel that the above is invalid because Python doesn't support my custom code page, then what if I make a custom language that is identical to Python, except that it uses my custom code page?

TL;DR: If I write a general purpose encoding for a language, can I still answer in the original language, and score it based on the encoding?

\$\endgroup\$
5
  • 2
    \$\begingroup\$ I'd say yes as long as an interpreter exists that uses that encoding, but at that point I think we'd consider it a different language. \$\endgroup\$
    – Alex A.
    Mar 17, 2016 at 16:50
  • 9
    \$\begingroup\$ Also note that "languages" which simply map X to Y in another language are boring and typically attract downvotes. Why use a trivial substitution variant of Python when you can just... use Python? Sure, it might make your answer shorter, but for me, seeing a Python answer that beats Ruby and Perl is far more impressive than a slightly shorter answer in some obscure substitution dialect that doesn't have anything to compare to or compete with. \$\endgroup\$
    – Doorknob
    Mar 17, 2016 at 17:10
  • 3
    \$\begingroup\$ the worst thing about those custom code pages is that the symbols used usually make no sense compared to the functionality performed by the underlying operator. \$\endgroup\$
    – Fatalize
    Mar 17, 2016 at 17:20
  • 1
    \$\begingroup\$ @Fatalize I feel like that doesn't do Jelly justice. I get the impression that the code page was very much chosen with somewhat reasonable mnemonics in mind (under Dennis's self-imposed and also very reasonable constraint that all characters must be typeable with a US International keyboard layout). The alternative would have been to use something like ISO 8859-1 where a large part of the code would simply have been unprintable. Using a custom code page doesn't improve golfability at all. It's only done to improve readability. \$\endgroup\$
    – Martin Ender
    Mar 17, 2016 at 20:12
  • 2
    \$\begingroup\$ Nit pick about the question: Jelly doesn't map Unicode characters to ASCII characters, it maps Unicode characters to byte values (or the other way round). Whether those characters require multiple bytes in UTF-8 seems completely irrelevant. They're just arbitrary code points. \$\endgroup\$
    – Martin Ender
    Mar 17, 2016 at 20:13

1 Answer 1

Reset to default
12
\$\begingroup\$

No, it's not the same language.

...If I write a general purpose encoding for a language, can I still answer in the original language, and score it based on the encoding?

No. You've made an essentially different language/dialect, adding a new command \x00 which prints something, removes (presumably) print, and is otherwise identical to Python. It's not Python, is it? I argue it's not. You can't answer therefore in Python, but, rather, whatever your dialect may be called.

You still can count the bytes normally, but, as has been said, it's just not Python.

(As for the title of your question, we can take encodings as far as is possible. Use ALL the bytes!)

\$\endgroup\$
14
  • \$\begingroup\$ So, in essence, I could just write my language in Python0, which looks exactly like Python 2, but has a shorter byte count (and different interpreter). \$\endgroup\$
    – Nathan Merrill
    Mar 17, 2016 at 17:24
  • \$\begingroup\$ @NathanMerrill Precisely. \$\endgroup\$
    – Conor O'Brien
    Mar 17, 2016 at 17:24
  • \$\begingroup\$ @NathanMerrill Just note that it would not be worth using. Just golf with Python. It's more readable, and golfs are more impressive. \$\endgroup\$
    – mbomb007
    Mar 17, 2016 at 18:24
  • \$\begingroup\$ @mbomb007 It would be just as readable as python, as it literally would have the same characters as python. \$\endgroup\$
    – Nathan Merrill
    Mar 17, 2016 at 18:37
  • \$\begingroup\$ @NathanMerrill You suggested using \x00 though >_> \$\endgroup\$
    – Conor O'Brien
    Mar 17, 2016 at 19:07
  • \$\begingroup\$ I'm not sure you guys understand. My interpreter would use a code map to convert print into \x00, and then \x00 back into print. Its similar to how Jelly converts ¡ into \x00, and then executes it. \$\endgroup\$
    – Nathan Merrill
    Mar 17, 2016 at 19:10
  • \$\begingroup\$ Then I say forbid it. A code map should be a one-too-one mapping between bytes. It shouldn't map multiple bytes to a single byte and back. That only makes the scoring and reading needlessly difficult. \$\endgroup\$
    – mbomb007
    Mar 17, 2016 at 19:34
  • \$\begingroup\$ @mbomb007 but then we forbid Jelly, which takes multiple bytes in UTF-8 to represent a single byte. \$\endgroup\$
    – Nathan Merrill
    Mar 17, 2016 at 20:16
  • 8
    \$\begingroup\$ @NathanMerrill I think there's a misunderstanding here about what an encoding is. Source code is just a byte stream. While you're used to the byte with value 33 to be displayed as !, that's a fairly arbitrary convention. You can display that byte however you like. The interpreter just reads a byte stream and doesn't even have to know about which glyphs each byte corresponds to. It's just that it can be cumbersome to tell your text editor to use that custom encoding. That's why I assume that TIO will do some UTF-16 (or -8)-to-custom encoding conversion for you. \$\endgroup\$
    – Martin Ender
    Mar 17, 2016 at 20:18
  • \$\begingroup\$ @MartinBüttner The Jelly interpreter takes a stream of UTF-8 characters (meaning multiple bytes of data), and maps them to a single byte. I understand that the resulting "byte" isn't a character. Then the Jelly interpreter then executes the code based on the byte value. Am I correct in my understanding? \$\endgroup\$
    – Nathan Merrill
    Mar 17, 2016 at 20:22
  • 3
    \$\begingroup\$ @NathanMerrill I'm pretty sure the Jelly interpreter could also read the file encoded directly in its own code page. The fact that it also supports UTF-8 is merely for convenience, but doesn't mean you couldn't feed it a file of the claimed size instead. \$\endgroup\$
    – Martin Ender
    Mar 17, 2016 at 20:23
  • \$\begingroup\$ Therefore, if input was in my custom encoding, my interpreter would need to accept 0x00, but if it was in UTF-8, then it could accept U+0070,0072,0069,006E,0074 (print in UTF-8) as a "convenience" feature. Therefore, I could write "print" instead of the null byte, and have it conveniently work. \$\endgroup\$
    – Nathan Merrill
    Mar 17, 2016 at 20:40
  • 4
    \$\begingroup\$ @NathanMerrill Sure you could. But that's just saying that there exists a long form and a short form of your language, much like Vitsy (I think it's Vitsy) also has a long form that isn't used for counting but helpful for explaining. \$\endgroup\$
    – Martin Ender
    Mar 17, 2016 at 21:39
  • \$\begingroup\$ @NathanMerrill TLDR, if you're going to create another language, just start fresh, rather than mapping X to Y from an existing language. \$\endgroup\$
    – mbomb007
    Mar 18, 2016 at 20:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .