Talk:Unparseable

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  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)