< 1763337639 345985 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: can your interpreter optimize over what ends up as nesting loops in bf? < 1763337644 787147 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, a bignum can be used to store arbitrary amounts of data (pretty much by definition), and some programs do that as an alternative to using multipel tape cells < 1763337663 309641 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the waterfall model uses a different control flow scheme, but effectively yes < 1763337716 775711 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it works by tracing round sequences of execution that actually happened to see whether they're exact repeats except that some cells increased/decreased by constants without any successful zero tests on them < 1763337721 258413 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :yeah, i start getting a sense of the challenge. for instance an instruction can't hold some constant to add to some other cell. it has to actually apply the operations on memory. is that kinda it? < 1763337730 320502 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and then just simulates the remaining loop executions until something tests as zero < 1763337757 287452 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is enough to optimise code that implements a divmod into an actual divmod instruction < 1763337776 54426 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and divmod is one of the most important operations when using a single tape cell to store arbitrary amounts of data, because it lets you use it like a stack < 1763337797 297311 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(you hold the stack in the digits of the number, the top of the stack is the least significant digit, then you divmod to pop and multiply-add to push) < 1763337862 388549 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i sort of get the very rough idea of what you're saying, but really not more than that :/ < 1763337890 530457 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(but i'm definitely missing background here) < 1763337965 887490 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually this reminds me of the discussion on literate programming above < 1763337981 111211 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :literate programming isn't a huge change to what you can do, but it's expected to be combined with a particular programming style < 1763337989 149754 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :and when i think about it, i'm not even sure where i'd start optimizing bignum bf, because except trivial constants, an instruction can't include them... < 1763338001 587477 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :bignum BF is similar, it doesn't hugely change programs written for wrapping interpreters, but it adds new possibilities which have their own style < 1763338019 478465 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and bignum BF is often run on very short tapes – three cells is enough) < 1763338037 322597 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :yeah, i do get the extra dimension it adds, quite literally < 1763338063 431634 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :avih: I assume you'd optimize all loops that have no inner loop and are balanced < 1763338067 679896 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it's like every cells is its own infinite tape < 1763338072 257434 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :cell* < 1763338079 350231 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: yes, that's a good way to put it < 1763338108 537620 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :b_jonas: yes. but that's trivial. teh next step is the interesting one. < 1763338137 533908 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: have you seen the result that bignum brainfuck only needs two pairs of brackets (total, in the whole program) to be Turing-complete? < 1763338182 835599 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :b_jonas: the 1k bf2c in sh which you saw does that too, in like 5 lines of awk. < 1763338184 21959 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :https://cs.stackexchange.com/questions/102363/how-many-pairs-of-brackets-are-sufficient-to-make-brainfuck-turing-complete > 1763338200 467783 PRIVMSG #esolangs :14[[07User talk:Sawyer.go092314]]4 10 02https://esolangs.org/w/index.php?diff=168529&oldid=168497 5* 03Sawyer.go0923 5* (+61) 10 < 1763338202 614404 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this sort of thing is why optimising nested loops is in general very hard < 1763338237 546978 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: no. but i do get a sense of why that can be true < 1763338257 71856 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not sure how many you need for 1-bit or 8-bit BF < 1763338257 122499 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(even if not the specifics) > 1763338307 518186 PRIVMSG #esolangs :14[[07User talk:Sawyer.go092314]]4 10 02https://esolangs.org/w/index.php?diff=168530&oldid=168529 5* 03Sawyer.go0923 5* (-2) 10 > 1763338346 36563 PRIVMSG #esolangs :14[[07User talk:Sawyer.go092314]]4 10 02https://esolangs.org/w/index.php?diff=168531&oldid=168530 5* 03Sawyer.go0923 5* (+35) 10 < 1763338354 237673 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: in general absolutely yes, but practically in many cases, as long as all the loops are balanced, it doesn't feel beyond reach. but it does require more infrastructure for tracking states and deps < 1763338393 989206 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(re hard to optimize nesting loops) < 1763338397 752642 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, in the 2-bracket BF construction both loops are unbalanced (in different directions) < 1763338424 21988 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs ::) < 1763338428 834225 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :mushos fun < 1763338432 54007 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ch* < 1763338498 223136 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :plain flat balanced loops can be done almost blindly. it really requires very little. < 1763338526 545574 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(i.e. counter loops, where it's balanced and head overall delta is 1 or -1) < 1763338610 465775 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there is something called the "polynomial optimisation" which is used for nested balanced loops, but I'm not sure I fully understand it – I think it only works for some of them rather than all of them > 1763338622 805391 PRIVMSG #esolangs :14[[07!frjnrehrbwgyrigbyieurgbyfaerkhbvrwgtr.14]]4 10 02https://esolangs.org/w/index.php?diff=168532&oldid=168479 5* 03Sawyer.go0923 5* (+16) 10 < 1763338800 102711 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: i might have a sense of where it stops working - when the same cell is used cumulatively at multiple levels of nesting < 1763338814 938395 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: that's my guess too < 1763338830 852147 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :in some cases it should be solvable too, but i think not in all of them < 1763338911 8293 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think probably the case where it doesn't work is if the inner loop changes the outer loop's control cell < 1763338916 43630 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :because the nesting scenario doesn't flat out unroll it - it turns it into an an "if", which is great speedup, but hard to optimize over multiple levels < 1763338978 523438 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(no pun intended in "flat out") < 1763338987 276036 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(well, maybe just a little) < 1763339043 333480 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: yeah, that definitely wouldn't work with a "naive" optimizer for this construct, but if it can track the values and still "get" the over delta, it might < 1763339056 399343 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :overall* < 1763339171 759182 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, I think balanced-loop-only bignum BF is TC, because I think you can compile Brainpocalypse II to it, but I haven't worked out the details of the compile so maybe I'm missing something important < 1763339173 172439 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but an optimizer doesn't have to optimize everything. if whatever it optimizes is effective, at reasonable cost, then it's still worth it < 1763339237 942354 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yep < 1763339254 795584 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :one thing that could be hard to optimized is if a conditional is implemented as unbalanced like [BODY >]< where the right square bracket is on a cell that's always zero but you can only tell that from global analysis < 1763339259 469039 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's still interesting to figure out the point at which an optimizer *can't* be written, though, as it helps to know what can be < 1763339271 533576 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :as opposed to, say, [BODY >[-]]< < 1763339280 24958 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: that's actually the thing that made me give up trying to write a BF optimizer myself < 1763339303 313591 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :trying to figure out global invariatns < 1763339307 837040 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :b_jonas: that _should_ be optimizable if the optimizer keeps track of known cell values, at least to some degree < 1763339359 243809 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(depending which barriers make it drop its knowledge) < 1763339412 445006 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :avih: yes, but it needs to simultaneously optimize conditionals to figure out that this [BODY>]< is balanced and figure out global invariants, because those two can circularly depend on each other < 1763339440 934422 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :global invariants circularly depend on themselves, it's a pain < 1763339449 569959 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yes < 1763339477 360605 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I don't want to write a brainfuck optimizer, but that sort of thing can come up in less esoteric optimizers too > 1763339480 114328 PRIVMSG #esolangs :14[[07User talk:Sawyer.go092314]]4 10 02https://esolangs.org/w/index.php?diff=168533&oldid=168531 5* 03Aadenboy 5* (+478) 10add note < 1763339483 85877 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :yes. it depends a lot on the specifics. but in my mind, there's a maximum body of knowledge that an optimizer can keep track of (without actually running the code), and if some constructs are deducable from this knowledge, then it's optimizable < 1763339605 624952 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there's also the JIT approach: you guess at a global invariant, and produce code that runs assuming the invariant (while checking it's true), and if the invariant ever becomes false, it recompiles itself without the invariant < 1763339620 703406 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(this can save time even if the invariant isn't always true, as long as it's usually true) < 1763339652 555012 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I guess a variant of that where you codegen two versions, one which assumes the invariant and one that doesn't, and jump back and forth based on whether it's true or false at the time < 1763339666 628869 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: how do you prevent it from running indefinitely? setting some hardcoded limit on the instructions executed or some such? < 1763339680 743405 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: prevent what from running indefinitely? the program or the optimiser? < 1763339692 316171 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :the hit to test the hypothesis < 1763339695 4024 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :jit* < 1763339710 57124 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: so you run it while the program is running < 1763339717 170236 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and monitor what the program actually does < 1763339734 658781 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :i.e. you aren't trying to predict the program's behaviour in advance, you monitor it at runtime instead < 1763339753 654874 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :how do you know that if you hit head 1000 times, the next coin flip won't be tail? < 1763339755 968028 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this means that the running program has to recompile itself if you guessed wrong, so the program and the compiler are kind-of looped into each other < 1763339767 949982 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: you don't, but you've simulated the program with 1000 heads < 1763339785 557105 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and if it eventually hits tails, you still have the state of the program after 1000 coinflips to start from < 1763339796 893618 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you recompile a version that doesn't assume heads but continue it where it left off < 1763339802 421473 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :not sure i get it then. how does it optimize then, if it only runs with the program? < 1763339821 775339 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the optimizer runs while the program is running rather than beforehand < 1763339837 663692 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so it has to be able to change what code is running while it's running < 1763339838 502928 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :still, what can it tell about the future? < 1763339845 373939 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it doens't have to, it just has to check < 1763339863 934317 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, say after 10 heads, it thinks "I should generate code that assumes heads because it'll run faster while this run of heads continues" < 1763339867 460848 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i must be missing something. let me read that jit thing more carefully. sec. < 1763339882 130267 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :then after another 990 heads, it finds out that it was wrong – but that doesn't matter because it still ran 990 coinflips at high spee < 1763339893 783400 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which is faster than using the unoptimised version for all 1000 < 1763339897 550709 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :so basically modern cpu branch prediction? < 1763339902 114192 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes < 1763339909 124553 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :why didn't you say that? :) < 1763339918 274137 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(i did think about it too in the past) < 1763339928 594289 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because I didn't realise it was an analogy that would help (and didn't realise it was an analogy until you pointed it out) < 1763339966 990916 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :speculative execution in current CPUs does seem to be best viewed as though it were a type of JIT > 1763339983 290376 PRIVMSG #esolangs :14[[07User talk:Sawyer.go092314]]4 10 02https://esolangs.org/w/index.php?diff=168534&oldid=168533 5* 03Sawyer.go0923 5* (+148) 10 < 1763339990 984181 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i thought you'd use jit to check which future is the correct one, but probability based, sure, it should work < 1763340146 992616 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :in a way, one of the reasons my optimizing interpreter is so much faster even from others which basically do the same shtick (plain balanced loops), is because my main loop is optimized according to the instructions probabilities (cascading if-else tree), rather switch/case over the instructions. this ends up basically 2x faster almost always < 1763340249 158774 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :the interesting part is that i was sure that with switch/case, PGO would "get it" and optimize it at least as good as my manually constructed if-else tree, but far from it. not even close. < 1763340310 848538 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wonder how this compares to threaded code in terms of branch prediction efficiency? < 1763340324 888756 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :switch/case doesn't branch-predict well because all the branches are done from the same point < 1763340367 878344 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :"threaded code" is the name given for the technique where, at the end of the equivalent of each case…break of a switch, you use a separate technique for branching to the correct label from there < 1763340384 421056 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(which in practice usually seems to be a computed goto, although if-trees probably also work) < 1763340400 668360 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that way the branch predictor learns which branches tend to follow which other branches, rather than which branch is the most common overall < 1763340408 181364 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I've never tried it but I've heard good things about it < 1763340411 189243 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i understand. i don't know. i think a combination of both would get the advantage of both? > 1763340418 959942 PRIVMSG #esolangs :14[[07Luau14]]4 N10 02https://esolangs.org/w/index.php?oldid=168535 5* 03Sawyer.go0923 5* (+426) 10Created page with "Luau is not an esoteric programming language. To check it out, go to the [https://en.wikipedia.org/wiki/Luau_(programming_language) Wikipedia page] or [https://luau.org luau website]. ==See also== * [https://en.wikipedia.org/wiki/Luau_(programming_language) Luau] * [[ < 1763340427 961333 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it seems possible < 1763340491 841215 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but it _really_ surprised me that PGO over a single switch was nowhere near if-else tree. like, really. < 1763340547 688766 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :PGO is probably just checking the probabilities of each case of the switch, and if all of them are below 50%, it probably didn't change the codegen at all < 1763340564 768545 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :and the switch was as "optimized" as it can be for PGO to assess it correctly. less than 10 cases, all of them small and end in "break", sequential values starting at 0, basically everything it could want was there, but in the end, really nowhere near. < 1763340589 43716 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, maybe the compiler is better at jump-threading the if-else tree than it is at jump-threading the switch < 1763340648 240768 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :sec, let me show you the approaches. < 1763340665 837270 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this came up in Rust, the "match in a loop" method of implementing the equivalent of a computed goto is the best option Rust has atm, but it optimises poorly, and apparently that's because LLVM can't jump-thread properly through a match/switch in a loop (which is apparently because, although the code for that exists, it's too slow to turn on by default) < 1763340671 771629 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: I'm afraid to ask what multi-threaded code might be then (scnr) < 1763340686 661743 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: this is an unfortunate clash of names < 1763340709 866340 :int-e!~noone@int-e.eu PRIVMSG #esolangs :we're so bad at terminology (we = humanity, collectively) < 1763340747 619357 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I like trying to do simplifications that cross multiple levels of abstraction, but they are often hard to talk about because different levels use the same term to mean different things < 1763340814 883153 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :https://0.vern.cc/B.txt < 1763340826 540186 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :"capability" has been coming up quite a bit recently, it means three different things that are relevant to the things I'm trying to reason about (and a fourth that isn't directly relevant but could be) < 1763340864 721372 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: right, this is probably an issue with jump threading < 1763340876 55573 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :"this"? < 1763340897 131472 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually no, the compiler isn't likely to be looking at *pc < 1763340903 8856 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so jump threading wouldn't help < 1763340943 564514 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i would think it just needs to find out the probabilities of each case. < 1763340983 332097 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you might want to look at the machine code to see how it differs < 1763340996 567894 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i ran few bf programs, big and small, and noticed that the probabilities, at least with my instructions set, are largely similar < 1763341009 339341 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think PGO would help the switch/case much because it's likely to compile into the same jump table regardless of the probabiities, unless they're extremely skewed < 1763341035 402517 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :so that's how i constructed my if-else tree. it could differ with others though. e.g. in my case ADD also does zero. < 1763341080 876230 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now I'm wondering how much work a truly branchless BF interpreter would be < 1763341099 930938 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: yeah, i did want to check what it generates, but didn't get to that yet. but suffice is to say that neither gcc not clang got anywhere near with PGO. but clang got closer than gcc. < 1763341157 470898 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: surely it would not be possible? < 1763341179 431908 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :well.. i think it would not be possible < 1763341198 478735 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it should definitely be possible (except for I/O which doesn't really need optimising because it's so slow naturally), a non-optimizing interpreter could represent each opcode by amount to add to current tape element, amount to add to tape pointer, amount to add to instruction pointer if current tape element is nonzero < 1763341215 705559 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that only contains one "if" which could be replaced by a conditional select < 1763341219 991369 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but it is one of the things my code tries to minimize. almost no branching inside each of the instructions code do_XXX < 1763341250 144086 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :like, input checks for EOF, but that's almost it. > 1763341250 545634 PRIVMSG #esolangs :14[[07ErrorFull14]]4 10 02https://esolangs.org/w/index.php?diff=168536&oldid=146279 5* 03Sawyer.go0923 5* (+400) 10 < 1763341275 59015 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :your , and . will have a lot of branches inside the standard library routines you call into to do the I/O < 1763341284 305831 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :the code which runs the most if by far the instructions selector < 1763341301 503427 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :is* < 1763341337 268979 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :sure, but that's out of my control, at least until (if) i merge consecutive outputs into one < 1763341362 928859 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i did try that btw. implement line buffer inside the interpreter. nearly zero impact. < 1763341373 836851 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that isn't surprising < 1763341378 451047 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :, and . don't run often enough to need optimising < 1763341384 31910 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :well, not even nearly. i couldn't measure a diff. < 1763341404 554018 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :exactly. they're not the bottleneck. < 1763341441 481579 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :programming for when I/O is the bottleneck is really weird and significantly different from normal programming < 1763341476 340034 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I wouldn't worry about trying to micro-optimize I/O too much, when it's worth it your whole program changes < 1763341497 723844 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :so to get the fastest, it needs to minimize the code and branching to reach the next instruction code. and the if-else tree does part of it, the fact that the main loop doesn't have a stop condition is another (a specific instruction stops it - not testing the stop condition on every instruction) < 1763341544 36996 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think that's almost equivalent, the advantage to the specific instruction is that it can be on the inside of the if-else tree rather than the outside < 1763341575 602729 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :exactly. branch prediction makes it slow, but who cares < 1763341585 953405 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(i.e. exit) < 1763341630 460315 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but i didn't actually check a loop of: for (; is_exit; pc++). from the initial version my main loop was without a stop condition. < 1763341699 658896 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : it means three different things ← in case someone in the logs asks, I'll give the answer pre-emptively in advance: capability bits of a pointer that specify the range it can access; object-capabilities; "capability passing style" in which the ability to do exclusive access to a piece of memory is passed into a function and returned from that function rather than being borrowed; and the fourth is Linux capabilities which split up the various < 1763341701 115158 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :aspects of being root < 1763341712 64620 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, I should go < 1763341713 610084 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :night < 1763341722 640754 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1763341767 897502 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs ::) night > 1763342609 100688 PRIVMSG #esolangs :14[[07WORST14]]4 N10 02https://esolangs.org/w/index.php?oldid=168537 5* 03Sawyer.go0923 5* (+6129) 10Created page with "{{Infobox language | name = WORST | year = 2025 | designer = User:Creator | website = | paradigm = Esoteric, intentionally hostile | license = Public domain }} '''WORST''' is an esoteric programming language designed to be as unpleasant, counter-intuitive, and err > 1763343320 667190 PRIVMSG #esolangs :14[[07WORST14]]4 10 02https://esolangs.org/w/index.php?diff=168538&oldid=168537 5* 03Sawyer.go0923 5* (-162) 10 > 1763344328 693979 PRIVMSG #esolangs :14[[07Esolang talk:Community portal14]]4 10 02https://esolangs.org/w/index.php?diff=168539&oldid=166844 5* 03NTMDev 5* (+40) 10 > 1763344340 489751 PRIVMSG #esolangs :14[[07Esolang talk:Community portal14]]4 10 02https://esolangs.org/w/index.php?diff=168540&oldid=168539 5* 03NTMDev 5* (+17) 10/* Discord */ > 1763344660 316888 PRIVMSG #esolangs :14[[07Esolang talk:Community portal14]]4 10 02https://esolangs.org/w/index.php?diff=168541&oldid=168540 5* 03Aadenboy 5* (+331) 10 < 1763346068 194571 :simcop2387!~simcop238@perlbot/patrician/simcop2387 JOIN #esolangs simcop2387 :ZNC - https://znc.in < 1763346310 552310 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot JOIN #esolangs perlbot :ZNC - https://znc.in < 1763346757 277259 :amby!~ambylastn@host-81-178-154-63.as13285.net QUIT :Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement > 1763347357 495296 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168542&oldid=168527 5* 03NTMDev 5* (+507) 10/* sort */ > 1763347451 306558 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168543&oldid=168542 5* 03NTMDev 5* (+89) 10/* String Checkers */ > 1763347483 106376 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168544&oldid=168543 5* 03NTMDev 5* (+56) 10/* String Checkers */ > 1763347715 579373 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168545&oldid=168544 5* 03NTMDev 5* (+482) 10/* String Checkers */ > 1763347934 429841 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168546&oldid=168545 5* 03NTMDev 5* (+158) 10 > 1763352930 504632 PRIVMSG #esolangs :14[[07Resubmit14]]4 10 02https://esolangs.org/w/index.php?diff=168547&oldid=168237 5* 03Yayimhere2(school) 5* (+86) 10/* Semantics */ > 1763352946 715045 PRIVMSG #esolangs :14[[07Resubmit14]]4 10 02https://esolangs.org/w/index.php?diff=168548&oldid=168547 5* 03Yayimhere2(school) 5* (-6) 10/* Semantics */ < 1763354260 874033 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu QUIT :Ping timeout: 256 seconds > 1763354275 203710 PRIVMSG #esolangs :14[[07Bitty14]]4 10 02https://esolangs.org/w/index.php?diff=168549&oldid=168192 5* 03Nomnomnom 5* (+159) 10added comptational class < 1763356985 112258 :impomatic!~impomatic@82.132.185.149 QUIT :Ping timeout: 250 seconds < 1763358802 591505 :int-e_!~noone@int-e.eu JOIN #esolangs int-e :Bertram < 1763358816 307206 :op_4_!~tslil@2a01:4f8:c0c:7952::1 JOIN #esolangs * :op_4 < 1763358857 417261 :pool2!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1763359001 195200 :pool!~nathan@user/PoolloverNathan QUIT :Ping timeout: 256 seconds < 1763359001 409546 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot QUIT :Ping timeout: 256 seconds < 1763359001 437198 :int-e!~noone@int-e.eu QUIT :Ping timeout: 256 seconds < 1763359001 464779 :op_4!~tslil@user/op-4/x-9116473 QUIT :Ping timeout: 256 seconds < 1763359001 464838 :slavfox!~slavfox@193.28.84.32 QUIT :Ping timeout: 256 seconds < 1763359001 886388 :pool2!~nathan@user/PoolloverNathan NICK :pool < 1763359003 168835 :op_4_!~tslil@2a01:4f8:c0c:7952::1 NICK :op_4 < 1763359003 552966 :Melvar!~melvar@dslc-082-082-054-197.pools.arcor-ip.net QUIT :Ping timeout: 256 seconds < 1763359095 970813 :slavfox!~slavfox@193.28.84.32 JOIN #esolangs slavfox :slavfox < 1763359163 827696 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot JOIN #esolangs perlbot :ZNC - https://znc.in < 1763359831 894663 :Melvar!~melvar@dslc-082-082-054-197.pools.arcor-ip.net JOIN #esolangs Melvar :melvar < 1763360525 326371 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1763360652 980093 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1763361507 99895 :impomatic!~impomatic@82.132.186.245 JOIN #esolangs * :[https://web.libera.chat] impomatic > 1763362020 85525 PRIVMSG #esolangs :14[[07Sorted!14]]4 10 02https://esolangs.org/w/index.php?diff=168550&oldid=38970 5* 03Tpaefawzen 5* (+84) 10/* External resources */ +1 > 1763362792 197977 PRIVMSG #esolangs :14[[07JUSTIF14]]4 10 02https://esolangs.org/w/index.php?diff=168551&oldid=91381 5* 03Tpaefawzen 5* (+58) 10/* External resources */ +1 > 1763365981 255376 PRIVMSG #esolangs :14[[07Vixen14]]4 10 02https://esolangs.org/w/index.php?diff=168552&oldid=166918 5* 03Corbin 5* (+5) 10/* Core */ Clean up quotation marks. > 1763366328 156828 PRIVMSG #esolangs :14[[07Vixen14]]4 10 02https://esolangs.org/w/index.php?diff=168553&oldid=168552 5* 03Corbin 5* (+401) 10/* Objects */ More precisely explain parents and delegation as well as the asterisk convention. < 1763366817 220407 :impomatic!~impomatic@82.132.186.245 QUIT :Quit: Client closed > 1763367056 542899 PRIVMSG #esolangs :14[[07Vixen14]]4 M10 02https://esolangs.org/w/index.php?diff=168554&oldid=168553 5* 03Corbin 5* (+0) 10/* Cloning */ Fix flag to execlineb. Yes, it almost doesn't matter. Yes, it can be the cause of subtle bugs when chaining calls. < 1763367981 463153 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1763368287 906861 :tromp!~textual@2001:1c00:3487:1b00:a876:2676:366b:2d63 JOIN #esolangs * :Textual User < 1763372709 917303 :Taneb!~username@host-79-43-26-190.retail.telecomitalia.it JOIN #esolangs Taneb :realname < 1763374669 432539 :APic!apic@apic.name PRIVMSG #esolangs :Hi < 1763375632 101335 :impomatic!~impomatic@ip-217-65-134-19.ptr.icomera.net JOIN #esolangs * :[https://web.libera.chat] impomatic > 1763376692 301565 PRIVMSG #esolangs :14[[07Contains everything14]]4 10 02https://esolangs.org/w/index.php?diff=168555&oldid=168451 5* 03C++DSUCKER 5* (+40) 10I changed my mind, the langauge should no longer be allowed to be recursive. i wil add a finite recursion operator. < 1763376801 337015 :tromp!~textual@2001:1c00:3487:1b00:a876:2676:366b:2d63 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1763376902 372623 PRIVMSG #esolangs :14[[07Contains everything14]]4 10 02https://esolangs.org/w/index.php?diff=168556&oldid=168555 5* 03C++DSUCKER 5* (+9) 10 < 1763377321 549797 :tromp!~textual@2001:1c00:3487:1b00:a876:2676:366b:2d63 JOIN #esolangs * :Textual User < 1763378153 3729 :impomatic!~impomatic@ip-217-65-134-19.ptr.icomera.net QUIT :Quit: Client closed < 1763379269 266437 :int-e_!~noone@int-e.eu NICK :int-e < 1763380422 297165 :Everything!~Everythin@88.155.1.132 JOIN #esolangs Everything :Everything < 1763382741 152917 :tromp!~textual@2001:1c00:3487:1b00:a876:2676:366b:2d63 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1763382987 269789 :Taneb!~username@host-79-43-26-190.retail.telecomitalia.it QUIT :Ping timeout: 252 seconds < 1763383444 319062 :Taneb!~username@host-79-43-26-190.retail.telecomitalia.it JOIN #esolangs Taneb :realname < 1763383726 629928 :tromp!~textual@2001:1c00:3487:1b00:a876:2676:366b:2d63 JOIN #esolangs * :Textual User < 1763385512 102867 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :int-e: i managed to improve my COND (==1) so that: 1. one '-' and one '+' instead of two of each. 2. restore the original value before entering the COND block. 1/2 combined is less complex (easier to document) and less moves/instructions (-4 chars). i think i'm now reasonably happy with it (bottom version). i said i really like your "one COND" approach... https://0x0.st/KfTu.txt < 1763385634 933839 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :cheers < 1763385763 748453 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1763385790 984664 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1763386291 61420 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1763386738 179216 :tromp!~textual@2001:1c00:3487:1b00:a876:2676:366b:2d63 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1763388355 445799 :tromp!~textual@2001:1c00:3487:1b00:a876:2676:366b:2d63 JOIN #esolangs * :Textual User < 1763389354 129660 :impomatic!~impomatic@95.147.193.63 JOIN #esolangs * :[https://web.libera.chat] impomatic < 1763389615 100355 :impomatic!~impomatic@95.147.193.63 QUIT :Ping timeout: 250 seconds > 1763390642 615922 PRIVMSG #esolangs :14[[07Luau14]]4 10 02https://esolangs.org/w/index.php?diff=168557&oldid=168535 5* 03Sawyer.go0923 5* (+4) 10 < 1763391984 446522 :Taneb!~username@host-79-43-26-190.retail.telecomitalia.it QUIT :Ping timeout: 244 seconds < 1763392613 99749 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs * :[https://web.libera.chat] wob_jonas < 1763392973 808381 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1763392991 840280 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: re match in a loop optimizes badly, that sounds omnious because I want to compile Enchain into C (or C++) switch in a loop. this works better in C than in Rust because C switch has fallthrough between a cases, so when the Enchain code has a conditional jump it compiles to setting a variable to the target then a conditional break. < 1763393096 601257 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1763393541 859456 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :normally you'd just compile into if{goto} in C. I was thinking of a switch because for some reason I put it into my head that I want to allow nested functions and that you should be able to goto out from a function, so when that happens the compiled C function would return an integer telling the label to jump to, or zero to continue execution < 1763393542 359460 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :normally. this is almost certainly a bad idea, I shouldn't do it, I don't think my original motivation for it is valid, and even if I do allow it it would be easier to just add a small switch{goto} at every call side of such a function, because most nested functions that you write in practice will have only very few jump targets. < 1763393730 413095 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wob_jonas: you can avoid the performance penalty by manually using gotos between the switch arms rather than going round the loop < 1763393743 867080 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :even if the switch and loop exist, nothing forces you to use them, you can just goto instead < 1763393802 652317 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :exactly, and I shouldn't use the looped switch at all, I should just compile to goto, if{goto}, switch{goto} in C. < 1763393829 525855 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :if I don't use the case labels then I don't need the switch in first place < 1763393896 833619 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed < 1763393909 99521 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs * :[https://web.libera.chat] wob_jonas < 1763393932 341922 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :the switch would be needed if I allowed jumps with runtime-computed targets, which I probably could do but probably shouldn't do. I should make all label values compile-time constants. < 1763393951 535808 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I mean all label values in Enchain compile-time consants. < 1763394017 46149 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ok, so then the big looped switch for the whole function body is just a bad idea that I confused myself into < 1763394038 264243 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw I don't know why compilers find it hard to optimise a loop-switch where an arm specifies a value for the switch constant on the next iteration into a direct goto between branches < 1763394058 105040 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I've been told it's hard to get that particular optimisation to run efficiently, but don't know why < 1763394392 407245 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: I was told that rust doesn't have a goto built-in because it would be hard to teach the old lifetime checker to handle it correctly, but the old lifetime checker isn't even around anymore so I'm not sure that applies. But at least even if goto is easy to compile in C, if you want to compile it in C++ the compiler has to figure out which < 1763394392 907045 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :local variables to destroy (and prove that no local variables have to be initialized, that would be a compile error). I imagine there might be a similar but harder problem in rust, because in general the compiler has to update the initialized flags for all local variables, and it's very important that the compiler understands the control flow well < 1763394393 407496 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :enough that it can completely optimize out initialized flags or their updates almost all the time. < 1763394445 136168 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the current plans for Rust is to have some way to mark the end of a branch of a loop-switch to say that it's actually meant to be compiled as a goto < 1763394454 805121 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, a loop-match < 1763394496 201214 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so that all the borrow checking, drop flags, etc. can be done on the loop-match and then all that changes is the code generation < 1763394525 520052 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :oh yeah, "drop flags" is what they're called < 1763394927 96151 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: I don't think that works. I thought the problem was that the liveness checker needs to understand goto to understand arbitrary control flow involving goto, because if it's phrased as loop-switch then the necessary information is hidden in some state variable of whose value the liveness checker doesn't need to track. < 1763394968 10506 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wob_jonas: well there may be false positives (i.e. programs that would be sound but are rejected) doing it this way, but that doesn't create any soundness holes < 1763394984 300991 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :sure < 1763395017 795659 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but then couldn't it also create cases when the compiler doesn't optimize away drop flags properly for the same reason? < 1763395097 210586 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wob_jonas: possibly but I don't think that's seen as an issue < 1763395148 117825 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :since gotos and conditional gotos (as well as function calls and function returns) are the main form of control flow in Enchain, I want the typechecker to understand the control flow, as in for each point statement I want to know what the next statement executed after it can be. this is why I shouldn't have computed gotos (or function pointers), < 1763395148 616814 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :those make the control flow almost impossible to follow. < 1763395208 940147 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and the control flow graph seems an easier abstraction to understand than the high-level control structures like if/while anyway < 1763395760 3415 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed < 1763396582 512903 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer > 1763396655 439938 PRIVMSG #esolangs :14[[07Iterate/Math14]]4 10 02https://esolangs.org/w/index.php?diff=168558&oldid=168500 5* 03Aadenboy 5* (-425) 10turning these into modules < 1763396697 981499 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan > 1763396935 346167 PRIVMSG #esolangs :14[[07!frjnrehrbwgyrigbyieurgbyfaerkhbvrwgtr.14]]4 10 02https://esolangs.org/w/index.php?diff=168559&oldid=168532 5* 03Yayimhere2(school) 5* (+5) 10correct comp class < 1763396962 808422 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 246 seconds < 1763397088 373019 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord > 1763397194 454415 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168560&oldid=168546 5* 03NTMDev 5* (-5) 10/* = */ > 1763397659 84372 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168561&oldid=168560 5* 03NTMDev 5* (+833) 10/* String Operations 2 */ < 1763397882 870244 :pool!~nathan@user/PoolloverNathan QUIT :Ping timeout: 256 seconds < 1763398400 672944 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1763398717 112847 :impomatic!~impomatic@2a00:23c7:5fc6:3201:d47e:4930:d4db:2a71 JOIN #esolangs * :[https://web.libera.chat] impomatic > 1763400366 256668 PRIVMSG #esolangs :14[[07Iterate/Math14]]4 10 02https://esolangs.org/w/index.php?diff=168562&oldid=168558 5* 03Aadenboy 5* (-727) 10fixes < 1763400992 653384 :impomatic!~impomatic@2a00:23c7:5fc6:3201:d47e:4930:d4db:2a71 QUIT :Quit: Client closed < 1763401650 1076 :amby!~ambylastn@host-81-178-154-63.as13285.net JOIN #esolangs * :realname < 1763401882 109145 :impomatic!~impomatic@2a00:23c7:5fc6:3201:d47e:4930:d4db:2a71 JOIN #esolangs * :[https://web.libera.chat] impomatic < 1763402112 954959 :sytra!~sytra@94.156.52.18 JOIN #esolangs * :Jordan > 1763403903 483538 PRIVMSG #esolangs :14[[07Iterate/Compilation14]]4 10 02https://esolangs.org/w/index.php?diff=168563&oldid=168510 5* 03Aadenboy 5* (+518) 10extra < 1763404084 278885 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu JOIN #esolangs b_jonas :b_jonas < 1763404284 888041 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ok, so there's a big problme with what I thought about Enchain gotos. we can't just have labels behave as zero-sized values whose types encode their label, because then figuring out the possible control flow and typechecking would mutually depend on each other. there are restricted versions of this that could work, but I have to figure out which, if any, are checkable at compile time, expressive enough, < 1763404290 895845 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :and don't feel kludgey like labels are completely unrelated to names. thank you #esolangs in the role of rubber duck. < 1763405011 182328 :amby!~ambylastn@host-81-178-154-63.as13285.net QUIT :Read error: Connection reset by peer < 1763406390 99743 :impomatic49!~impomatic@2a00:23c7:5fc6:3201:a4ef:c9e:43c:f50e JOIN #esolangs * :[https://web.libera.chat] impomatic < 1763406395 412605 :amby!~ambylastn@host-81-178-154-63.as13285.net JOIN #esolangs * :realname < 1763406489 99510 :impomatic!~impomatic@2a00:23c7:5fc6:3201:d47e:4930:d4db:2a71 QUIT :Ping timeout: 250 seconds < 1763406926 452842 :tromp!~textual@2001:1c00:3487:1b00:a876:2676:366b:2d63 QUIT :Read error: Connection reset by peer < 1763407398 743902 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1763407422 839132 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1763408147 975059 :sytra!~sytra@94.156.52.18 QUIT :Quit: sytra < 1763409259 979160 :sytra!~sytra@94.156.52.18 JOIN #esolangs * :Jordan > 1763409613 100031 PRIVMSG #esolangs :14[[07Iterate/Math14]]4 10 02https://esolangs.org/w/index.php?diff=168564&oldid=168562 5* 03Aadenboy 5* (+547) 10/* Logic */ < 1763411004 193434 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1763411022 599452 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1763411874 321593 :impomatic49!~impomatic@2a00:23c7:5fc6:3201:a4ef:c9e:43c:f50e QUIT :Quit: Client closed < 1763411905 497031 :Everything!~Everythin@88.155.1.132 QUIT :Quit: Lost terminal > 1763412044 599016 PRIVMSG #esolangs :14[[07G Sharp14]]4 M10 02https://esolangs.org/w/index.php?diff=168565&oldid=154461 5* 03Ractangle 5* (-54) 10/* Functions */ > 1763412088 452254 PRIVMSG #esolangs :14[[07G Sharp14]]4 10 02https://esolangs.org/w/index.php?diff=168566&oldid=168565 5* 03Ractangle 5* (-5) 10/* Truth-machine */ > 1763412158 910850 PRIVMSG #esolangs :14[[07Iterate/Math14]]4 10 02https://esolangs.org/w/index.php?diff=168567&oldid=168564 5* 03Aadenboy 5* (+430) 10 > 1763412172 13693 PRIVMSG #esolangs :14[[07Iterate/Math14]]4 M10 02https://esolangs.org/w/index.php?diff=168568&oldid=168567 5* 03Aadenboy 5* (+2) 10/* Minimum/maximum of A and B */ h3 > 1763412323 450553 PRIVMSG #esolangs :14[[07G Sharp14]]4 M10 02https://esolangs.org/w/index.php?diff=168569&oldid=168566 5* 03Ractangle 5* (+260) 10/* Functions */ > 1763412443 303899 PRIVMSG #esolangs :14[[07True (Ractangle)14]]4 M10 02https://esolangs.org/w/index.php?diff=168570&oldid=163114 5* 03Ractangle 5* (-149) 10/* Infinite loop */ > 1763412503 404903 PRIVMSG #esolangs :14[[07GTA614]]4 M10 02https://esolangs.org/w/index.php?diff=168571&oldid=168481 5* 03Ractangle 5* (-1) 10 < 1763414497 109485 :impomatic!~impomatic@2a00:23c7:5fc6:3201:a4ef:c9e:43c:f50e JOIN #esolangs * :[https://web.libera.chat] impomatic < 1763415457 792773 :APic!apic@apic.name PRIVMSG #esolangs :Good Night * 😴 < 1763415825 808340 :JAA!~JAA@user/meow/JAA NICK :jinn7 < 1763415839 986434 :jinn7!~JAA@user/meow/JAA NICK :JAA < 1763416729 848664 :ais523!~ais523@user/ais523 QUIT :Quit: quit > 1763417119 382267 PRIVMSG #esolangs :14[[07Iterate/Math14]]4 10 02https://esolangs.org/w/index.php?diff=168572&oldid=168568 5* 03Aadenboy 5* (+221) 10/* If else */ < 1763417380 304088 :sytra!~sytra@94.156.52.18 QUIT :Remote host closed the connection < 1763417565 472176 :impomatic!~impomatic@2a00:23c7:5fc6:3201:a4ef:c9e:43c:f50e QUIT :Quit: Client closed > 1763419017 221612 PRIVMSG #esolangs :14[[07User:Buckets14]]4 M10 02https://esolangs.org/w/index.php?diff=168573&oldid=168512 5* 03Buckets 5* (+13) 10 > 1763419073 351263 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=168574&oldid=168513 5* 03Buckets 5* (+14) 10 > 1763419092 943055 PRIVMSG #esolangs :14[[07BeeJazz14]]4 N10 02https://esolangs.org/w/index.php?oldid=168575 5* 03Buckets 5* (+1783) 10Created page with "BeeJazz is an Esoteric Programming language created By [[User:Buckets]] in 2020, after They watched [https://en.wikipedia.org/wiki/Bee_Movie / A Certain Movie featuring bees And jazz.] {| class="wikitable" |- ! Commands !! Instructions |- | B || Assign The current hexe > 1763419113 558658 PRIVMSG #esolangs :14[[07BeeJazz14]]4 M10 02https://esolangs.org/w/index.php?diff=168576&oldid=168575 5* 03Buckets 5* (-2) 10 > 1763419140 484340 PRIVMSG #esolangs :14[[0711001000010011011001014]]4 10 02https://esolangs.org/w/index.php?diff=168577&oldid=147808 5* 03Kaveh Yousefi 5* (+614) 10Added a hyperlink to my implementation of the 110010000100110110010 programming language on GitHub and altered the Unimplemented tag to Implemented. < 1763419498 101832 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 JOIN #esolangs DOS_User :[https://web.libera.chat] DOS_User_webchat < 1763421018 241968 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1763421041 397864 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1763421183 535737 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 QUIT :Remote host closed the connection < 1763421348 311968 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1763421355 386937 :pool6!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1763422242 886616 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1763423245 517160 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :int-e: "if (==0) BODY": < 1763423245 544418 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs : int-e (3 tmps): >+<[>->]>[>>]<<[-< BODY >]< < 1763423245 544460 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs : avih (2 tmps): >+<[>-]>[-< BODY >>]<< < 1763423408 955679 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :and this can also be used with your 1-COND while loop, resulting in much much shorter code, which can still be used as a generic template (in my case COND is (==1), which does need 2 '-' and 2 '+') < 1763423463 840546 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(i do need both "if (==0) BODY" and "while (==1) BODY") < 1763423784 702487 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :the "trick" to use only 2 tmps is that the BODY "if" is also unbalanced. < 1763423862 84732 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :well, both have 2 unbalanced while/end, but with two tmps the other one is instead together with BODY.