00:08:29 -!- variable has quit (Quit: /dev/null is full).
00:15:24 <esowiki> [[Surtic]] https://esolangs.org/w/index.php?diff=55601&oldid=55598 * Digital Hunter * (+65)
00:16:12 <esowiki> [[User talk:Galaxtone]] https://esolangs.org/w/index.php?diff=55602&oldid=55244 * Digital Hunter * (+139) /* Chat */
00:52:30 -!- doesthiswork has joined.
02:34:57 -!- Naergon has quit (Read error: Connection reset by peer).
02:50:42 <doesthiswork> So I came up with something that should find languages that reduce bugs sort of like how code golf finds languages that are more expressive.
02:55:13 <zzo38> I don't know? I think the program can have bugs in most programming languages though, anyways
02:55:38 <doesthiswork> Person A sets a task and all the challengers provide both a program that does it and the smallest edit to that program that causes it to do it incorrectly (but without compile or runtime errors) The challenger's score is the size of the edit divided by the size of the program
02:58:02 <zzo38> O, OK, you can try that?
03:03:49 <shachaf> `le/rn exponentially//"exponentially" is a word that means "a lot".
03:03:51 <HackEso> Learned 'exponentially': "exponentially" is a word that means "a lot".
03:05:30 <HackEso> /srv/hackeso-code/multibot_cmds/lib/limits: line 5: exec: ?acute: not found
03:07:42 -!- Naergon has joined.
03:24:44 <imode> I guess I should give up trying to make my tree-rewriting system variable-less.
03:39:30 -!- variable has joined.
03:40:34 <rdococ> imode: I like how variable joined after you said that.
04:20:45 -!- variable has changed nick to constant.
04:22:57 <rdococ> doesthiswork: The variable just changed, it cannot be constant
04:28:15 <doesthiswork> There is no variable only constant. And because as you say constants never change, variable must have always been constant,.
04:33:53 -!- Naergon has quit (Ping timeout: 268 seconds).
05:32:50 -!- Naergon has joined.
05:35:31 <\oren\> I don't have any ginger tea so Ijust used ginger powder in the espresso machine. it worked surprisingly well
05:44:19 <\oren\> therefore, espresso machine can potentially be used to decoct all kinds of herbal liquids
06:33:10 -!- ais523 has joined.
06:48:22 -!- xkapastel has quit (Quit: Connection closed for inactivity).
06:56:12 -!- ais523 has quit (Quit: sorry for my connection).
06:56:27 -!- ais523 has joined.
07:14:13 -!- AnotherTest has joined.
07:23:20 <Lymia> doesthiswork, in most languages, commenting out some print command does so perfectly.
07:23:35 <Lymia> Its output will be incorrect and there will be no crash.
07:24:45 <Lymia> The features to avoid this aren't... really good features in practice.
07:25:11 <Lymia> The golfiest ways to make a program stop working are usually not what actually cause bugs (in my experience).
07:25:34 <Lymia> And the things that prevent them (dead code hard errors, unused variable hard errors, etc) are bad ideas in practice
07:27:46 <Lymia> Haskell is one of the safest languages out there right now.
07:28:56 <Lymia> And still, with basically any program, you can make it stop working with s/main =/main = const(return())$/
07:30:08 -!- AnotherTest has quit (Ping timeout: 255 seconds).
07:32:35 -!- doesthiswork has quit (Quit: Leaving.).
07:50:50 <Vorpal> <\oren\> therefore, espresso machine can potentially be used to decoct all kinds of herbal liquids <-- interesting, though I assume there might still be coffee taste left in the machine?
07:51:43 <Lymia> just get a press brewer or something
07:52:13 <Vorpal> also you could probably just crush the ginger and use a reusable infuser if you have one
07:55:59 <Vorpal> I use a large reusable cloth tea bag when making tea
08:12:27 <fizzie> Vorpal: Been a while since we last swapped these -- https://zem.fi/tmp/florence.jpg
08:14:25 <Vorpal> fizzie: I haven't done any in a while though :/
08:14:56 <fizzie> I've mostly been lazy and used the phone's tool for them, though that one was done in the traditional Hugin way.
08:15:35 <Vorpal> hm have hugin improved any in recent years? haven't looked at it for a while
08:16:06 <fizzie> I think some of the UI elements had moved places, but I don't think it's much different.
08:17:29 <fizzie> I had somehow managed to make the default lens type something non-rectilinear, had real trouble with stitching before I realized that. I think it probably remembers that setting, and maybe I had played around with it.
08:21:27 <fizzie> Not sure if I mentioned, but I also bought a fisheye lens.
08:23:30 <Vorpal> oh, some neighbor is using a hammer drill I think
08:23:42 <fizzie> https://zem.fi/tmp/duomo1.jpg https://zem.fi/tmp/duomo2.jpg fun, but not exactly all that practical
08:26:53 <Vorpal> expected a circular viewport
08:28:37 <fizzie> It's one of those where for APS-C it fills the frame. Something like 167° diagonal FOV.
08:30:12 <fizzie> I think if you stick it on a full-frame camera it's almost a circle, but not quite.
08:33:20 <fizzie> https://drkrishi.com/wp-content/uploads/2013/07/panorama-using-8mm-fisheye-01.jpg -- the (faintly visible) circle is what the image would be on a full-frame, but there's a hood that's been cut so that it doesn't obstruct the APS-C rectangle.
08:33:46 <fizzie> (In my version it's removable, in the original model it wasn't.)
08:36:08 <Vorpal> that is some intense colour fringes
08:36:35 <Vorpal> now when I look closely I see some in your photo too, but not as bad
08:37:17 <Vorpal> did you correct for it in post processing?
08:37:59 <fizzie> No. I wonder if that has something to do with how well the light/dark edge is is focus. The lens hood in that picture would be very out-of-focus.
08:39:19 <fizzie> (Or maybe it's just better near the middle of the frame.)
08:40:25 <Vorpal> colour fringing is generally worse towards they edges yes iirc
08:42:52 <fizzie> It's manual aperture and manual focus, though really if everything's more than about 1-2 metres away, you just set the focus to the 'infinity' marker and don't worry about it.
08:46:45 <ais523> (re the Lymia/doesthiswork conversation) in programming competitions you sometimes have to design programs to be resistant to being changed
08:46:55 <ais523> this lead to the development of languages with checksums
08:47:16 <ais523> although something like https://esolangs.org/wiki/A_Pear_Tree can only be resistant to 3-4 bytes being changed
08:47:22 <ais523> you could make a language that could handle more
08:49:54 <Vorpal> I guess most programming languages where small changes are still valid different programs (as opposed to syntax errors) are chaotic, since usually the result is completely different
08:51:07 <Vorpal> though there is an argument against that too since often a small change can still lead to no observed behaviour change (e.g. code is never actually executed, or it is still an infinite loop, just with a slightly different condition)
08:51:11 <ais523> right, some are intentionally designed like that, e.g. Incident
08:51:30 <ais523> where you can effectively remotely delete any part of the program by making an edit anywhere
08:52:56 <ais523> the intent was to make it able to polyglot with /anything/
08:52:59 <ais523> as long as you had an editable portion
08:53:21 -!- laerling has joined.
08:55:45 <Vorpal> but that are some really hard to use operations
08:57:17 <ais523> it's actually worse than it looks at first
08:58:13 <ais523> actually, control flow is pretty easy in Incident, the main problem is data storage and transfer
09:00:56 <ais523> the language is basically entirely made of call stacks
09:05:52 -!- erkin has joined.
09:09:18 <Lymia> Vorpal, how would you design a programming language that's not chaotic in such a manner?
09:09:30 <Lymia> I suspect the answer is probably: see neural networks
09:11:44 <Lymia> There's simple tricks you could use to make any valid program very distant (in a byte-by-byte sense) from any valid program (any cryptographic AONT on a conventional language works)
09:11:55 <Lymia> But there's still an underlying logic where a small change can create a huge difference.
09:21:52 -!- imode has quit (Ping timeout: 245 seconds).
09:22:09 <Lymia> Even Malbroge is that way
09:22:22 <Lymia> Though, it doesn't reject anything I guess
09:23:36 <ais523> Malbolge rejects almost everything
09:23:53 <ais523> IIRC there are only 8 valid options for each character position in the program, anything else is a syntax error
09:23:58 <ais523> (what those options are depends on the location)
09:24:19 <ais523> this makes Malbolge programs quite easy to recognise, they tend to have long sequences that run backwards through ASCII as a result of the syntactic restrictions
10:03:04 -!- arseniiv has joined.
11:36:27 -!- erkin has quit (Quit: Ouch! Got SIGIRL, dying...).
11:41:17 -!- laerling has quit (Quit: Leaving).
11:48:23 -!- jix has joined.
12:08:05 -!- APic has quit (Ping timeout: 240 seconds).
12:53:33 -!- oerjan has joined.
13:00:32 -!- doesthiswork has joined.
13:02:54 -!- SopaXorzTaker has joined.
13:12:23 -!- xkapastel has joined.
13:15:14 -!- Naergon has quit (Ping timeout: 276 seconds).
13:27:54 -!- xkapastel has quit.
13:28:12 -!- xkapastel has joined.
13:31:40 -!- SopaXorzTaker has quit (Remote host closed the connection).
13:58:43 -!- ineiros has joined.
14:39:41 <rdococ> Is there a control flow structure more flexible than delimited continuations (which seem to be rare in an esolang)?
14:41:21 <ais523> aren't non-deliminted continuations more flexible than delimited continuations?
14:42:52 <ais523> something I discovered a whlie back in INTERCAL is that you can emulate continuations using threads that can be paused
14:42:57 <ais523> although they're fairly heavy
14:43:24 <ais523> given that continuations have no obvious way to do pre-emptive (as opposed to cooperative) parallelism, threads may be more flexible
14:46:55 <rdococ> Delimited continuations can easily emulate undelimited continuations with a single 'reset' that wraps around the whole program and some kind of 'halt program' instruction at the end
14:47:12 <rdococ> ('at the end' being still within the 'reset')
14:48:08 <zzo38> Well, there is Forth; some implementations may be more flexible
14:48:49 <rdococ> I wonder if pausable threads can emulate delimited continuations
14:51:29 <rdococ> I guess you could just expose the call stack
14:53:02 <ais523> well, the call stack is pretty exposed in INTERCAL
14:54:26 <rdococ> Or maybe a call spaghetti stack
14:55:08 -!- oerjan has quit (Quit: Later).
15:16:56 <rdococ> If you allow the manipulation of stack frames (invoking it with values, modifying the frame it returns to, and cloning it) you can emulate delimited continuations fairly easily, I think
15:17:37 <rdococ> in addition to passing them around as first-class citizens (Communism: The Esolang)
15:31:37 <Lymia> Scala lets you serialize delimited continuations
15:31:45 <Lymia> So you can send control flow through the network :D
15:34:20 <ais523> hmm, I wonder if you can implement delimited continuations using undelimited continuations in a simple way
15:34:57 <rdococ> I tried, but I don't think it's possible
15:34:59 <ais523> something like "calling a delimited continuation takes you back to the old stack frame, but records where you called it from, and then reset can take you back to where you called it"
15:36:23 <Lymia> <rdococ> Is there a control flow structure more flexible than delimited continuations (which seem to be rare in an esolang)?
15:36:32 <Lymia> <s>computed goto</s>
15:36:57 <rdococ> nah, not harmful enough
15:37:02 <ais523> oh, computed next from is pretty powerful
15:37:18 <ais523> it's like come from except it allows you to go back again
15:37:53 <ais523> it lets you do things like implementing a single-stepping debugger within the language itself, by nexting from the IP as long as it isn't in the debugger itself
15:39:10 <ais523> it's not used in any mainstream language I'm aware of, though, because it's ridiculously inefficient
15:39:12 <rdococ> I've noticed that some implementations of reset/shift only allow 'shift' to interact with the 'reset' nearest to the top of the stac
15:39:48 <ais523> hmm, Perl has the option to replace the main loop of the bytecode interpreter
15:40:04 <ais523> that strikes me as pretty insanely flexible as operations go, and it doesn't seem to fall into any category other than "control flow"
15:40:44 <rdococ> do any esolangs have computed next from?
15:41:11 <ais523> probably not any others, though :-D
15:41:12 <zzo38> Maybe CLC-INTERCAL does
15:41:23 <ais523> both CLC-INTERCAL and C-INTERCAL do
15:42:04 <ais523> C-INTERCAL allows you to write the computed next from in a C or Befunge-98 program, but it'll only capture lines with INTERCAL line numbers
15:42:26 <ais523> (which means that you need to explicitly give an INTERCAL line number to part of the C or Befunge-98 program or you can't do anything with it)
15:43:29 <rdococ> hm, if I understand this, come from is to goto as next from is to call
15:46:49 <rdococ> could we extend the analogy to continuations?
15:47:30 <ais523> well, continuations are a generalisation of exceptions
15:47:36 <ais523> and resumable exceptions are something that exists
15:47:40 <ais523> so this seems maybe doable?
15:47:57 <zzo38> What programming language has powerful enough macros to implement next from and continuations and all of those things?
15:47:58 <ais523> presumably the continuation gets two arguments, the "payload" you passed it, but also a continuation to go right back where you were before
15:48:40 <zzo38> What do you mean by "resumable exceptions"; is that like the RESUME command in BASIC?
15:49:22 <ais523> it's a bit like a cross between RESUME from BASIC and catch from Java
15:49:42 <rdococ> zzo38: for something like come from or next from to work, every line you'd have to check each come/next from to see if the instruction pointer matches
15:50:05 <ais523> the idea is that when an exception occurs, the program looks for an exception handler in the normal way (stack-unwinding-like) but doesn't actually unwind the stack, instead the exception handler runs on top of the stack
15:50:40 <ais523> and then can choose to unwind back to its own location in the code (in the usual way), but can also choose to correct the issue and then return back to the code that errored
15:51:11 <zzo38> rdococ: For computed come from, yes I would think (if not computed then it is simpler to do), but I ask if it can be implemented by use of macros.
15:54:47 <rdococ> presumably, to implement come froms or next froms within the language itself you'd have to define something that runs before/after every line
15:57:03 <rdococ> continuations could be implemented in the form of lexical goto (goto out of anonymous function scope), I wonder if you could have a similar "lexical come from"
16:06:18 <rdococ> If threads can be cloned, paused and unpaused, they would be more flexible than *undelimited* continuations at least
16:06:58 <ais523> now I'm trying to work out what operation a delimited thread would support
16:07:05 <ais523> presumably you could pause it, change the bottom of the call stack, and unpause it
16:07:41 <ais523> unless you'd already returned past that point, so perhaps they have a marker "don't go past this point"
16:09:05 <rdococ> you could try the opposite route, and work out how concurrent continuations could work
16:09:16 <rdococ> concurrent delimited ones, that is
16:11:51 <rdococ> thread X could 'call' thread Y so that if Y returns with a value as opposed to just unpausing another thread and pausing itself, control would return to X?
16:14:09 <ais523> that seems similar to coroutines
16:23:45 <rdococ> How about this: Thread X could "invoke" Threads Y and Z by unpausing both of them, passing itself along with arguments to them, and pausing itself. Then when either Thread Y or Z "returns", one of them could unpause X and pause itself?
16:24:48 -!- SopaXorzTaker has joined.
16:25:00 <rdococ> If Y "returns" first, though, what happens when Z "returns"?
16:25:29 <rdococ> Or would X wait for both Y and Z to return by pausing itself twice?
16:35:53 -!- erkin has joined.
16:47:42 -!- constant has quit (Quit: Found 1 in /dev/zero).
16:55:40 -!- laerling has joined.
17:12:39 <rdococ> ais523: Since delimited continuations are essentially functions in that you can pass values to them, and they can return values, perhaps you could simply implement a way to call them concurrently?
17:15:28 <lambdabot> error: Data constructor not in scope: Yay
17:20:57 <rdococ> Another way to think about it is that functions are like thread generators, and to call a function would be similar to creating and resuming a new thread passing the caller's continuation to it.
17:21:28 <rdococ> Well, you wouldn't need to pass a continuation, just pass the caller itself if it's a thread.
17:28:38 <esowiki> [[User:Kaa-kun]] https://esolangs.org/w/index.php?diff=55603&oldid=55000 * Kaa-kun * (-18) Blnk'd out page
17:32:27 <rdococ> And if you can clone a thread, functions can then be thread prototypes, which you clone to create threads from.
17:33:21 <esowiki> [[Esolang talk:Community portal]] https://esolangs.org/w/index.php?diff=55604&oldid=49676 * Kaa-kun * (+290) /* How do you make userboxen? */ new section
17:33:48 -!- imode has joined.
17:35:36 <rdococ> Hello imode. ais523 and I were discussing control flow structures that could be more powerful than delimited continuations.
17:36:17 -!- ATMunn has quit (Excess Flood).
17:36:30 -!- ATMunn has joined.
17:37:58 -!- Naergon has joined.
17:41:18 <int-e> . o O ( computed COME FROM )
17:43:45 <rdococ> int-e: Computed COME FROM is maybe more or less powerful than undelimited continuations, but I don't think it's as powerful as delimited ones.
17:45:49 <rdococ> Although, computed COME FROM enables pre-emptive multitasking (something which even delimited continuations seems to lack), and if two COME FROM statements coming from the same line is supported then that would result in concurrency.
17:47:12 <rdococ> Even non-computed COME FROM supports pre-emptive multitasking (to an extent?) and concurrent threads.
17:48:56 <int-e> there is a multi-threaded intercal, where this is indeed how threads are spawned
17:49:31 <esowiki> [[User:Kaa-kun]] https://esolangs.org/w/index.php?diff=55605&oldid=55603 * Kaa-kun * (+834) Bio
17:51:09 <rdococ> How about multi-threaded "next from"?
17:57:24 <ais523> at least in C-INTERCAL
18:00:00 <rdococ> Having shift, reset and a fork instruction would probably be sufficient for concurrent delimited continuations...
18:03:11 <rdococ> Or perhaps if 'reset' could act as a forking instruction as well, which would be somewhat analogous to supporting multiple goto labels with the same name.
18:07:54 <imode> what, y'all aren't content with FSM-based control? :P
18:10:13 <rdococ> Yeah, it's kind of moot when even just vanilla structured programming languages can be turing complete.
18:10:52 <imode> expressiveness does matter.
18:14:19 <rdococ> Quantum Malbolge should hash the program securely before executing it, so programming in it would require calculating reverse hashes (with current, classic cryptography, it's easy for quantum computers but not classical ones).
18:20:09 -!- SopaXorzTaker has quit (Remote host closed the connection).
18:28:24 <zzo38> JavaScript has no goto command. All of the stuff that can be done with it you can avoid goto, and in many cases in JavaScript what it does have does help better anyways than in C, but in some cases nevertheless would be more nicer program to have goto sometimes.
18:30:35 -!- fractal_ has quit (Ping timeout: 240 seconds).
18:32:21 <zzo38> (BLISS also does not have a goto command.)
18:39:46 <rdococ> I feel like you could delimit threads in the same way that you can delimit continuations.
18:41:01 -!- AnotherTest has joined.
18:44:47 -!- wob_jonas has joined.
18:45:47 <wob_jonas> ais523: hi. in that brainfuck variant you invented, where the - command multiplies the cell by -2 instead of subtracting 1 from it, what sort of numbers is it support to use? modulo 256? bignums? something else?
18:46:42 <ais523> it doesn't matter unless you have a limited length tape though
18:46:46 <ais523> because brainfuck minus - is TC
18:46:48 <wob_jonas> in that case I wonder if that variant is even turing-complete
18:46:59 <ais523> https://esolangs.org/wiki/Brainfuck_minus_-
18:46:59 <wob_jonas> brainfuck on bignums without - is TC?
18:47:15 <ais523> although bignums makes it harder
18:47:30 <wob_jonas> yes, without bignums it's easy, that's why I'm asking
18:47:35 <pikhq> With integers mod 256 it's pretty trivial, really.
18:47:41 -!- fractal_ has joined.
18:47:49 <pikhq> (or mod any number)
18:48:06 <pikhq> Since you just need to do + a number of times congruent to -1.
18:50:01 <rdococ> brainfuck without - is demonstrably turing complete whether the integers are modular or not as seen in the article
18:51:07 <pikhq> Yeah, that article suffices to prove it, but it's pretty non-trivial.
18:57:11 <rdococ> What would occur if you replaced > and + with }, which is equivalent to >+?
18:58:47 <wob_jonas> rdococ: I think that variant is already invented under some name and on the wiki
18:59:00 <ais523> without - too? then it's at most a PDA, and probably less powerful than that
18:59:14 <wob_jonas> you can just write > as }- and + as <}
18:59:41 <rdococ> wob_jonas: We're talking about a derivative where >, +, - don't exist while } does.
19:00:01 <rdococ> + is fairly trivial, as it's just <}. > on the other hand is most likely impossible.
19:00:47 <ais523> the problem is that you can never read any data to the right of the pointer
19:01:55 -!- AnotherTest has quit (Ping timeout: 245 seconds).
19:02:02 <pikhq> Would it be so limited? If it's mod-256, then > is <} 256 times.
19:02:52 <pikhq> Yeah, that might be a PDA.
19:03:23 <ais523> it obviously can't be stronger than a PDA, but I suspect it's weaker
19:04:18 <pikhq> Not quite an FSA because it definitely has infinite states, but
19:04:29 <ais523> I think it's a single-counter machine
19:04:37 <ais523> specifically, the number of 1s to the left of the pointer
19:04:55 <rdococ> I don't even think it's that
19:05:05 <pikhq> Quite possibly, yeah.
19:05:11 <ais523> nah, it is, you can increment with } and decrement with <
19:05:28 <pikhq> Interesting that making it mod-256 makes it more powerful.
19:06:06 <rdococ> only the first cell will ever be 0 when the cell pointer is on it
19:06:28 <pikhq> Well, unless it's unbounded to the left.
19:06:33 <rdococ> and if you can't go to the left of the first cell you can't make it anything other than 0. the tape is effectively fixed.
19:06:41 <wob_jonas> you can also consider making it 0 to 255 inclusive, or -128 to 127 inclusive
19:06:47 <wob_jonas> where overflows lead to undefined behavior
19:07:09 <rdococ> then its computational class would depend on its undefined behavior
19:07:43 <ais523> "i=i++; // makes the language Turing-complete"
19:08:12 <rdococ> or overflow causes the cell pointer to move to the right
19:09:28 <wob_jonas> no no. overflow just causes the machine gives control to a malicious adversary with unlimited computing power, who'll want to make your program behave incorrectly
19:09:36 <wob_jonas> that's what undefined behavior means
19:10:02 <ais523> wob_jonas: technically speaking, that could be TC too
19:10:15 <ais523> it's like an oracle machine except the oracle is evil
19:11:02 <wob_jonas> it's not turing complete, because you can't easily translate any program from some other TC language to a program that always does the samd
19:11:18 <ais523> there's no "easily" requirement
19:11:36 <ais523> all you have to do is be very good at making it look like a specific course of action would be the most destructive to what you were trying to achieve
19:11:37 <wob_jonas> it has to be somewhat easily, otherwise you'd put all the computation in the translation
19:11:46 <ais523> hmm, I feel a new esolang coming on
19:12:22 <ais523> that said, the adversary has to be somewhat gullible or else they could just always return 0, or implement https://esolangs.org/wiki/Baby_Language, or something
19:13:23 <wob_jonas> ah, an monkey with typewriter language
19:15:50 <ais523> I'm interested in its computational class, actually
19:16:09 <ais523> this is more a question of how computational class is defined than anything else, though
19:22:10 -!- variable has joined.
19:42:42 -!- APic has joined.
19:43:14 -!- Phantom_Hoover has joined.
19:59:14 <imode> I'm still in the midst of a crisis. any other automata I look at that's been proposed either need to abstract upwards to a TM or are extensional equivalents to a TM.
20:02:41 <imode> ais523: so I've been looking into different kinds of automata. queue automata, 2-stack PDAs, tag systems, etc.
20:04:05 -!- laerling has quit (Quit: Leaving).
20:04:34 <wob_jonas> imode: isn't that because the queue stuff is even more inefficient than a one-tape turing machine, as in, sometimes you have to spend squared the amount of time?
20:05:01 <wob_jonas> imode: although you should of course look at counter machines and all their strange variations, those are even more inefficient
20:05:14 <imode> and from what I can see, using queue automata as an example, you're always going to just overlay a tape over whatever datastructure you've tacked on in order to do any algorithmic work.
20:05:35 <imode> wob_jonas: I figured, but you'd at least find some algorithms where you don't have to loop through the queue all the damn time, right?
20:05:53 <imode> like why else would you bother with any automata other than TMs then if you're just going to abstract upwards to a TM's tape?
20:06:25 <imode> I'd like to see something as trivial as binary addition on a queue automata.
20:07:13 <imode> I thought tag systems would be different but, sure enough, they rely on the same methods..
20:09:17 <ais523> imode: normally I end up going to counter machines (which can be programmed in directly) rather than tape machines
20:09:42 <ais523> e.g https://esolangs.org/wiki/The_Waterfall_Model maps much more naturally onto a counter machine
20:09:54 <ais523> and trying to simulate a TM into it you'd go via counteres
20:11:59 -!- imode1 has joined.
20:12:34 <imode1> ais523: right, but throwing away just proofs of turing completeness, what the hell is the purpose of these automata other than just proving they're turing complete?
20:12:58 <ais523> proving that other things are Turing complete
20:13:51 <imode1> okay, that's fine, but you'd think that there are some classes of "native algorithms" that don't just resort to a simulation of a damn tape. :\
20:14:25 -!- imode has quit (Ping timeout: 245 seconds).
20:14:36 <wob_jonas> It's sort of a funny hierarcy if you take a one-queue machine, a one-tape machine, a 2-tape machine, a 3-tape machine, a 4-tape machine, etc, and a pointer machine. there's only like a squaring slowdown (O(t**(2+epsilon)) steps for the slower when t steps on the bigger) between the top and the bottom one, but each one in the hierarcy can only simul
20:14:36 <wob_jonas> ate the next one with that square slowdown
20:14:50 <ais523> imode1: a while back I was working on an optimised interpreter for counter machines
20:15:14 <ais523> they are easier to optimise than Turing machines are, and counter machine programs ran faster than the equivalent Turing machine programs would have done post-optimisation
20:15:41 <imode1> right, but I don't... care much about optimizations. I'm saying that there just doesn't exist a non-tape-oriented set of algorithms for shit like queue automata.
20:16:24 <ais523> do you consider Thue to be tape-based?
20:16:37 <ais523> that's pretty easy to implement on a general queue automaton
20:17:13 <imode1> it is, and I've done it (queues are nice because they're effectively cyclical strings).
20:17:39 <ais523> whereas with the tape you have to keep going back and forth
20:18:15 <imode1> right. queues seem good for models of computation that require some rewriting rules.
20:18:45 <imode1> but I've not really gone into translating things like "traditional algorithms" into thue-like rewrite systems.
20:19:12 <ais523> the queue model also feels essentially concurrent
20:19:23 <ais523> as you can do things on multiple places in the queue as easily as you can in just one place
20:19:31 <ais523> whereas with a tape+tape head model, it's easier to stay in one place
20:19:42 -!- sebbu2 has joined.
20:19:46 <wob_jonas> so there are problems you can solve more efficiently on a 101-tape turing machine than on a 100-tape one, but they get rare above 3 tapes
20:20:18 <ais523> "101-way diff", for example
20:20:20 <imode1> something that I've been wanting to do is extend a queue automata with I/O. I feel that's easier than a traditional TM.
20:21:08 -!- sebbu has quit (Ping timeout: 256 seconds).
20:21:34 <ais523> wob_jonas: it's like a 3-way diff but bigger
20:21:42 <imode1> wob_jonas: interactive, yeah.
20:21:45 <wob_jonas> ais523: yes, but what's 3-way diff in this sense?
20:22:04 <ais523> this is just a guess, it seems like a reasonable one though
20:22:58 <imode1> because with stuff like rewrite rules simulated on top of a queue automata, you can just do something easy like "request_for_input1 -> <inputted stuff from the keyboard".
20:23:43 <wob_jonas> and you could also consider multi-stack machines, where every 2n-stack machine can simulate an n-tape machine efficiently, and every n-tape machine can simluate an n-stack machine efficiently
20:23:59 <wob_jonas> so it's sort of a different hierarchy probably
20:24:34 <wob_jonas> ais523: the obvious problem for that is simulating a 101-tape turing machine program, but that's sort of artificial
20:25:14 <imode1> ais523: the problem with thue is also the intuition behind it. I can only speak from my ignorance but I don't see how you could create an algorithm that should be "intuitive" on a TM that's intuitive in a semi-thue system.
20:25:38 <imode1> like it's fairly mechanical when you're working in a TM. you work on the basis of seeks and searches, and you can compose larger machines from smaller ones. can you do that in Thue easily?
20:28:31 <ais523> Thue is best thought of as a combination of a) data pointers (somewhat TM-like), and b) pieces of data moving through other pieces of data (not at all TM-like)
20:28:45 <ais523> composition is done at the level of unique symbols
20:29:00 <ais523> i.e. you have some symbol that isn't used for data, and put that in all the rewrite rules that have a particular purpose
20:29:14 <ais523> then they can't clash with each other, and that symbol in the string says where "that rule" is currently working
20:29:19 <ais523> but you can have multiple heads, etc.
20:29:30 <imode1> my interest is piqued.
20:30:18 <wob_jonas> oh, I think I see what you mean by 101-way diff, although that would be really hard to prove the complexity, but you can probably generate some slightly more tricky problem like that that's more believable to be provable
20:30:38 -!- wob_jonas has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
20:30:42 <imode1> I like the idea of multiple heads.
20:31:09 <imode1> but my question is, you're essentially just simulating a traditional TM at that point right? states and all?
20:36:59 <imode1> hm.. you could encode the state of the TM and the tape head as just a string of two (or more!) characters. then you could just plonk surrounding characters around that.
20:42:07 <imode1> shoot, I gotta run. if you're alright with it, I'll be back in an hour ais523. I'd like to pick your brain if you're around! :)
20:43:25 -!- imode1 has quit (Quit: WeeChat 2.1).
21:03:44 -!- arseniiv has quit (Ping timeout: 255 seconds).
21:06:05 -!- variable has quit (Quit: /dev/null is full).
21:09:03 <rdococ> Hm, I bet there's already an esolang where the code is the data...
21:09:20 <rdococ> I did have an idea for planar brainfuck...
21:13:25 <esowiki> [[Surtic]] https://esolangs.org/w/index.php?diff=55606&oldid=55601 * Digital Hunter * (-218)
21:33:52 -!- oerjan has joined.
21:41:39 -!- AnotherTest has joined.
21:48:39 -!- AnotherTest has quit (Ping timeout: 268 seconds).
21:49:32 <zzo38> I implemented a lot more stuff in Free Hero Mesh now, including the class loading, and functions to read the levels/solutions from those files or the user cache as applicable, and the SQL execute mode, etc. If you like to, you can help too such as to draw the logo, to write the picture editor program (it would be an external program, probably), and/or to write complaints about it.
21:52:22 <zzo38> (And I am glad they added upsert now in SQLite, since Free Hero Mesh internally uses it in one function.)
21:53:34 <zzo38> Also I got a message with valgrind that one of the loss records says zero bytes are definitely lost (and then specifies what function); it is supposed to do that, and if so, why?
21:54:01 <esowiki> [[Esolang talk:Community portal]] https://esolangs.org/w/index.php?diff=55607&oldid=55604 * Oerjan * (+256) /* How do you make userboxen? */ Mostly you don't
21:54:15 <lambdabot> error: Variable not in scope: userboxen
21:54:56 <oerjan> . o O ( someone will now link a userbox on the wiki i don't know about )
21:55:33 <zzo38> On what wiki? Does esolang wiki have a user box?
21:55:54 <oerjan> no, but Kaa-Kun asked about them.
21:56:36 <oerjan> and there are enough pages on the wiki i haven't looked at or don't remember, that someone _may_ have made one.
21:56:58 <zzo38> Still it should be possible to do without needing to add any additional extensions.
21:57:15 <oerjan> . o O ( also upsert totally looks like someone made a typo )
21:58:09 <rdococ> Userboxen should be the official plural.
21:58:48 <zzo38> Maybe, but it does not seem to be a typo. It means a INSERT command that also has a ON CONFLICT ... DO UPDATE afterward to update instead of insert in case there already is such a record in the table. Apparently it was from PostgreSQL at first, but now SQLite has it too.
22:00:30 * oerjan didn't notice the plural until you mentioned it
22:04:11 <oerjan> of course i'm old enough to know about it. but these days we need to be gender neutral, so clearly the plural should be userbcattle hth
22:08:54 -!- erkin has quit (Quit: Ouch! Got SIGIRL, dying...).
22:10:10 <oerjan> <rdococ> Having shift, reset and a fork instruction would probably be sufficient for concurrent delimited continuations... <-- does intercal have SPOON or KNIFE?
22:10:25 <zzo38> That is problem of English (and many other) language, not having suitable gender neutral pronoun and someother gender neutrals sometimes
22:10:32 <zzo38> oerjan: Not any version I know.
22:10:37 <int-e> PLEASE ABSTAIN FROM KNIVING SPOONS
22:10:37 <zzo38> Make it up if you like to do so.
22:10:49 <ais523> oerjan: those sound like Snowflake instructions
22:11:06 <ais523> …it's probably a good thing this language is implemented or else they might not exist any more
22:11:27 <ais523> hmm, it seems that Snowflake has SPOON and FORK but not KNIFE
22:11:37 <ais523> Brachylog has a knife instruction, but it doesn't do flow control
22:12:24 <ais523> in Snowflake, fork … spoon is quite close to a parallel map
22:12:39 <ais523> but you can run them unpaired if you want to
22:16:06 <ais523> (the point of having a map instruction is that Snowflake needs to do complicated calculations in a reversible way, so it's "main" flow control commands must be ones that are inherently terminating)
22:18:14 -!- imode-desktop1 has joined.
22:18:40 -!- imode-desktop1 has quit (Client Quit).
22:18:59 -!- imode-desktop1 has joined.
22:19:04 <oerjan> <rdococ> Quantum Malbolge should hash the program securely before executing it, so programming in it would require calculating reverse hashes (with current, classic cryptography, it's easy for quantum computers but not classical ones). <-- i don't think that's easy for quantum computers.
22:19:24 -!- imode-desktop1 has quit (Client Quit).
22:19:42 -!- imode-desktop has joined.
22:20:08 <oerjan> you could get a square root speedup with grover's algorithm, but nothing enormous.
22:21:59 <oerjan> as scott aaronson mentions in his latest blog post, cryptography _other_ than public-key isn't really cracked easily with QC.
22:22:31 <ais523> imode-desktop: a good example of something that Thue-alikes are good at is bracket matching
22:23:37 <ais523> if you just want to check for matchedness and not preserve the data, you can replace () with the null string, which is something that's much more complex in a Turing machine
22:23:45 <ais523> but suppose you want to preserve the pattern too
22:24:19 <ais523> you can do something like replace ) with x], ]x with x], )x with x), [x with x[, and (x with [
22:24:44 <ais523> the idea is that each ) spawns an x, and the x's flow to the left until they reach an open parenthesis, at which point they're consumed
22:25:22 <ais523> if any escape to the left, there are unmatched ), and if there are unmatched (, one of them will be left unchanged without becoming [
22:25:53 <ais523> the x's here act like miniature data pointers which are just looking for a bracket to match
22:28:39 <ais523> the #1 most annoying thing about writing Thue is that if you want characters in group 1 to be able to move past characters in group 2, you have to write all the cases out individually
22:28:47 <ais523> apart from that it's a really beautiful language
22:29:25 <ais523> yes, or just generate a variant that has wildcards
22:29:44 <imode-desktop> I suppose I should just look into naive string rewriting, ala Thue. do you have any resources/literature you could point me to?
22:31:23 <ais523> not really, I've mostly just been figuring things out myself as I go
22:31:35 <imode-desktop> makes sense. it struck me as a relatively unexplored area.
22:32:57 <imode-desktop> I've just been wondering about scaling upwards. I wonder what a simulation of a random access machine would look like in Thue. that's one step to getting somewhere close to "usable".
22:34:59 <ais523> you'd have to limit the character set, thue suffers from not escaping its input
22:35:48 <ais523> that said, thue would be quite bad at self-interpreting because it's not normally very good with handling two different things at the same time (as you need to keep moving them through each other to get them to the right relative positions)
22:36:03 <ais523> and when interpreting thue, you have three things to handle at once (working string, search string, replacement string)
22:37:20 <imode-desktop> I assume you'd have to have the equivalent of a tape division.
22:38:42 <imode-desktop> construct the equivalent of a multi-tape turing machine and map each tape to each component, scanning through the input one cell at a time.. but then you're back to abstracting towards a TM.
22:38:44 <oerjan> <ais523> the queue model also feels essentially concurrent <-- did you see my update to the underload construction in fueue, that's relevant
22:39:36 <ais523> I think I might have /seen/ it but I can't remember what it was
22:40:06 <ais523> imode-desktop: well you can make use of the nondeterminism, if it is genuine nondeterminism
22:40:11 <ais523> but most thue interps don't implement that
22:41:41 <ais523> ah yes, I remember now
22:41:47 <ais523> (now that I've looked at it)
22:42:50 <esowiki> [[SimPPLe]] https://esolangs.org/w/index.php?diff=55608&oldid=53107 * Kaa-kun * (-13) Reedireect
22:43:50 <imode-desktop> ais523: I guess there's potential. what I'm looking to do is stupid but I'm exploring translating traditional game models (like roguelikes, text adventures, anything that involves some abstract interaction between entities that may contain arbitrary codes) to different models of computation, and I've been on a descent to find the most "convenient" one to use.
22:44:40 <ais523> imode-desktop: you might want to talk to Lymia (who was trying something quite similar) about this
22:45:01 <ais523> but that's a good idea, I'm also interested in the results of this
22:45:43 <imode-desktop> the possibility of interactive I/O and "clean extendability" of whatever model I choose would also mean I get to work with the multiplayer aspect.
22:46:13 <imode-desktop> much like how many people have extended brainfuck with I/O and network capabilities.
22:46:38 <ais523> I've been thinking about this from the other direction (i.e. creating a new paradigm for games programming)
22:46:52 <ais523> I combined something like three old languages I was working on and am really happy with the direction it's going in
22:46:59 <rdococ> Hm. idea: call spaghetti queue
22:47:04 <ais523> but it's all ideas so far, and possibly will be forever as this is daunting to spec, let alone implement
22:47:35 <imode-desktop> I feel that. the hardest part for me is trying to translate different object behaviors to moves of a TM tape head.
22:48:42 <imode-desktop> it's kind of degraded into a "multi-user programming environment" based on really small automata.
22:49:45 <imode-desktop> because when I started taking into account the behaviors that MUDs offer, for example, it turns out that you just need the ability to execute arbitrary programs that respond to the world state and external player/object events.
22:50:16 <ais523> the basic idea is a) objects can be created and persist even when not referenced, they have to be explicitly deleted; b) object fields cannot be directly modified but you can attach modifiers to them, some fields are calculated, and some fields are calculated as integrals of other fields so you can store data in the constant of integration; c) collisions between objects (with a simple or maybe even complex collision-detection algo) are a first-class
22:50:17 <ais523> part of the language, and are the only way to do "discrete" operations like creating and deleting objects; d) collisions may be based on things other than positions but they occupy a sort of "conceptual space" which has a speed of light (thus "distances" are actually measured in time, with c=1)
22:51:24 <imode-desktop> that last bit is interesting to me in particular, have you ever seen this?: https://mitpress.mit.edu/books/conceptual-spaces
22:52:13 <ais523> from the abstract it's unclear if the book is describing the same thing as me or not
22:52:16 <imode-desktop> the tl;dr is "guy tries to map properties of objects to quality dimensions, and starts sketching out figures that represent concepts and individuals."
22:52:16 <ais523> I guess they might be different but similar
22:53:20 <imode-desktop> probably different, but you're the only other person I've seen using the term "conceptual space", so I had to at least ask. ;)
22:53:53 <oerjan> <rdococ> Hm. idea: call spaghetti queue <-- . o O ( call FSM )
22:54:03 <ais523> it's more similar than I thought it would be
22:54:22 <ais523> my method is intended as a model of computer thought, though, not a model of human thought, so it's much simpler
22:56:06 <rdococ> oerjan: Perhaps stack frames with multiple parents could return to all of them concurrently, or maybe the stack frame would be able to choose which parent to return to.
22:58:19 <rdococ> A "call FSM" would be, most likely, a call directed graph, which would allow for cycles of stack frames that return to eachother. I'm unsure of the uses for it, though.
22:58:43 <oerjan> `le/rn call cthulhu//Call Cthulhu is the most destructive calling convention.
22:58:45 <HackEso> Learned 'call cthulhu': Call Cthulhu is the most destructive calling convention.
22:59:34 <ais523> "call finite state machine" is basically how Verity works
22:59:41 <ais523> it doesn't support (non-tail) recursion for obvious reasons
22:59:51 <rdococ> "DEALLOCATE THE KRAKEN!"
23:00:02 -!- danieljabailey has quit (Quit: ZNC 1.6.5+deb2build2 - http://znc.in).
23:00:21 -!- danieljabailey has joined.
23:00:29 <imode-desktop> ais523: what I'm noticing is the "ultimate game" turns out to be something akin to Ready Player One's oasis, or the Metaverse. not something that has any specific game behavior, but a simple multi-user environment (can be single user as well) that starts off as a simple shell, but can evolve to contain different kinds of interactive game objects.
23:01:05 <ais523> so basically a codenomic
23:01:14 <imode-desktop> if you wanted to build a forest with some birds in it that hunt and peck for seeds on the ground, you could plop some graph nodes down, write some behavior for the bird, write some behavior for seed growth, and bam.
23:03:10 <ais523> I think that things like the old MUDs/MOOs probably got closest to that
23:03:14 <ais523> modern games tend to be a lot more controlled
23:03:50 <imode-desktop> I don't know why they never took off. there are ways to make those types of worlds graphical, more interactive.
23:07:32 <ais523> probably because it conflicts with the usual monetisation model
23:07:42 <ais523> charging for skins and emotes is not really worth much when players can create anything
23:07:52 <ais523> you'd have to do something like charging for anything that's blue, or the like
23:08:09 <zzo38> There is still the MUDs that you don't need any graphics
23:09:44 <imode-desktop> right, but I've not really seen any that are too terribly "out there". let's face it, a lot of the languages that these things are built with suck. and their toolkits are largely game-focused (at least the ones I've seen are.)
23:10:55 <ais523> I think you're right that Second Life is close to what you're looking for, at least in concept
23:11:08 <ais523> the execution, of course, could be much better
23:11:23 <imode-desktop> definitely. imho their first mistake was trying to work within 3D space.
23:12:14 <imode-desktop> starting with 3D is not the way to go in my eyes. that kind of abstraction is best left to the logic you define later, not a job for your core systems to manage. 3D mesh data should be an afterthought, and well-considered one at that...
23:12:58 <imode-desktop> the early MUDs had it right. flat objects in memory with a loose communication mechanism that tied them all together, so you could have abstract rooms or entire spaces full of interacting objects and players.
23:13:02 -!- Phantom_Hoover has quit (Read error: Connection reset by peer).
23:13:45 <imode-desktop> the next logical step is the graph of rooms, as with many MUDs. dedicated door objects that can speak to eachother and whoever uses them, so you can coordinate teleportation at the object level, _not_ have it as an engine builtin.
23:14:24 <imode-desktop> after that, you can add positional movement on top of the room layout, and even things like SL's grid, just by tying rooms together and being smart about prefetching objects from a certain range out in your renderer.
23:15:20 <zzo38> What I know is how ifMUD works; there are many objects having locations, and fields on objects, and exits on both items and rooms
23:15:25 <imode-desktop> I think the killer there is "choose your interaction". you can either have room-based movement, or location-based movement within rooms, or positional movement as well.
23:16:39 <imode-desktop> but imagine you're just using this thing for collaberation? you can pull 4 people into a room, 2 of them create objects, and the other 2 act as QA, trying to break what's been made.
23:18:32 <imode-desktop> these kinds of environments aren't just suited towards game-like content, they're essentially multi-agent systems, where the players are the agents and the programmers!
23:23:05 -!- olsner has quit (Ping timeout: 240 seconds).
23:23:26 <imode-desktop> the starting point to all of that, I guess, is finding a solid base, which is why I've been concerned with automata.
23:27:48 -!- oerjan has quit (Quit: Nite).
23:36:13 -!- sebbu2 has changed nick to sebbu.
23:38:27 -!- doesthiswork has quit (Ping timeout: 256 seconds).
23:40:44 -!- imode has joined.
23:42:34 -!- olsner has joined.
23:52:56 <rdococ> Hm, might start trying to design my own b{markup language}.
23:55:24 <rdococ> https://esolangs.org/wiki/Start-reset_markup_language is fairly inaccurate - the IRC control codes for formatting are toggles, so \b turns bold off if it's already on.