Talk:Oozlybub and Murphy

Infinite loops

Couldn't you just make the following dynasts:

  dynast(2) <-> write 49
  dynast(3) <-> create/countably/many/dynasts 2, 5

You now have an infinite number of copies of dynast 2, effectively creating an infinite loop. You could break out of it by doing

create/countably/many/dynasts 2, 5

a second time, as that would end the program. Or have I misunderstood something? --Marinus 15:43, 1 December 2010 (UTC)

From the description of create/countably/many/dynasts: "The new labels are the odd integers starting at the first odd integer greater than the second i-expr." It doesn't create any dynasts labeled with even integers. Since dynasts are executed with successively higher integer labels, you need some of those, or you'll halt. Maybe the sentence "If there is a dynast labelled with the next higher integer, execution continues with that dynast" is a bit ambiguous -- I meant the next higher integer in Z, not the next higher integer in the set of labels of dynasts in the program :) --Chris Pressey 16:43, 1 December 2010 (UTC)

Alternatively, couldn't you just create an even number by adding together four primes? Nothing in the syntax seems to prevent that. --ais523 16:36, 1 December 2010 (UTC)

From the description of copy/dynast: "The new label is the sum of the two p-exprs". There isn't any way to create a label which is the sum of four primes, unless you manually sum two pairs of primes, check that those results are prime, and pass those as the two arguments to copy/dynast. In which case, you are still summing two primes. --Chris Pressey 16:43, 1 December 2010 (UTC)

Use of variable names

As far as I can tell, the regular expressions are never used for matching anything. My idea is adding a new variable type called m which is meta-programming type. The commands for writing more program by meta can write streams including pragmas and a string in quotation marks will select all variables that names matching this string. --Zzo38 06:29, 4 December 2010 (UTC)

Each variable is identified by a set of strings (and one of these strings must be "infinitely" long). A regular expression is used to match a particular set of strings, and thus identify a particular variable. (Because many regular expressions can match the same set of strings, I'm considering adding the requirement in version 2.0 that, outside wimpmode, no regular expression may appear more than once in a program text.)

I'm also considering adding quotation marks, but basically only to complicate the matter of recognizing the parse stream manipulation pragmas. I don't know what to make of your suggestion for meta-programming yet; I'm concerned about any features that might be powerful enough to make Turing-completeness independent of Goldbach's conjecture. --Chris Pressey 18:39, 4 December 2010 (UTC)

Error in the specification?

Your spec says:

c-expr then expr
Evaluates the expr on the left-hand side for its side-effects only, throwing away the result, 
then evaluates to the result of evaluating the right-hand side expr.

but the infinite-loop example you give on that same page does this:

if? not? exists/dynast 5 then
       create/countably/many/dynasts #myself#, 5

It seems to rely on then only evaluating expr if c-expr evaluates to go. Otherwise, your "loop" would only run once. --Marinus 16:53, 4 December 2010 (UTC)

Indeed, that's an error, thanks for catching it. In fact then is supposed to be a short-circuiting and, (and I'm not sure why and is still in the spec), and the above could should read then do. See, that's why it's more correctful to implement these things instead of just specifying them! FWIW, I'm thinking of writing up Oozlybub and Murphy version 2.0 soon, in which I'll clarify these behaviours and make large chunks of the existing functionality a wimpmode. --Chris Pressey 18:01, 4 December 2010 (UTC)

...and an even more egregious error is present in the sentence "Each dynast is labeled with a positive even integer and contains an expression." In fact dynasts can be labeled with any positive integer, and the rest of the document assumes this. I'll be releasing version 1.1 of the language soon, which will address these two issues. --Chris Pressey 19:03, 27 April 2011 (UTC)

(Very Important) Question about the Murphy Part

The language spec states that "The fact that the language is not entirely named Oozlybub is named Murphy". In my mind, this leads to an egregious ambiguity. What if a language was named "Fingblat and Murphy"? Would "Murphy" mean that "Fingblat and Murphy" is not entirely named Oozlybub - which is just nonsense? Or is Murphy a more general designator meaning that "Foo and Murphy" is not entirely named Foo for all values of Foo? --Nthern 17:54, 12 July 2011 (UTC)

Yes. --Ørjan 20:02, 12 July 2011 (UTC)

Interpreter

I (semi-)finished an interpreter I've been working on off and on for a while when I had time. The parser is really slow and inefficient but apart from that it should work. Here's a cat program I used to test it:

VARIABLES ARE a /e*/.

{@+} {@>}
dynast(1) <-> /e*|e/ [minus 1] := minus 1

{@+} {@>}
dynast(2) <-> /e*|ee/ [0] := minus 1

{@+} {@>}
VARIABLES ARE p /p*/, p /q*/, i /c*/.
dynast(3) <->
  do (. if? not? exists/dynast 5 ,then
           create/countably/many/dynasts #myself#, 5 .)  ,then
  
  do (. for each prime /p*|p/ below #myself#+2 do
           for each prime /q*|q/ below /p*|pp/+1 do
               if? not? exists/dynast  /p*|p|p/ + /q*|q|q/ ,then
                  copy/dynast #myself#, /p*|ppp/, /q*|qqq/ .) ,then 
     
  do /c*|c/ := #read# ,then 
  do (. /e*|e|e/ ? /c*|cc/ ,then 
         create/countably/many/dynasts 1, 1 .) ,then 
  write /c*|c|c/

--Marinus (talk) 22:44, 18 December 2013 (UTC)