Talk:SendStuff

Hello, World!

Hmmm... interesting.

>(Add 72 >(Output)             #H 
>(Add 29 >(Output)             #e
>(Add 7  >(Output)             #l 
         >(Output)             #l
>(Add 3  >(Output)             #o
>(Sub 67 >(Output)             #,
>(Sub 12 >(Output)             # 
>(Add 55 >(Output)             #W
>(Add 24 >(Output)             #o
>(Add 3  >(Output)             #r
>(Sub 6  >(Output)             #l
>(Sub 8  >(Output)             #d
>(Sub 67 >(Output))))))))))))) #!

Am I correct?

--Seven Inch Bread 18:18, 19 November 2007 (UTC)

Yes, that will work. The specification I posted does not allow abbreviating Subtract to Sub, but some interpreter might be madde that does allow that, and if it does, then it will work. --Zzo38 19:43, 22 November 2007 (UTC)

I'd personally prefer +, -, *, /, and mod for the math operators. Mainly because of laziness but also because of aesthetics. --Seven Inch Bread 19:56, 22 November 2007 (UTC)

Concurrency

What would happen in a program like this:

>start(
         >(Add 1 >start) 
         >(Add 2 >start) 
         >(Add 3 >start)
       )

...where all of the child nodes begin a recursive loop. Does the interpreter handle child nodes concurrently or in linear order? --Seven Inch Bread 18:26, 19 November 2007 (UTC)

There is no interpreter (yet), but how it is supposed to work is the Add 2 and Add 3 commands are never get a chance to execute because the Add 1 sends the result to start and since the number can be any size, it will just continue in a infinite loop unbounded and will waste too much memory because it is expecting it to do the next commands, Add 2 and Add 3 commands, so it will keep it in memory that it is supposed to go back there and continue the next command (for each iteration of start --> Add 1 --> start, etc, but it never will. --Zzo38 19:41, 22 November 2007 (UTC)

turing-completeness

In order to be turing-complete, we need to be able to effect conditional behavior. I can see nothing allowing for conditional behavior in the language, and thus, I believe this to be not turing-complete. However, it may be possible that just adding an SNZ (send parameter if input is non-zero) and an SZ (send parameter if input is zero) operation would make it turing-complete. --(this comment by Quintopia at 03:45, 31 March 2009 UTC; please sign your comments with ~~~~)

Um several of the commands don't send anything on certain conditions. E.g.:

• Subtract: Subtract its parameter to received number and send the result. If result is negative, it send nothing.

It seems to me that one might build SNZ and SZ from those with a little arithmetic. --Ørjan 17:44, 31 March 2009 (UTC)

Hmm, I didn't see that. However, it's still not clear how one would build conditional sending on top of conditional failure to send. You need a node that sends whenever it does not receive something, right?--Quintopia 05:25, 1 April 2009 (UTC)

Hm, I didn't look very carefully at the language. I don't think sending when not receiving is essential for TC. More seriously to me the parameters are constants; it seems that there is no way for a node to depend on more than one received value at a time, neither with gradually collected nor with synchronized values. So you essentially have numbers propagating from node to node without interacting with each other. That also makes it hard to do any complicated arithmetic munging of stuff, I think. Maybe that's still enough for emulating the one register variation of a Minsky machine, though. --Ørjan 00:09, 2 April 2009 (UTC)

Now I made Extended SendStuff, which can have infinite numbers of nodes, and also a few other commands. --Zzo38 16:37, 16 August 2009 (UTC)

A possibility to create SNZ and SZ could be:

@SNZ(>(Subtract 1 >(Add 1 %)))
@SZ(>(Minus %))

--Zzo38 16:37, 16 August 2009 (UTC)