> 1742949566 927966 PRIVMSG #esolangs :14[[07Topple14]]4 10 02https://esolangs.org/w/index.php?diff=154533&oldid=154510 5* 03H33T33 5* (-42) 10
> 1742949716 34147 PRIVMSG #esolangs :14[[07User:H33T3314]]4 M10 02https://esolangs.org/w/index.php?diff=154534&oldid=152196 5* 03H33T33 5* (+12) 10/* Experience */
> 1742950329 895670 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Hazel 5*  10New user account
> 1742950455 537577 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 M10 02https://esolangs.org/w/index.php?diff=154535&oldid=154478 5* 03Hazel 5* (+111) 10Hello, world -Hazel
> 1742950517 901345 PRIVMSG #esolangs :14[[07User:Hazel14]]4 N10 02https://esolangs.org/w/index.php?oldid=154536 5* 03Hazel 5* (+48) 10Created page with "== hazel ==  transfem lesbian, she/her. the end."
> 1742950762 633140 PRIVMSG #esolangs :14[[07User:Aadenboy/Zerons14]]4 M10 02https://esolangs.org/w/index.php?diff=154537&oldid=154531 5* 03Aadenboy 5* (+0) 10/* Further */ mistake
> 1742952258 659929 PRIVMSG #esolangs :14[[07Rivulet14]]4 10 02https://esolangs.org/w/index.php?diff=154538&oldid=154500 5* 03Rottytooth 5* (+2625) 10Added more syntax
> 1742952553 116790 PRIVMSG #esolangs :14[[07Rivulet14]]4 10 02https://esolangs.org/w/index.php?diff=154539&oldid=154538 5* 03Rottytooth 5* (+361) 10Adding images
> 1742952918 805581 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 upload10 02 5* 03Rottytooth 5*  10uploaded "[[02File:Rivulet Fibonacci1.png10]]": A Fibonacci program in the Rivulet language
> 1742952970 105081 PRIVMSG #esolangs :14[[07Rivulet14]]4 10 02https://esolangs.org/w/index.php?diff=154541&oldid=154539 5* 03Rottytooth 5* (+0) 10
> 1742952973 34379 PRIVMSG #esolangs :14[[07Goog14]]4 N10 02https://esolangs.org/w/index.php?oldid=154542 5* 03Hazel 5* (+2271) 10Add Esolang "Goog"
> 1742953011 68562 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 upload10 02 5* 03Rottytooth 5*  10uploaded "[[02File:Rivulet Fibonacci2.png10]]"
> 1742953070 158587 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 upload10 02 5* 03Rottytooth 5*  10uploaded "[[02File:Rivulet Fibonacci4.png10]]": Another Fibonacci program in Rivulet
> 1742953338 569298 PRIVMSG #esolangs :14[[07UT1914]]4 10 02https://esolangs.org/w/index.php?diff=154545&oldid=122761 5* 03Stkptr 5* (+327) 10/* The production rules of UT19 */ Add more typical alphabetical version for clarity
> 1742953474 899265 PRIVMSG #esolangs :14[[07Rivulet14]]4 10 02https://esolangs.org/w/index.php?diff=154546&oldid=154541 5* 03Rottytooth 5* (+151) 10Added images
> 1742953508 518199 PRIVMSG #esolangs :14[[07Rivulet14]]4 10 02https://esolangs.org/w/index.php?diff=154547&oldid=154546 5* 03Rottytooth 5* (+0) 10Resized images
> 1742953784 388832 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=154548&oldid=154523 5* 03Hazel 5* (+11) 10/* G */  - Add Goog
< 1742961161 250733 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :The IPv6 saga continues: DigitalOcean has now (politely) told me to go complain to my ISP instead. Well, there's still a "different team" investigating it from their end, but still.
< 1742961189 766126 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :So I filed a support ticket with my ISP, and hit the size limit of their web form, and after clicking submit the report just... disappeared.
< 1742961208 1102 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :So I've sent them an email instead, because at least that doesn't have silly-short size limits.
< 1742961307 439141 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :But I'm pessimistically expecing I have to go through the standard support script of "have you tried restarting your router?" and (once they learn I'm not actually using the one they supplied) the request to switch back to their dinky box, no matter how clear it seems to be that the problem's _between_ the ISP and DigitalOcean networks, not at either end.
< 1742961396 405524 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :And I guess to be fair, it's not entirely impossible that, I don't know, their "Hyperhub" does some special magic in the DHCPv6 prefix delegation request that enables this one particular route to also work.
< 1742961436 342571 :int-e!~noone@int-e.eu PRIVMSG #esolangs :heh that could be the worst outcome
< 1742961614 471323 :int-e!~noone@int-e.eu PRIVMSG #esolangs :. o O ( haunted IPv6 routing )
> 1742964776 665075 PRIVMSG #esolangs :14[[07Goog14]]4 10 02https://esolangs.org/w/index.php?diff=154549&oldid=154542 5* 03Stkptr 5* (-230) 10Fix categories, no looping so it's total, also no conditionals
< 1742965723 710011 :ais523!~ais523@user/ais523 QUIT :Quit: quit
< 1742966844 408641 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I wanted to make up a pokemon battle with each side only having one pokemon remaining, of which the first one has a move with recoil damage (or Life Orb) that will knock itself out, and knock out the second pokemon iff it scores a critical hit, but the second pokemon is faster, and confused and will knock itself out if it attacks itself due to confusion but has a move that will defeat the first one in one hit.
< 1742966937 268205 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Furthermore, the second one must be allowed to learn Roar or Whirlwind, and the first one does not have any move without recoil damage that it is able to select.
< 1742967007 674275 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Do you know?
< 1742970129 921797 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :(Actually, it is probably not necessary for the confusion damage to knock out yourself in one hit, but it must knock you out when added to the minimum damage caused by the opponent's attack.)
< 1742970976 647082 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer
< 1742971392 382670 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :On TI-92, newList(0) is an error even though logically it would be sense to be valid (to make a empty list), I think.
< 1742973301 191703 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
< 1742973368 934613 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 268 seconds
< 1742973383 470400 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life
> 1742974937 763404 PRIVMSG #esolangs :14[[07Table14]]4 M10 02https://esolangs.org/w/index.php?diff=154550&oldid=148527 5* 03Rdococ 5* (-47) 10/* Semantics */
> 1742977900 742842 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 upload10 02 5* 03BerdiesLuvr 5*  10uploaded "[[02File:L'toile Noire.png10]]"
< 1742979308 400442 :b_jonas!~x@88.87.242.184 QUIT :Quit: leaving
< 1742982143 215900 :sirikon!~sirikon@2403:6200:8892:5d20:5d90:6403:b526:bacc JOIN #esolangs * :[https://web.libera.chat] sirikon
< 1742982192 379144 :sirikon!~sirikon@2403:6200:8892:5d20:5d90:6403:b526:bacc QUIT :Client Quit
< 1742982213 254013 :sirikon!~sirikon@2403:6200:8892:5d20:5d90:6403:b526:bacc JOIN #esolangs * :[https://web.libera.chat] sirikon
< 1742982290 171174 :sirikon!~sirikon@2403:6200:8892:5d20:5d90:6403:b526:bacc QUIT :Client Quit
< 1742985389 487421 :rodgort!~rodgort@static.38.6.217.95.clients.your-server.de QUIT :Ping timeout: 244 seconds
< 1742987716 917001 :rodgort!~rodgort@static.38.6.217.95.clients.your-server.de JOIN #esolangs * :rodgort
< 1742988778 215302 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
< 1742988876 636578 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :re https://logs.esolangs.org/libera-esolangs/2025-03-24.html#lub the "Edg/" thing is correct, https://dpaste.com/C2XPZU8K2.txt has request headers I got from actual browsers on windows. These are headers for a request to an unknown host, so probably not quite the same as the typical headers that browsers send, where they already know they can send
< 1742988877 136819 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :HTTP2 or SSL or whatever.
< 1742988906 56299 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :the user agent string says: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36 Edg/133.0.0.0
< 1742989169 48021 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :so yes, that has quite a few brand names in there. we should make one that also says Netscape Firebird MSIE Opera in the same line.
< 1742989262 427701 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Latest charts: https://zem.fi/tmp/errors3.png -- nice stair-step pattern there. So still happening, sporadically.
< 1742990983 373509 :craigo!~craigo@user/craigo JOIN #esolangs craigo :realname
> 1742996006 71834 PRIVMSG #esolangs :14[[07UserEdited14]]4 10 02https://esolangs.org/w/index.php?diff=154552&oldid=154100 5* 03Hotcrystal0 5* (+508) 10
> 1742996025 947393 PRIVMSG #esolangs :14[[07UserEdited14]]4 10 02https://esolangs.org/w/index.php?diff=154553&oldid=154552 5* 03Hotcrystal0 5* (+1) 10
> 1742996053 383133 PRIVMSG #esolangs :14[[07UserEdited/Versions14]]4 10 02https://esolangs.org/w/index.php?diff=154554&oldid=154081 5* 03Hotcrystal0 5* (+35) 10
< 1742996676 105944 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Ping timeout: 264 seconds
< 1742996725 561180 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse
> 1742997479 374240 PRIVMSG #esolangs :14[[07User:JIT14]]4 10 02https://esolangs.org/w/index.php?diff=154555&oldid=154423 5* 03JIT 5* (+336) 10
> 1742997692 645193 PRIVMSG #esolangs :14[[07Fontmess14]]4 10 02https://esolangs.org/w/index.php?diff=154556&oldid=154408 5* 03JIT 5* (+33) 10
> 1742998402 698617 PRIVMSG #esolangs :14[[07Rivulet14]]4 M10 02https://esolangs.org/w/index.php?diff=154557&oldid=154547 5* 03Rottytooth 5* (+43) 10/* Strand Types */
> 1742998519 44004 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=154558&oldid=154548 5* 03Rottytooth 5* (+14) 10Added Rivulet
> 1742998599 444939 PRIVMSG #esolangs :14[[07User:Rottytooth14]]4 10 02https://esolangs.org/w/index.php?diff=154559&oldid=152628 5* 03Rottytooth 5* (+31) 10Lang list
> 1742999175 354091 PRIVMSG #esolangs :14[[07User:PrySigneToFry/Sandbox/Draft of EtPL14]]4 10 02https://esolangs.org/w/index.php?diff=154560&oldid=154501 5* 03PrySigneToFry 5* (+838) 10
> 1742999521 605245 PRIVMSG #esolangs :14[[07Rivulet14]]4 10 02https://esolangs.org/w/index.php?diff=154561&oldid=154557 5* 03Rottytooth 5* (+84) 10/* Example */
> 1742999536 820249 PRIVMSG #esolangs :14[[07Rivulet14]]4 10 02https://esolangs.org/w/index.php?diff=154562&oldid=154561 5* 03Rottytooth 5* (+1) 10/* Example */
< 1742999850 390286 :FreeFull!~freefull@79.186.3.8.ipv4.supernova.orange.pl JOIN #esolangs FreeFull :FreeFull
> 1743001201 662760 PRIVMSG #esolangs :14[[07User:Aadenboy/Zerons14]]4 10 02https://esolangs.org/w/index.php?diff=154563&oldid=154537 5* 03Aadenboy 5* (-809) 10/* \sqrt{q}? */ hang on that's wrong
< 1743002074 421147 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net JOIN #esolangs amby :realname
< 1743004452 943990 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1743006562 51809 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed
> 1743006571 783307 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Ilikeundertale 5*  10New user account
> 1743008051 801093 PRIVMSG #esolangs :14[[07Waduzitdo14]]4 M10 02https://esolangs.org/w/index.php?diff=154564&oldid=130315 5* 03Krolkrol 5* (+123) 10
< 1743008310 549751 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Curses. I've seen the end of programming. I'm adding "set up a co-op that can fund the next stage of software development" to my topics to chat with my lawyer about.
< 1743008334 125898 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I've been chewing on "Galois Theory of Algorithms" https://arxiv.org/abs/1011.0014 and thinking about what it means for writing a program.
< 1743008378 846394 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Let's say that I'm hacking in some cruddy imperative "close-to-the-metal" ALGOL descendant. There are few automorphisms which fix the semantic behavior of programs in that language, because almost every statement is fully dependent on almost every other prior statement. We call this "data-dependent control flow".
< 1743008446 242448 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yanofsky proposes three reasonable operations, and notes that we can take a quotient of programs based on the requirement that these operations commute. The operations are "bracket" (product), primitive recursion, and sequential composition.
< 1743008486 861320 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So, for example, if we have a program like `x += 1; y += 2;` then we can note that the lack of data dependency between the two statements allows us to find an automorphism respecting composition sending it to `y += 2; x += 1;`
< 1743008533 519313 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I'll skip the category theory. It's shown that we can decide equivalence of programs given bracket and composition, but *not* with primitive recursion.
< 1743008587 319450 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It's also known that the "initial operations" generated by these three operations include building every natural number, and thus that the automorphisms ought to respect those operations; a program that outputs 5 should never be considered equivalent to a program which doesn't output 5.
< 1743008661 414361 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Finishing the background, Yanofsky gives the punchline that the automorphism group under all three ops is the trivial group; there are programs whose behavior isn't equivalent to others under these three reasonable ways of combining programs.
< 1743008704 103041 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This isn't in any fancy computational model. It's Kleene's primitive-recursive functionals. The same stuff used in HOL or Cammy or Peano arithmetic.
< 1743008799 791587 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Here's what I just realized. Let some monad carry our imperative language's effects. The monad freely gives a Kleisli category, *which has composition*. We usually compute over sets, over which all monads are strong, so we freely *have a bracket*.
< 1743008919 209136 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So, given some equivalence of imperative programs, Yanofsky says that we also have an equivalence of arrows in the Kleisli category. But they also say that if we add primitive recursion for those arrows, then we can't compute the equivalence any longer.
< 1743008986 711670 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But primitive recursion in a category is merely repeated composition. So this means that we can't even compare equivalence of programs under indefinitely-repeated composition, which makes sense if you know about e.g. mortal-matrix problems.
< 1743009217 398146 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It's not quite a slogan, but: Sometimes a program will not be computably equivalent to any other program, even any other program which computes the same function.
< 1743009293 814795 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This is kind of like making Rice's theorem worse, and also kind of like an irreducible-control-flow lemma.
< 1743009510 998633 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...It's also obviously a little wrong, in the sense that given some total program P, some composition c() and some identity program I, c(P,I) ≈ P, and even for partial P, c(I,P) ≈ P. So we need some sort of size to give order and metric, and then restate "sometimes, the *smallest* program computing some function..."
< 1743009683 581318 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Anyway, my big insight is that we currently write *programs*, and we have trouble not doing that because sometimes we can't (efficiently??) express certain *functions* without getting into machine-specific details.
< 1743009742 376140 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Obviously we want to write *algorithms* since the 60s and *functions* since the 80s. Yes. But how? We know programs are surjective on algorithms are surjective on functions, but that doesn't somehow ease the task of actually picking out a program for a particular function.
< 1743009846 695749 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Functions and algorithms both give genuine categories; we *can* decompose them with the three ops. But we can't do that for programs. So instead our compilers all work in subsets of the languages that support "calling conventions" and "procedures" and other ways of reusing and compressing code.
< 1743009947 40736 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Since we can't stop paying those costs, we call them "interpretative overhead" and brag about how our "Jones-optimal partial evaluator" can remove them, asymptotically, probably. We complain about how "intrinsics" perform an object-register mapping and never consider whether ORMs are necessary.
< 1743010237 201771 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This is also the root of the split between MLs. I've long struggled to see why Haskell, OCaml, etc. have efficient runtimes and also aren't eta- or beta-equivalent, and meanwhile Idris, Adga, Coq, etc. are pure type systems that are not fast and must undergo extraction for speed. If we note that the latter have a vague concept of program equivalence, then it's somewhat obvious what's going on: the latter are program-oriented, not function-oriented
< 1743010237 313503 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :!
< 1743010308 897655 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...Yes, thanks IRC. Anyway, this suggests that e.g. Rust in the former camp and therefore can't save software development because it lacks nice composition properties. It also suggests that e.g. Cammy is in the latter camp, and indeed it's only fast because of extraction with a JIT. I'm open to frame challenges but this is explaining more than it's obscuring.
< 1743010781 556780 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: reading your messages now
< 1743010866 438243 :ajal!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net JOIN #esolangs * :realname
< 1743010866 540977 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net QUIT :Read error: Connection reset by peer
< 1743010906 93990 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I think I have my own thoughts about this sort of thing, but they don't contradict yours
< 1743010999 40753 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :recently I've been viewing programming through a lens of a) trying to make subprograms into pure functions as much as possible, with any effects encoded in the input and output, and b) where possible, limiting the syntax to things that have a nice canonical form that optimizers can operate based on
< 1743011050 758429 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one of the biggest mistakes programming languages make is to accidentally make a detail that should be irrelevant observable
< 1743011079 814177 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and this is a type of mistake that normally can't be backwards-compatibly corrected
< 1743011106 466368 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I think the reason it happens is that the languages start by using algorithms to specify functions, and that makes it easy to accidentally capture an implementation detail
< 1743011224 948562 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I've also been considering writing a blog post about why Rust reborrowing (the thing that is special about &mut) seems to cause most of Rust's major problems, even though it's hard to deal without – and I think that is consistent with your viewpoint too, as reborrowing is the Rust construct that behaves least like a pure function
< 1743011358 933264 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Yeah. I think that we often couch all of this in terms of purity, which happens to generalize Yanofsky because functions are definitionally pure. Certainly, implementing pure type systems is a special case of all of this.
< 1743011397 958177 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think purity is the most marketing-friendly way to talk about the concept, at least – even people who aren't deeply into type theory can have an idea of what it means
< 1743011429 753659 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :To stereotype my conversations with implementors of languages like Idris or Coq, they have a distinction between "computation" in terms of simplifying/rewriting terms, and "extraction" in terms of actual compilation.
< 1743011478 261779 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This also shows up in partial evaluation; in e.g. lambda calculus, there's a real distinction between beta-reduction of symbolic terms and the effective beta-reduction performed by call/return semantics.
< 1743011501 937893 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Er, like CBV semantics obviously, but also calling by partially-evaluated reference.
< 1743011553 841866 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am increasingly thinking that references should be an implementation detail rather than something explicitly managed by the programmer
< 1743011586 520679 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :an obvious example is the distinction between &T and &&T in Rust, which is necessary for type-system reasons but causes runtime overhead for almost no good reason
< 1743011619 174184 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Your (b) is definitely both desirable and something for which we have a type-theoretic ceiling. It's known that Cartesian-closed categories have a canonical form for arrows on their own, but if we add sums (bicartesian) or natural-numbers objects, then equivalence is undecidable.
< 1743011634 961294 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the only thing that prevents you optimising &&T into a copy of the &T is that it might get converted to a raw pointer, which most programs don't care about doing)
< 1743011680 94525 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wouldn't expect practically useful programming languages to have decidable equivalence, because that places huge constraints on the computational class that likely rule out a wide range of useful programs
< 1743011683 369193 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The first part of that sounds a lot like "no Turing-complete language has genuine sums and products", but it comes from a totally different angle: there's no finite axiomatization of rewrites for bicartesian-closed categories.
< 1743011709 273225 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but maybe large portions of them can
< 1743011780 621074 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in a language I am working on, I realised that programs are conceptually much easier to express if the virtual-machine evaluation order used in the specification is very different from the evaluation order of the compiled assembly language
< 1743011800 740982 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although in order to pull that off, you need a lot of statements to be able to commute
< 1743011897 921944 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I suspect the construct that most commonly causes program equivalence to become undecidable is the unbounded loop (whether done via recursion or imperatively)
< 1743011905 360903 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, well, Blindfolded Arithmetic is enough to demonstrate that
< 1743011910 661244 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :don't even need any control flow, just the loop
< 1743011917 327291 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah. And we can see the gaps here. For example, when we compile a language with pairs ("bracket") into stack-machine code, we usually get to choose whether to evaluate the left-hand or right-hand component first. That choice is a compiler choice and often commutative.
< 1743011951 801104 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes – and ideally a well-designed language would make it impossible to write a program where the choice was observable
< 1743011965 786612 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But that suggests that, as a compiler, we're embedding a possibly-trivial automorphism group into a non-trivial group.
< 1743011975 440615 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :for example, you could reject programs in which both arguments to the pair constructor had side effects
< 1743012012 87724 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or use a type system to do the same thing
< 1743012045 982194 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And Yanofsky showed that the non-trivial automorphism groups correspond to equivalences of programs which don't fully respect bracket, composition, or recursion. Since bracket is freely respected here, and since composition is usually implied in homomorphic compilers, this means that e.g. Cammy's compiler must create some observable non-equivalences of recursion.
< 1743012046 940613 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think pair constructors are special here, the same thing is true of function arguments in general
< 1743012060 394492 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And indeed there are some test Cammy programs that provoke StackOverflow in the underlying JIT.
< 1743012130 795538 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Pair construction is just a convenient example. We could use any categorical structure that's implied by the three ops.
< 1743012136 700434 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am not surprised that lack of equivalence is mathematically unavoidable, and agree that recursion/loops is the best place for it to happen
< 1743012199 84336 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I used to be a little surprised that OCaml and GHC Haskell don't have eta-equivalence. Angry, even. Now I'm thinking that it's inevitable if they want to automatically and homomorphically generate efficient programs.
< 1743012280 31739 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(It doesn't matter that Hask isn't a category! Yanofsky expects languages to only give graphs. For categories, the structure's already too nice to have interesting Galois theory.)
< 1743012408 361111 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which version of eta-equivalence are you talking about? the general one which lets you substitute any function for another function with the same I/O behaviour, or the specific one that only converts between f and \x -> f x?
< 1743012454 904506 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Either TBH, but Ocaml specifically lacks the latter, and GHC has historically had many bugs relating to it.
< 1743012490 420844 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right – Ocaml specifically has observable evaluation order which breaks that equivalence – Haskell I would have expected to uphold it, though, and it sounds like it's trying to?
< 1743012740 650957 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Well, the automorphism groups don't preserve computational complexity. GHC bugs usually aren't miscompiles but performance problems; the relevant part of the compiler is their "lambda lifter", which also decides whether to eta-convert expressions to add/remove laziness.
< 1743012777 313428 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, I see
< 1743012794 885221 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...I mean, some of the automorphism groups do preserve complexity, but anything involving loops appears to not be that easy. Yanofsky suggests that natural numbers are some sort of special semantic object that brings in the complexity.
< 1743012836 820429 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think that might be backwards – in the sense that I suspect the same sorts of things that introduce complexity can also be used to implement natural numbers
< 1743012869 460331 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is why The Waterfall Model is so good at proving TCness – pretty much anything that is complex enough to be TC can implement natural numbers more or less directly, and TWM doesn't need anything else
< 1743012930 60294 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the basic reason is that anything TC has to be able to store arbitrary amounts of data, and "the amount of data" is typically something you can use to represent a number
> 1743012945 503988 PRIVMSG #esolangs :14[[07Table14]]4 M10 02https://esolangs.org/w/index.php?diff=154565&oldid=154550 5* 03Rdococ 5* (-156) 10
> 1743013004 652549 PRIVMSG #esolangs :14[[07Table14]]4 M10 02https://esolangs.org/w/index.php?diff=154566&oldid=154565 5* 03Rdococ 5* (+1) 10/* Truth machine */
< 1743013580 242598 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :That's definitely a way of looking at it, although I worry that it's too focused on the computer as the source of the complexity. After all, we usually define complexity in terms of asymptotes which extend beyond any single computer.
< 1743013605 621485 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, I'm thinking in terms of abstract machines here, not physical computers
< 1743013669 880356 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh! I was always thinking in terms of abstract machines, sorry. Like, "the computer" might well be Kleene's formalism, which also assumes the existence of natural numbers.
< 1743013719 589419 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess I have a semantics-first way of thinking about TC proofs because that's how most esolangs are defined
< 1743013777 320862 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I also have a suspicion that taking asymptotes/limits of programs is a dangerous/risky operation in the sense that it may not be well-defined – it can definitely cause a huge expansion to a computational class
< 1743013785 90647 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :No worries. I only think so much about abstract syntax because I'm always writing cruddy compilers.
< 1743013842 508436 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :for example, suppose you have a language equipped with a random oracle; if you use it it returns either true (with probability p) or false (with probability 1-p) – you can give that to a TC language and it's still TC (just with potentially random behaviour) – but if you take the limit as p goes to 0, it becomes able to solve the halting problem
< 1743013854 83125 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(even though the actual value of p=0 would be entirely useless)
< 1743013914 262397 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Right. We can always define limits of categories, and a "star graph" category can serve as the appropriate diagram; it's got arrows 0 → 1, 0 → 2, 0 → 3, etc. But programs only give a graph, not a category, under typical rewriting rules.
< 1743013984 130629 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Ah, yeah, the limit has to be WRT some categorical structure, and I'm not sure how the complexity class R behaves when we do that. (I've failed to understand Turing categories like three times; they are not easy constructions.)
< 1743013996 40227 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I would not expect programs to usefully give a limit ("useful" in the sense that it corresponds to any operation that you can actually calculate or implement or that gives insight for reasoning about programs)
< 1743014109 941091 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Well, we can get one insight: what are some trivial complexity bounds for a given program? If we can determine which algorithm it implements, then we can shift to the category of algorithms, optionally give it a non-uniform representation, map it onto a star graph, and take the limit in some metric space.
< 1743014164 200800 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :That determiniation must be the hard part, because we usually just kind of handwave over the rest of it!
< 1743014218 822498 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I agree – you can prove that by "contradiction" in that if we could easily tell what algorithm an arbitrary program implemented, it would be trivial to optimise it
< 1743014285 146233 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In the sense that, since programs are surjective on algorithms, once we've picked out a representative (which we established earlier is hard) then we can hand-optimize that representative. And recognizing an algorithm is "idiom detection" from compiler engineering.
< 1743014320 504121 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there are limited languages in which you can do that, e.g. with a language that has integer constant and variables and + - × and non-recursive functions but no control flow or loops, you can canonicalise functions into polynomials
< 1743014351 884534 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and one thing that I'm interested in is expanding that sort of language into something that still canonicalises but can express a greater range of useful programs
< 1743014363 685410 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. can we add bitwise operators and bitshifts to that?
< 1743014366 747681 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, but also: for a given program, we know at least one algorithm it implements, because we know one function it implements: it implements the effects encoded by the Kleisli category of the effect monad! And algos are surjective on functions.
< 1743014411 759871 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Further we know how to use abstract interpretation to concretely transform a program with loops into a worst-case complexity analysis, and we teach it to undergrads when we show them the triply-nested loop for matrix multiplication.
< 1743014438 792498 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :idiom detection annoys me – I a) intuitively feel like it's the wrong approach but b) don't know any better alternatives
< 1743014471 963882 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think the reason I think it's the wrong approach is that it will usually optimise some programs differently from other programs that are clearly (to a human) equivalent
< 1743014479 896948 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :especially if it isn't confluent, which it isn't usually
< 1743014504 108823 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Hm. That's a good question and one that we'd need a ring theorist to really take apart. It sounds very familiar, maybe because somebody stubbed a Diophantine-equation article recently.
< 1743014572 827266 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Right, we know that tile-oriented instruction selection is NP-hard to do well, and idiom detection is -- if we allow individual instructions to be idioms -- therefore NP-hard too.
< 1743014590 81426 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :come to think of it, just being able to prove that a set of tree-rewriting optimisations is confluent would be useful, and seems theoretically possible in at least some cases
< 1743014609 420526 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, NP-hardness, that makes sense
< 1743014647 891050 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :To the point where I always remember NOLTIS in terms of what it stands for: Nearly-Optimal Linear-Time Instruction Selection. Wow! And it uses tiles explicitly, too.
< 1743014724 916911 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :related: I recently came across a problem related to instruction selection for which the abstract version is this: you have a number of known finite sets, and need to choose one element for each set – for each pair of elements in different sets there is a (possibly zero) cost, and you want to make a selection that minimises the total cost across all pairs of elements you selected
< 1743014762 730140 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this looks really reminiscent of an NP-complete problem but I haven't immediately figured out which one – in particular it reminds me a lot of Boolean satisfaction but the restriction to pairs makes it hard to implement anything other than 2-SAT directly
< 1743014777 270886 :b_jonas!~x@88.87.242.184 JOIN #esolangs b_jonas :b_jonas
< 1743014816 532036 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It reminds me of how Sudoku is solved, and Hamiltonian cycles are doable in a similar setup. It becomes 0-1 programming when we set the cost to be a Dirac delta (0 when i = j and 1 otherwise).
< 1743014864 79796 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Pair-of-elements is like a 2-graph; it's a double-decker where each edge is valued in the *elements* of nodes and not just the nodes themselves.
< 1743014885 880708 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh you're right, I think it does do Hamiltonian cycles directly (the sets are the edges from each vertex, and there's a high cost for choosing two edges that don't connect to each other)
< 1743014919 674258 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It reminds me of Sudoku because I bet Norvig's heuristic is decent on it: pick the smallest set and generate the collection of all possible pairs in/out of it, recursively eliminating possibilities.
< 1743014946 225300 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, it looks like the sort of NP-complete problem for which there are good approximations
< 1743015941 259842 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Okay, I'm back to the three ops. Was thinking about how UNIX kernels used to be handwritten. A kernel can take programs and perform the three ops on them. We'll only consider input and output effects, like with UNIX pipes.
< 1743016020 872450 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Then composition obviously holds. Bracket-pairing should work too. Recursion needs help from a system daemon or a jank series of syscalls but should be possible. So, in a sense, one of the jobs of a (UNIX) kernel is to promote programs into algorithms; the individual programs might not compose, but the computer does as a whole.
< 1743016341 126652 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This is a pretty stark contrast with the "page of code" school, e.g. from VPRI/STEPS, which contends that we should write a single low-level program that is about one page long and merely bootstraps a nicer programming environment, about five or six times.
< 1743016395 899728 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not convinced that the "page of code" strategy is necessarily a sensible way to do programming, but it sounds like a lot of fun – I might try that some time
< 1743016420 777730 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sure, maybe the first page of code gets us into a nice low-level image-based Forth-ish or Tcl-ish environment. Maybe the next page of code sets up a GC. Maybe the next page establishes platform-specific hooks and prepares for a userland.
< 1743016468 605590 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But at some point, we want the computer to transition from running one program to providing some sort of program-running environment and giving us various meta powers, and in particular we might want to compose two programs. But programs don't compose.
< 1743016493 861643 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think the page-of-code approach eventually hits Kolmogorov complexity limits
< 1743016518 639188 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can create increasingly golfy programming environments, but even the golfiest won't be able to fit a program that's too complicated into a single page
< 1743016544 455802 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :For sure. I also think it's based on some very optimistic assumptions. I think I've documented Nile on-wiki as an example of a STEPS language; it's part ML and part APL, and it was designed to express GPU shaders very succinctly.
< 1743016550 919456 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you'd have to start encoding the actual program you wanted into the language, rather than just writing the best generic language you could
< 1743016560 561184 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And that still takes maybe two pages to implement Porter-Duff in toto.
< 1743016572 640516 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and at that point you're losing the benefits from the approach
< 1743016593 653803 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it could make sense for early bootstrapping, though, as long as you abandon it once it stops working
< 1743016596 781541 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Or at least the benefits start shifting to the eDSL benefits.
< 1743016664 24302 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...Sorry, what a bad sentence, and I can't figure out how to rephrase it.
< 1743016744 372885 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like, we want to make simple high-level statements like "boot the system", and if those get rephrased to machine-parseable `boot(theSystem)` statements then that's not necessarily worse. Machines can check their well-formedness, do a model-check, etc.
< 1743016775 477989 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Pantagruel might be a good example of that sort of language, but the reference implementation's in Janet and I've been unable to adopt it because Janet's custom build system is jank.
> 1743019320 209825 PRIVMSG #esolangs :14[[07Clockwise Turing machine14]]4 N10 02https://esolangs.org/w/index.php?oldid=154567 5* 03Stkptr 5* (+2710) 10creat
> 1743019635 450075 PRIVMSG #esolangs :14[[07FOSMOL14]]4 M10 02https://esolangs.org/w/index.php?diff=154568&oldid=153872 5* 03Aadenboy 5* (+46) 10/* Example macros */ oh duplication is simple actually
> 1743019719 869791 PRIVMSG #esolangs :14[[07Pantagruel14]]4 N10 02https://esolangs.org/w/index.php?oldid=154569 5* 03Corbin 5* (+1818) 10Stub a desirable specification language.
< 1743020011 473930 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Okay, so I'm still thinkin' way too hard, but here's an example of a spec language that isn't as encumbered as Dafny or as austere as TLA+. Pantagruel documents are basically little diagrams of a simple type theory. We could imagine interpreting them in a world of functions.
< 1743020095 175148 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :We could imagine calculating a program for such a spec. First, figure out a candidate function; we'll just take the least upper point of the diagram, requiring every property to abstractly hold. Then pull back once for an algorithm, and twice for a program.
< 1743020162 638838 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Hopefully we only get stuck at that second stage, since that's the one that we thought was hard earlier. Which algorithm implements the least upper point? Well, any algorithm that checks each property by examining the input will do. We can choose the cheapest one through standard algebraic optimization.
> 1743020312 759045 PRIVMSG #esolangs :14[[07Clockwise Turing machine14]]4 10 02https://esolangs.org/w/index.php?diff=154570&oldid=154567 5* 03Stkptr 5* (+29) 10
< 1743020414 482733 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(I'm not handwaving that, BTW. There's a wonderful book using equational reasoning to work through how to *compute* algorithms with desired properties: https://di.uminho.pt/~jno/ps/pdbc.pdf "Program Design by Calculation")
> 1743020434 330188 PRIVMSG #esolangs :14[[07Clockwise Turing machine14]]4 10 02https://esolangs.org/w/index.php?diff=154571&oldid=154570 5* 03Stkptr 5* (-29) 10Undo revision [[Special:Diff/154570|154570]] by [[Special:Contributions/Stkptr|Stkptr]] ([[User talk:Stkptr|talk]])
< 1743020484 23346 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(I guess this is covered in the current Chapter 7, "Contract-oriented Programming")
< 1743020951 458574 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm kind-of stuck confused between different levels of abstraction, as usual when I'm thinking about category theory
< 1743021007 830738 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Totally fair. Galois theory is very difficult for me in general, and I think I'd be completely lost if it weren't for programs => algos => functions right now.
< 1743021083 349049 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :is it the case that with your terminology, algorithm→program is "hard" because the program captures inessential details that the algorithm doesn't capture, so you can end up producing an undesirable program by forcing the wrong details?
< 1743021215 275785 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It's hard to find an efficient program quickly. NP-hard in the specific case of idiom recognition, at least. We can find a decent program using homomorphisms and generic tools, but it'll do "slow" things that respect the symmetries of composition, like saving registers for calling conventions or spilling them for inlined subroutines.
< 1743021256 789289 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :OK, yes, I think I understand now – finding an arbitrary program isn't hard, but finding one with desirable properties is
< 1743021271 902024 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The faster programs might exist, but they won't be found programmatically by a symmetry-respecting tool like a BURG. They'll have to be found by something a little more brute like a superoptimizer.
< 1743021330 348956 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, this reminds me – I think at least inefficiencies related to cross-subroutine register allocation are probably fixable without a full rethink of the way compilers work
< 1743021389 669128 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think register allocation is done too early in typical compile pipelines – it seems like the sort of thing that could reasonably be left as late as possible
< 1743021392 574206 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :A slogan that might help: A concrete category is a path category on some graph (called its "quiver", because it holds arrows, haha~ ugh). This sort of program generation has to follow paths from one possible optimized program to another, and those paths are defined WRT some underlying symmetry due to their inner control flow.
< 1743021428 889757 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and that would open the possibility of each subroutine being built with its own ABI, or maybe even multiple ABIs, that are propagated to do a more optimal register assignment
< 1743021479 147302 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In order to find one of those uniquely efficient programs, the generator has to find a similarly unique path of applied optimizations; in particular, *no optimizations may commute* or else there are multiple underlying paths.
< 1743021492 823463 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yes, exactly.
< 1743021654 478921 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Oh sheesh, that reminds me of a blog post I did *not* write. If we ignore call/return and stack semantics, the remaining opcodes of most processors give a structure called an "operad".
< 1743021717 462496 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Terminology around these things is awful. An operad is a category that takes multiple inputs and has multiple outputs (a "multicategory"). We want to let some registers be general and others specific (they have "colors", again ugh), and we can apply arguments in any order.
< 1743021763 221603 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But once that's all set up, an operad exactly encodes the dataflow of a program. To evaluate some operation, first evaluate its arguments and then perform the operation itself.
< 1743021826 150679 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think most practical processors nowadays are moving away from special-purpose registers, except a) stack/subroutine-related registers, b) the instruction pointer, and c) the fact that some registers are typically larger than others
< 1743021846 18526 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So the *processor* has symmetries! It's not actually running programs, it's running algorithms! No wonder the modern CPU basically has an on-die JIT.
< 1743021892 650210 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But only if there's a lot of GPRs. Like maybe two or three GPRs, at least. So maybe the 6502 has genuine programs.
< 1743021900 489142 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, that's more true than you imagine – registers nowadays are primarily a convention for expressing SSA in a fairly compressed/golfy form and get decompiled into SSA in the processor
< 1743021956 969633 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the only time a value is stored in an actual physical register is if you don't mention the register for ages (around 100 instructions) and the compiler needs to remember the assignment of value to register name long-term
< 1743021966 841963 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the rest of the time it's all virtual SSA registers, and there are hundreds of them
< 1743022064 758425 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But 6502 is different. Or Z80, whatever. Every primitive operation only operates on specific registers, and they usually can't be substituted for each other. So there's practically no commuting sequences of code in terms of register effects.
< 1743022074 482266 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes
< 1743022121 780934 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So there's no point to JIT. Or the point would only be to JIT an emulator if we're virtualized, I guess. But the hardware itself, not able to commute operations, executes programs.
< 1743022123 909120 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :microcontrollers can be different again – the one I used had one traditional register which was an implicit operand of basically every command, and the other operand was memory, but it had a huge number of special-purpose memory addresses
< 1743022163 529581 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. to do an indirect access to memory, you would store the address at, IIRC, memory location 4 and then read/write the value of memory location 0, which was defined as an alias to whatever memory location 4 was poining to
< 1743022177 382573 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so from one point of view it had only one register, from another point of view it had hundreds
< 1743022198 589212 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it was sort-of like a transport-triggered architecture, except that it had normal arithmetic instructions as well as the memory-mapping
< 1743022218 910707 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and likewise normal control flow instructions
< 1743022253 766486 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So nothing would commute, since the implicit register creates data dependencies. Although, if we add standard read-write memory semantics for the rest of the memory bank, then some operations would commute again.
< 1743022338 410180 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, it was worse than that – there were only a couple of hundred bytes of memory total, and it was documented as expected behaviour to use special-purpose registers for general-purpose purposes in order to get a bit more memory
< 1743022358 124734 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So, in some sense, equipping a concrete machine with some I/O -- even just memory -- is loosening it up to only evaluate some algorithm, rather than a specific program.
< 1743022361 789142 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :many of them would, e.g., have enable flags in a different register and act like regular memory when disabled
< 1743022371 878724 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And that makes sense if we think about memory controllers having many different tools for speeding up transfers.
< 1743022417 657330 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I found some of my own asm code for this, it's mostly mov instructions with occasional arithmetic and control flow
< 1743022444 369847 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and instructions to set/clear/toggle single bits directly in memory, without needing to go via the register
< 1743022490 569595 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wasn't expecting this to have RMW instructions but those ones do make sense, given how the processor works (and, come to think of it, might have been implemented without a specific read cycle via using memory that could be written a single bit at a time)
< 1743022528 278079 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :*But* if the program is written to require a specific memory-controller behavior, then that would still be targeting a concrete machine. So it turns out that when we want to work with "a machine", we need to be fairly specific about whether it's evaluating programs or algorithms, and we can only tell by doing some Galois theory to see how strongly Hyrum's Law applies.
< 1743022539 569070 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah no, it appears to have actual RMW instructions, there are some "add register to memory", "increment/decrement memory" in here
< 1743022564 479137 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, that's nice of them.
< 1743022587 777988 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: my guess is that practical programming and practical computers don't try to make a hard distinction between programs and algorithms in your sense
< 1743022601 142614 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and this occasionally leads to trouble but mostly works well enough for people to not be bothered by it
< 1743022693 191587 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: I agree. And also, more nuanced: a hardware-maker is trying to turn programs into algorithms, which requires new symmetries to be exposed so that some operations can commute. A programmer is trying to turn algorithms into programs, which requires breaking symmetries and choosing a good order of operations.
< 1743022834 886519 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :A compiler author must do both, first by taking a program as representative of a class of algorithms, then by viewing that class as an equivalent category to some other class, and finally by choosing an efficient representative program from the class.
< 1743023008 98484 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Those almost sound like slogans. Needs a bit more cooking.
> 1743023115 256385 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03OskuDev 5*  10New user account
< 1743023204 221912 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I may be misunderstanding something, but I don't think Hamiltonian cycles can be easily reduced to the optimization problem that you gave.  
< 1743023251 490023 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Sorry for the headache; thanks for the rubber-ducking. I think that I have the bulk of the insights for the post; the rest of it is just verifying theses like "every modern language expresses exactly one of: programs, algorithms, or functions".
< 1743023286 441017 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I think it's NP-complete nevertheless, that's just not the right way to prove it
< 1743023332 566143 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I think you have to reduce chromatic number instead, or maximal matching, or something like that.
< 1743023355 155529 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :The reduction that you mention doesn't work because it doesn't enforce that there's only once cycle instead of a union of disjoint cycles.
< 1743023527 470363 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Ah curses, and Sudoku doesn't encode nicely for the same reason. Nice catch, thank you.
< 1743023547 449031 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: ah yes, the construction doesn't seem to handle cycle count
< 1743023583 243142 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I actually considered pinging you at that point in the conversation, it seemed like your sort of problem
> 1743023657 551000 PRIVMSG #esolangs :14[[07Bi-tag system14]]4 N10 02https://esolangs.org/w/index.php?oldid=154572 5* 03Stkptr 5* (+2341) 10crate pag
< 1743023668 669606 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the chromatic number decision problem (more or less than some specific value) seems to work fairly directly? just have a high cost for two adjacent vertices being the same color
< 1743023741 188312 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :My entire thought process about it was wrong, sorry. In particular, if the cost function is always 0 or 1, then it's poly-time whether there's a zero-cost path. I was completely misled by superficial details.
> 1743023753 957717 PRIVMSG #esolangs :14[[07Tag system14]]4 10 02https://esolangs.org/w/index.php?diff=154573&oldid=115677 5* 03Stkptr 5* (+20) 10/* See also */
< 1743023780 463983 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I think even the only-0-or-1 case can solve the chromatic number decision problem
< 1743023804 889423 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which is NP-complete for, e.g., determining whether a graph is 3-colorable
< 1743023809 85484 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :correct, that's my sort of problem
< 1743023827 38801 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and yes, chromatic number works well for this 
> 1743023925 582547 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=154574&oldid=154535 5* 03OskuDev 5* (+94) 10/* Introductions */
< 1743024034 993395 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, okay, yeah. The 0-1 case comes out as the path problem for inhabited finite relations, which is canonically NP-complete. I see the chromatic-number encoding too.
< 1743024064 227352 :craigo!~craigo@user/craigo QUIT :Quit: Leaving
< 1743024579 671371 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :as for read-write-modify memory, the silliest language in that respect is https://esolangs.org/wiki/Y86 . it starts normal: most instructions can read an operand from memory but only write to a register, there's of course an ordinary store instruction. but there's one exception: you can one's complement memory in place. I don't know why it's designed that way.
< 1743024710 178762 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It looks like it's the only unary operation? Could be a simplification due to how addressing modes are (expected to be) decoded in hardware.
< 1743024766 475890 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :korvo: yeah, but why would they have that unary instruction when there are so few instructions?
< 1743024779 279296 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :At the time, the same sort of operation on a Z80 or 6502 could only happen on the accumulator X, I think? So maybe it went from an op with an implicit address to an op with explicit addressing.
< 1743024791 325664 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: I don't know. Retrospect is puzzling.
< 1743024828 916789 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I think that there may be benefits of not having any instruction that both read and write memory; some are read and some are write but not both.
< 1743024919 387461 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I mean there's kind of a reason, which is that to some extent y86 is based on 8086, which has special instructions for one's complement, but still, it has lots of other special instructions too
< 1743025242 494257 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :(The benefit might be that the cycles of the instruction should be more clearly, e.g. instruction cycle, calculation cycle, memory cycle. That way you should not need multiple memory cycles, but calculation cycles might be able to run at same time than other instructions do in some cases, since the calculation cycle does not need to access memory.)
< 1743025333 48419 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :a more common pattern is https://esolangs.org/wiki/Viktor%27s_amazing_4-bit_processor and https://esolangs.org/wiki/Lawrence_J._Krakauer%27s_decimal_computer , both of which have arithmetic instructions that get one operand from memory and the other from accumulator and store to accumulator, and have two store instructions: one to store the accumulator and one to store the program counter (for 
< 1743025339 56422 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :subroutine call). 
< 1743025797 859545 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: on the 6502, A is the register that supports most operations; X and Y are limited to moves, increment/decrement, and being used as an address
< 1743025820 358285 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not as familiar with the Z80 but am not sure it even has an X
< 1743025836 837028 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(I learned to program on a 6502, originally, so it's the first platform I learned)
< 1743025912 378730 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: huh, I'm familiar with two standard ways to do subroutine calls in hardware and that isn't either of them
< 1743025945 468845 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although I vaguely remember it being used by some early programming languages that didn't support recursion – the location of the caller would be stored in a static variable of the callee
< 1743026010 159008 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it crosses my mind that you don't really need "store/push current address" if you have "store/push immediate", unless you're using some sort of ASLR – but it might be useful anyway due to the instruction being shorter / needing fewer immediate bytes
< 1743026069 171285 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: well these are small toy processors. this wouldn't be very practical in a real machine because you have to know where the return instruction is to call the function, which makes it hard to change programs. optimized programs that ignore the published API and refer to addresses of specific subroutines in the kernal would hardcode not only the entry but the exit address. that would make it very 
< 1743026075 178689 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :annoying to update the ROM.
< 1743026209 649309 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: IIRC the convention was to store the return address immediately before the called address
< 1743026218 379951 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(obviously this requires program memory to be writable)
< 1743026256 608143 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :back in the days of old languages that didn't support recursion, presumably on processors that didn't have stacks because otherwise they would have used those instead
< 1743026314 169566 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ooh, even more fun – you don't need an indirect jump instruction to return, you can have a goto-immediate instruction at a known location and, when calling a function, just overwrite the immediate to decide where to return to
< 1743026347 91315 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this seems like it might potentially be a useful technique for implementing VMs in esolangs?
< 1743026432 933206 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :all three of Knuth's processors (that I documented) have a call instruction that puts the return address into a register, and then the called subroutine can use that register. 
< 1743026663 278595 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yes, Viktor T. Toth's CPU and Krakauer's language do that, they don't have indexing on any instruction, just modify the address field of the instruction in memory. and Krakauer's language actually adds the same trick to this as MIX does: the store program counter instruction actually only modifies the address field of the memory word, keeps the instruction field unchanged. Viktor T. Toth's CPU 
< 1743026669 285737 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :has nybble-granular memory so you can just directly address the address field, just like you can do on the 6502.
< 1743026731 921070 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :"directly address the address field" reminds me of Redcode
< 1743026761 917983 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :MIX also has indexing with index registers, and you can use that for an indirect jump, but subroutine returns don't do that too often. you can only store the return address to memory directly, it's one more instruction to load it back to an index register. can still be worth if you have many return statements from the same subroutine of course.
< 1743026840 11317 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the 6502 and BMOW-1 have indexing with index registers, but even more so than MIX they encourage you to also use self-modifying code for indirect memory access.
< 1743027008 521942 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, that's interesting – the 6502 doesn't really seem to need self-modifying code for that
< 1743027009 301995 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :whereas https://esolangs.org/wiki/Apollo_Guidance_Computer has an indexing instruction that loads an index from memory and it will be added to the next instruction between fetching and executing it. it works for almost any instruction. so it's even more general as MIX's indexing mechanism. 
< 1743027042 306487 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can indirect via a memory address plus a register, and can add the register either to the address being indirected via or the address loaded indirectly
< 1743027079 892345 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: in the 6502 the indexed addressing modes use the X or Y registers as an index, and those registers are one byte long, but the address space is two bytes long, and sometimes you want to index with more than just a byte
< 1743027084 408762 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I do like the "add to next instruction" for a short-pipeline processor, it's like you get the benefits of self-modifying code without needing to actually modify the program in RAM
< 1743027114 756549 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yes but you still can indirect via two bytes read from memory
< 1743027125 809348 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you don't need to self-modify code, just store the address you want in RAM
< 1743027138 657628 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and you still get to add one byte of offset to it)
< 1743027162 679576 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, you don't *need* self-modifying code, but self-modifying code is very often the easiest, at least if you have a non-small amount of memory
< 1743027175 98022 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can even do jump tables in a single instruction (although there's no automatic doubling of the offset like x86 can do, so you probably need another instruction to double the register first)
< 1743027205 979214 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I didn't program on banked 6502 implementations but they are very common, to get more than 64KiB of program+data memory
< 1743027228 613809 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I suspect they would make self-modifying code even less useful, especially as code is usually executed from ROM on those
< 1743027279 975917 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, in this case by "non-small" I just mean not just like 128 bytes of RAM plus 2 kilobytes of ROM like the Atari 2600 has, but enough RAM that you actually want indexes longer than a byte sometimes
< 1743027335 503977 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yes – but my point is that you can store the address into data RAM and indirect via it, or you can store the address into program RAM (if you even have any) and have it decoded as part of the instruction, and the former is neater and doesn't seem to have any downsides by comparison?
< 1743027341 671173 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :unless you need a double indirection
< 1743027502 737410 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: ok, I guess I was too strong above. probably you only want self-modifying code for a minority of indirect or indexing.
< 1743027518 897054 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the indirect addressing modes are good for most cases
> 1743028370 145909 PRIVMSG #esolangs :14[[07'Python' is not recognized14]]4 10 02https://esolangs.org/w/index.php?diff=154575&oldid=154516 5* 03Stkptr 5* (+35) 10It can never pop, so the stack is effectively 2 symbols deep
> 1743029462 10185 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 upload10 02 5* 03Buckets 5*  10uploaded "[[02File:Fontpride Logo.png10]]": This is the logo for Fontpride/<span style="background-color:#FFAFC8;color:white;">F</span><span style="background-color:#74D7EE;color:black;">o</span><span style="background-color:#613915;color:white;">n</span><span style="background-color:#E40303;color:black;">t</span><span st
> 1743029529 287898 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=154577&oldid=154558 5* 03Buckets 5* (+557) 10
> 1743029572 955447 PRIVMSG #esolangs :14[[07User:Buckets14]]4 M10 02https://esolangs.org/w/index.php?diff=154578&oldid=154525 5* 03Buckets 5* (+556) 10
> 1743029632 726707 PRIVMSG #esolangs :14[[07User:Buckets14]]4 M10 02https://esolangs.org/w/index.php?diff=154579&oldid=154578 5* 03Buckets 5* (+1) 10
> 1743029673 722947 PRIVMSG #esolangs :14[[07Fontpride14]]4 N10 02https://esolangs.org/w/index.php?oldid=154580 5* 03Buckets 5* (+12518) 10Created page with "{{wrongtitle|title=<span style="background-color:#FFAFC8;color:white;">F</span><span style="background-color:#74D7EE;color:black;">o</span><span style="background-color:#613915;color:white;">n</span><span style="background-color:#E40303;color:black;">t</span><span st
> 1743029944 695724 PRIVMSG #esolangs :14[[07Batch No For14]]4 10 02https://esolangs.org/w/index.php?diff=154581&oldid=139891 5* 03Stkptr 5* (+98) 10
< 1743030359 910872 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname
> 1743031455 994699 PRIVMSG #esolangs :14[[07Talk:14]]4 10 02https://esolangs.org/w/index.php?diff=154582&oldid=108008 5* 03Hotcrystal0 5* (+61) 10/* Unstack */ new section
> 1743031462 500380 PRIVMSG #esolangs :14[[07Talk:14]]4 10 02https://esolangs.org/w/index.php?diff=154583&oldid=154582 5* 03Hotcrystal0 5* (+93) 10
> 1743031500 794277 PRIVMSG #esolangs :14[[07User:I am islptng/List of the users that is also in conwaylife.com14]]4 10 02https://esolangs.org/w/index.php?diff=154584&oldid=154489 5* 03Hotcrystal0 5* (+51) 10
> 1743031512 186675 PRIVMSG #esolangs :14[[07User:I am islptng/List of the users that is also in conwaylife.com14]]4 10 02https://esolangs.org/w/index.php?diff=154585&oldid=154584 5* 03Hotcrystal0 5* (+3) 10
> 1743031820 334189 PRIVMSG #esolangs :14[[07AH'TALIQUAE ENGLISH/Examples14]]4 M10 02https://esolangs.org/w/index.php?diff=154586&oldid=141133 5* 03Buckets 5* (+0) 10