From Esolang
Jump to navigation Jump to search

The first person to make an interpreter wins! --TehZ 21:46, 9 May 2011 (UTC)

To win what? --Zzo38 00:02, 10 May 2011 (UTC)
CAKE! --TehZ 11:41, 11 May 2011 (UTC)
Watch out! The cake is a lie! — Timwi 14:01, 15 May 2011 (UTC)
No, because according to the previously mentioned required test protocol, we are no longer allowed to lie to you. --TehZ 18:49, 16 May 2011 (UTC)

It does seem it can be executed. To me it seems it is possible to execute, even though it cannot be parsed without execution. I think there are also other programming languages that mix the parser with the interpreter, although this is one without subroutines. Others that require mixing parser with interpreter includes TeX and Forth, both of which requires parsing as it is reading and executing, you cannot parse everything ahead of time because some things might change during that time, although both have modes that are not reading from the input file, so it does sometimes parse before executing, so maybe it doesn't count. But perhaps it might be true that Unparseable cannot be compiled. --Zzo38 00:02, 10 May 2011 (UTC)

Define compiling. You could easily package the interpreter with the source and call that compiling. But yeah, it cannot be parsed without execution. --TehZ 06:45, 10 May 2011 (UTC)

I was looking at making an interpreter for this, but the spec is unclear on some things, and may even contradict itself. For instance, it's clear from the examples that &| executes at compile/parse/preprocess-time (before the program even starts running). I assume that / is supposed to execute at compile/parse/preprocess-time from that point onwards (otherwise (/( would run the / once, flip the (s to )s, then either fail to loop back to the start as there was no longer a matching (, or loop back to the start then hit the / again, making the program a syntax error). However, the spec seems very confused as to what = does. For instance, is (=A)A valid (and an infinite loop), or a paradox, or a syntax error? In order to even enter the loop, the loop needs to be matched, but the definition that completes the loop is actually inside the loop, so the loop needs to be entered before it can be seen as a loop. And yet, the spec says it's valid, and yet the spec also says that = can be executed multiple times inside a loop. In short, I suspect this language is uninterpretable unless the spec becomes a lot clearer on what the semantics/syntactics are. --ais523 12:31, 12 May 2011 (UTC)

I think you misunderstood loops. They are basically nested jump points, so you can enter an unmatched loop, but it will have to become matched before the loop is exited. So () is a no-op, and it's matched. (/( is also matched, because it enters the loop, then it flips the parens and successfully exits the loop. Also, a = doesn't always do the same thing, even if it's parameters are the same, because it uses state. --TehZ 14:11, 12 May 2011 (UTC)
But with (/(, why would it exit the loop? The whole point of loops is that they loop, so it'd go back and run the / command again, wouldn't it? The whole point of a loop is to run the commands inside it repeatedly. --ais523 15:27, 12 May 2011 (UTC)
There are special commands for re-running a loop. --TehZ 18:02, 12 May 2011 (UTC)
It seems to me that TehZ is using the word loop in a confusing way. It seems to me that (...) and [...] are not loops by themselves; they are merely scopes or labels or similar, and only the use of @ and/or ", which causes the interpreter to “jump backwards”, actually makes it a loop in the traditional sense. Am I right? — Timwi 14:08, 15 May 2011 (UTC)
Yes, you are right. --TehZ 18:48, 16 May 2011 (UTC)
Perl uses the term "block" for this. --Ørjan 19:47, 16 May 2011 (UTC)

I'm having a hard time understanding how & | and ' function, but the rest of your ideas are generally equivalent to what I've done with Fit and even closer to Staq (in terms of program flow) - Madk 19:48, 27 June 2011 (UTC)

This language is specifically designed to be hard to parse.--TehZ 12:50, 28 June 2011 (UTC)
I'm confident I could pull it off without much difficulty given I knew better what those commands are meant to do, the reason being I've implemented essentially identical features in my own languages, though for sake of uniqueness rather than just being hard to parse. If you check my page you'll find I'm quite used to self-modifying code and odd syntax, the only thing I don't like is multi-character commands (though that's not to say I can't handle them, I just prefer not to and am of the opinion that it defeats a lot of the esoteric-ness of a language.) - Madk 00:37, 29 June 2011 (UTC)
An example of the & and | commands might help: +&>| is interpreted as >+, not +>. That's what makes it hard to parse.--TehZ 14:57, 29 June 2011 (UTC)
Are you saying that the only purpose of &| is to give a portion of code higher priority than anything outside? If so, that doesn't seem to make much sense from a coding standpoint; why not just put down >+ in the first place? - Madk 15:43, 29 June 2011 (UTC)
This language is not supposed to make sense. The first priority was a language that was hard to parse. The second was Turing-completeness. --TehZ 16:03, 29 June 2011 (UTC)
Esolangs that derive their "strangeness" from mere syntactic unfamiliarity are fairly boring (unless this unfamiliarity affects the semantics of the language), IMHO. If making a language use multiple-character commands would render it mundane, perhaps it was not esoteric at all. With regards to the language in the article, unless I'm missing something, it is very obviously parseable. —ehird 00:48, 29 June 2011 (UTC)
Try! Remember the & and |. --TehZ 16:03, 29 June 2011 (UTC)

I don't understand something.

The program corectness depends on the input, but the algorithm of checking it doesn't as I see. Examples:

The following can be incorrect with interactive I/O:
If the user writes in the same as he or she read out:
 if it is a ' ',
  the "+" will be added to the beginning and it outputted "!"
 if it is a "!",
  the "+" will never be added to the beginning and it outputted ' '
 That is a paradox, and the program is read backwards:
 This is an incorrect program.

Also, the operators making { and } brainfuck loops don't actually do this because the loop contents will be always executed at least once and even can be executed infinitive number of times:

+>[++<[->-<]++>] -> ={(=}'?#@)'+>{++<{->-<}++>}

I suggest ={'(?#'=}'@)' instead. Orisphera (talk) 08:33, 19 September 2018 (UTC)