Talk:Котята-арбузята

its proven two turing incomplete things can be complete IIRC, see Along and Across. cool concept tho! --Yayimhere2(school) (talk) 12:21, 11 August 2026 (UTC)

thx, didnt know about Along and Across at the time of making this esolang --Dragoneater67mobile (talk) 16:25, 11 August 2026 (UTC)

Please add single-file mode

Something like this:

( 72   | < 0 [
( 101  |   : *
( 108  |   : *
( 108  |   : *
( 111  |   : *
( 44   |   : *
( 32   |   : *
( 119  |   : *
( 111  |   : *
( 114  |   : *
( 108  |   : *
( 100  |   : *
( 33   |   : *
( 10   |   : *
' 0    |   : *
.      |   ,
       | ]

It would enable QUINE challenge. --Blashyrkh (talk) 14:21, 11 August 2026 (UTC)

Thanks. --Blashyrkh (talk) 22:21, 11 August 2026 (UTC)

Input EOF

What should be pushed/sent on input EOF? --Blashyrkh (talk) 15:47, 11 August 2026 (UTC)

0 --Dragoneater67mobile (talk) 16:18, 11 August 2026 (UTC)

Weird name

"Котята" is kittens (pl.) in Russian. The word "арбузята" may be translated as "small watermelons" but small not because of their size but because of being children. And both parts of the language name are plural. What does it mean at all? --Blashyrkh (talk) 18:43, 11 August 2026 (UTC)

it doesnt actually mean anything. i chose that name because it sounds cute and rhymes well --Dragoneater67mobile (talk) 19:03, 11 August 2026 (UTC)

The name is awesome. Singulars are "котёнок" and "арбузёнок" respectively, these might be used for single instructions of a program sections. --Blashyrkh (talk) 19:10, 11 August 2026 (UTC)

Posting signal if it's already being handled

Suppose the following situation: котята posts signal 0 to арбузята, арбузята's signal 0 handler starts to execute, but before it finishes execution котята posts another signal 0. What happens?

• A: the signal is ignored, posting it is NOP
• B: signal handling is postponed until current signal 0 execution finishes
• C: signal handler is restarted
• D: current арбузята's instruction pointer is saved (somewhere), execution of signal 0 handler starts from the beginning, when it's finished the saved value of арбузята's instruction pointer is restored.

--Blashyrkh (talk) 22:34, 11 August 2026 (UTC)

bee --Dragoneater67mobile (talk) 06:13, 12 August 2026 (UTC)

Are postponed signals counted or is postpone flag just a boolean? Same rule if another signal is posted (signal 0 is being executed, signal 1 arrives, execution is postponed until signal 0 handling is finished), right? And suppose that receiver's main body is being executed (not a signal handler), and signal comes. Is body execution interrupted, or the signal is postponed until the last body instruction is finished? --Blashyrkh (talk) 06:20, 12 August 2026 (UTC)

signal is postponed until body finishes execution --dragoneater67 contribs talk 06:41, 12 August 2026 (UTC)

So, both executors have associated signal queues. Posting a signal pushes a 8-bit code to the corresponding queue, and when executor is ready (finishes execution of main body or a signal handler), it takes a code from its queue and executes (step-by-step, in round-robin manner) the handler. Few questions to settle it down:

• When is it decided that un-registered signal is NOP? When the signal is posted (so, the code isn't put to the queue), or when the code is extracted from the queue by the receiver?
• Since the dynamics is essential, it's needed to be specified: do "extract code from the queue", "find handler", "execute the handler's first instruction" are done as a single atomic execution step or three steps (or maybe two)?

--Blashyrkh (talk) 06:57, 12 August 2026 (UTC)

• when the signal is posted
• its atomic

--dragoneater67 contribs talk 07:06, 12 August 2026 (UTC)

If signal handler is registered but it's empty, does its execution requires 1 scheduler step as well? Remember, I asked if "extract code from the queue", "find handler" and "execute the handler's first instruction" are executed as a single step? What if there's no handler's first instruction because the handler is empty? Still a single step? --Blashyrkh (talk) 22:05, 21 August 2026 (UTC)

empty signal handler takes up a single step --Dragoneater67mobile (talk) 08:06, 22 August 2026 (UTC)

XKCD Random Number - why to do it signal-driven?

Wouldn't it be simpler?

.
+
: 52
: 10
,

--Blashyrkh (talk) 09:24, 12 August 2026 (UTC)

sure, it could be simpler, but i wrote it that way because... why not? --dragoneater67 contribs talk 09:28, 12 August 2026 (UTC)

I just had to be sure that my version is valid as well. --Blashyrkh (talk) 09:29, 12 August 2026 (UTC)

Whitespace and linefeeds

Are whitespace and newlines an essential part of the syntax (like in Python), or they are just for readability purpose? --Blashyrkh (talk) 18:14, 12 August 2026 (UTC)

every token must be separated by whitespace or linefeeds --dragoneater67 contribs talk 08:12, 13 August 2026 (UTC)

Interpreter

https://gist.github.com/rs-blashyrkh/b124e2f2c7ccbf39e9b8a6ce8d59eb63

Few improvement proposals for the language specification:

1. Do not require whitespace to delimit tokens. All tokens are 1-character except numbers, and numbers never follow each other, so they don't require delimiting. Actually, my interpreter already ignores all whitespace.
2. Use # for comments. Replace already used # token with something else (say, ~).
3. Do not check whether signal handler is registered or not at the moment of sending a signal. Let the signal be queued anyway. If executor pops signal number for which there's no registered handler then it's NOOP. In any case the whole receiver's cycle is wasted on extraction of signal number from the signal queue and looking up for a handler.
4. Do not execute handler's first instruction in the same cycle as the signal number was popped from the queue. Do it on next cycle. It would make the behavior more consistent.

These are just proposals, they are not implemented in my interpreter (except the first one which doesn't break compatibility). Proposals 2-4 must be approved by the language author. --Blashyrkh (talk) 09:27, 22 August 2026 (UTC)

thanks, i applied some changes that make the behaviour more consistent --dragoneater67 talk contribs 09:15, 2 September 2026 (UTC)

QUINE

It requires an interpreter which ignores whitespace and supports "one file" mode.

}0[!33!5!49!5!39!5!48!5!93!5!125!5!53!5!91!5!33!5!50!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!51!5!33!5!50!5!39!5!48!5!93!5!125!5!51!5!51!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!49!5!33!5!50!5!33!5!53!5!49!5!39!5!48!5!93!5!125!5!51!5!53!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!49!5!33!5!50!5!33!5!53!5!51!5!39!5!48!5!93!5!125!5!51!5!55!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!49!5!33!5!50!5!33!5!53!5!53!5!39!5!48!5!93!5!125!5!51!5!57!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!49!5!33!5!50!5!33!5!53!5!55!5!39!5!48!5!93!5!125!5!52!5!51!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!50!5!33!5!50!5!33!5!53!5!49!5!39!5!48!5!93!5!125!5!52!5!52!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!50!5!33!5!50!5!33!5!53!5!50!5!39!5!48!5!93!5!125!5!52!5!54!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!50!5!33!5!50!5!33!5!53!5!52!5!39!5!48!5!93!5!125!5!52!5!56!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!50!5!33!5!50!5!33!5!53!5!54!5!39!5!48!5!93!5!125!5!52!5!57!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!50!5!33!5!50!5!33!5!53!5!55!5!39!5!48!5!93!5!125!5!53!5!48!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!51!5!33!5!50!5!33!5!52!5!56!5!39!5!48!5!93!5!125!5!53!5!49!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!51!5!33!5!50!5!33!5!52!5!57!5!39!5!48!5!93!5!125!5!53!5!50!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!51!5!33!5!50!5!33!5!53!5!48!5!39!5!48!5!93!5!125!5!53!5!51!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!51!5!33!5!50!5!33!5!53!5!49!5!39!5!48!5!93!5!125!5!53!5!52!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!51!5!33!5!50!5!33!5!53!5!50!5!39!5!48!5!93!5!125!5!53!5!53!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!51!5!33!5!50!5!33!5!53!5!51!5!39!5!48!5!93!5!125!5!53!5!54!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!51!5!33!5!50!5!33!5!53!5!52!5!39!5!48!5!93!5!125!5!53!5!55!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!51!5!33!5!50!5!33!5!53!5!53!5!39!5!48!5!93!5!125!5!53!5!56!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!51!5!33!5!50!5!33!5!53!5!54!5!39!5!48!5!93!5!125!5!54!5!48!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!52!5!33!5!50!5!33!5!52!5!56!5!39!5!48!5!93!5!125!5!54!5!51!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!52!5!33!5!50!5!33!5!53!5!49!5!39!5!48!5!93!5!125!5!57!5!49!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!55!5!33!5!50!5!33!5!52!5!57!5!39!5!48!5!93!5!125!5!57!5!51!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!55!5!33!5!50!5!33!5!53!5!49!5!39!5!48!5!93!5!125!5!57!5!52!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!53!5!55!5!33!5!50!5!33!5!53!5!50!5!39!5!48!5!93!5!125!5!49!5!50!5!53!5!91!5!33!5!51!5!51!5!33!5!50!5!33!5!52!5!57!5!33!5!50!5!33!5!53!5!48!5!33!5!50!5!33!5!53!5!51!5!39!5!48!5!93!5!125!5!49!5!91!5!39!5!49!5!93!5!125!5!50!5!91!5!33!5!49!5!125!5!49!5!91!5!125!5!53!5!91!5!33!5!50!5!125!5!53!5!91!5!39!5!49!5!93!5!125!5!50!5!91!5!39!5!52!5!46!5!93!5!39!5!49!5!93!5!125!5!49!5!91!5!39!5!48!5!93!5!39!5!51!5!93!5!125!5!50!5!91!5!39!5!50!5!93!5!39!5!50!5!93!5!43!5!60!5!48!5!91!5!94!5!37!5!93!5!60!5!49!5!91!5!94!5!63!5!93!5!60!5!50!5!91!5!58!5!35!5!94!5!37!5!93!5!60!5!51!5!91!5!60!5!48!5!91!5!94!5!63!5!93!5!60!5!49!5!91!5!58!5!35!5!94!5!37!5!93!5!94!5!48!5!93!5!60!5!52!5!91!5!44!5!93!5!58!5!49!5!50!5!53!5!58!5!52!5!56!5!58!5!57!5!49!5!94!5!48!5!1'0]}5[!2!33!2!53!2'0]}33[!33!2!51!2!51'0]}35[!33!2!51!2!53'0]}37[!33!2!51!2!55'0]}39[!33!2!51!2!57'0]}43[!33!2!52!2!51'0]}44[!33!2!52!2!52'0]}46[!33!2!52!2!54'0]}48[!33!2!52!2!56'0]}49[!33!2!52!2!57'0]}50[!33!2!53!2!48'0]}51[!33!2!53!2!49'0]}52[!33!2!53!2!50'0]}53[!33!2!53!2!51'0]}54[!33!2!53!2!52'0]}55[!33!2!53!2!53'0]}56[!33!2!53!2!54'0]}57[!33!2!53!2!55'0]}58[!33!2!53!2!56'0]}60[!33!2!54!2!48'0]}63[!33!2!54!2!51'0]}91[!33!2!57!2!49'0]}93[!33!2!57!2!51'0]}94[!33!2!57!2!52'0]}125[!33!2!49!2!50!2!53'0]}1['1]}2[!1}1[}5[!2}5['1]}2['4.]'1]}1['0]'3]}2['2]'2]+<0[^%]<1[^?]<2[:#^%]<3[<0[^?]<1[:#^%]^0]<4[,]:125:48:91^0

Best wishes. --Blashyrkh (talk) 23:50, 23 August 2026 (UTC)

btw, i thought that writing a quine in this esolang was impossible (even with one file mode) --dragoneater67 talk contribs (mobile) 17:55, 30 August 2026 (UTC)

Do I need to explain how it works, or is it obvious? --Blashyrkh (talk) 17:57, 30 August 2026 (UTC)

no ill try to figure it out myself, but thanks either way --dragoneater67 talk contribs (mobile) 18:09, 30 August 2026 (UTC)

Thank you for the language. It was quite a challenge. --Blashyrkh (talk) 18:10, 30 August 2026 (UTC)

A+B golfing challenge

Arbitrary size non-negative integers, separated by newline (U+000A), finished with newline too. The program should print addition result and newline character. Who's gonna try to do it? --Blashyrkh (talk) 18:03, 30 August 2026 (UTC)

"After sending a signal the program waits for the signal handler to finish, but it keeps listening for new signals."

It's unfair to change essential part of language specification after an interpreter and quine have been implemented. It's breaking change. And looks like inconsistent overcomplication anyway. All signals are enqueued and may be executed at some point later (depending on signal queue size). If you need to freeze sender's code until opposing handler has finished execution, split it into two (move post-call code to separate handler, make the opposing handler to signal you back). --Blashyrkh (talk) 09:17, 2 September 2026 (UTC)

ok, but a lot of my programs were written with that assumption --dragoneater67 talk contribs 09:21, 2 September 2026 (UTC)

its fine now, i reverted the change and fixed the programs (except bct) instead --dragoneater67 talk contribs 09:35, 2 September 2026 (UTC)

I believe the simpler an interpreter the better. Special cases' handling usually means an inconsistency or vagueness of specification. Signal queue must be just a queue. No priorities, no "being executed" flag etc... If signal is posted then it's enqueued. When receiver's scheduler would become idle, it dequeues the first (the oldest posted) signal and executes its handler. --Blashyrkh (talk) 09:49, 2 September 2026 (UTC)

Kolakoski sequence

}1['1'8]
}2['2'9]
}4[
  !1
  }8['5]
  }9['7]
  '3
]
}5[
  !2
  }8['4]
  }9['6]
  '3
]
}6[
  !1'4
]
}7[
  !2'5
]
'1'2'2
!1
'4
+
<1[:49]
<2[:50]
<3[^%]
<4[^4]
<5[^5]
<6[^6]
<7[^7]
<8[^8]
<9[^9]

139 bytes in stripped form. --Blashyrkh (talk) 12:20, 2 September 2026 (UTC)