< 1762906952 103294 :DOS_User_webchat!~DOS_User_@72.red-88-1-117.dynamicip.rima-tde.net JOIN #esolangs * :[https://web.libera.chat] DOS_User_webchat < 1762906965 115432 :DOS_User_webchat!~DOS_User_@72.red-88-1-117.dynamicip.rima-tde.net CHGHOST ~DOS_User_ :user/DOS-User:11249 < 1762908372 456635 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 QUIT :Remote host closed the connection < 1762908866 822482 :ais523!~ais523@user/ais523 QUIT :Quit: quit > 1762910032 698585 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=167959&oldid=167957 5* 03NTMDev 5* (+909) 10 < 1762911404 528989 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :There must exist a point at which if a Brainfuck implementation has too few memory cells, or the Brainfuck code cannot exceed a certain length, the existence of the implementation no longer proves that it's... whatever the memory bounded version of TC is. What is that point? < 1762911483 865358 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Sgeo: Sure, if you follow along these lines you may come to see a computer as a giant but finite state machine. < 1762911515 681740 :int-e!~noone@int-e.eu PRIVMSG #esolangs :But TC is a much nicer theoretical concept than "fit for programming" which is what we care about in practice. Not necessarily for esolangs though. < 1762911542 485093 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Sgeo: The original Brainfuck had 30k 8-bit cells so it's not TC either. < 1762911611 798013 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I keep thinking about "compiling" Brainfuck to Burroughs E101. E101 only has 100 cells. And I don't see an easy way to... decrement a pointer in few instructions unless I limit to 10 cells. And there's only room for 8*16=128 instructions in E101's ... program < 1762911640 640786 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Sgeo: Basically no actual implementation of any programming language is TC. (You could cheat by adding more storage peripherals over time, though eventually you'll run into physical limitations doing even that.) < 1762911695 533262 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Also E101 doesn't do constants. So I'd also be "compiling" into instructions for the user: At the first halt type this number, at the second halt type this number, etc.. < 1762911707 863915 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Which is how real programs on it worked too < 1762911709 429255 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Sgeo: Right, that may be too small for a brainfuck target. Or, really, for basically anything you want a computer to do. :) < 1762911713 678781 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(these days) < 1762911766 918688 :int-e!~noone@int-e.eu PRIVMSG #esolangs :it really sounds more like an electronic calculator that has some basic macro capabilty for user-defined functions < 1762911811 524693 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Burroughs was a calculator company. The keyboard looks like an adder machine. But I think it is in some sense a full computer (not a stored-program one though) < 1762911825 465226 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :https://bitsavers.org/pdf/burroughs/Electrodata/E101/ < 1762911853 488836 :int-e!~noone@int-e.eu PRIVMSG #esolangs :yeah sorry I'm not going to be drawn into details :P < 1762911952 411604 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Sgeo: Can you sort an array of 10 cells without human intervention? What about 50 cells or all 100? :) < 1762911952 686589 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :There's an extension that does allow setting E and F from the accumulator, I guess that can be used if I store a pointer in memory < 1762912005 532213 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(sorting is one of the basic tasks that we often want a computer to do :) ) < 1762912074 899972 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I don't think I'm going to attempt to write a sort routine. Might not be able to do all 100 if it needs more scratch space than just the accumulator. There's a library of subroutines, all of which are math functions. < 1762912076 292234 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I don't need an answer to the question. I'm musing about where I'd draw the line between a calculator and a computer. < 1762912136 572228 :int-e!~noone@int-e.eu PRIVMSG #esolangs :And I think if it *can't* sort then it's not a computer. If it can sort... well, that clearly moves it closer. Is it enough for me? I don't know! Obviously modern computers do so much more. < 1762912312 980824 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(Interesting side show: Are analog computers for space crafts computers :) ) < 1762912483 652196 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Is there a sort where the only time I have to decrement the pointer is going back to the beginning of the array? I think that would be -easier- to implement < 1762912492 631865 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :(I'm not actually attempting to implement) < 1762912517 780233 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I was thinking bubble sort but that doesn't quite fit < 1762912990 143526 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Sgeo: uh, there is this horribly inefficient thing: https://paste.debian.net/1405805/ < 1762913027 336299 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(2**64 is supposed to be a number larger than any number of interest) < 1762913122 350198 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Yeah I think that's implementable < 1762913138 404094 :int-e!~noone@int-e.eu PRIVMSG #esolangs :"horribly inefficient" -- it's exponential < 1762913166 127218 :int-e!~noone@int-e.eu PRIVMSG #esolangs :not quite as bad as the expected runtime of bogosort but close < 1762913387 209423 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Well, IIRC it had O(2^n) worst case, O(2^n / n) average case and only O(n^2) worst case. < 1762913420 27747 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Assuming that the numbers to be sorted are all distinct < 1762913470 305656 :int-e!~noone@int-e.eu PRIVMSG #esolangs :err the second "worst case" was supposed to be "best case" < 1762914331 336835 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the usual approach is to define a generalization of the machine where the memory size is a parameter, then prove that the problem is PSPACE-complete < 1762914336 961411 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :like nxn chess > 1762914617 190725 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=167960&oldid=167959 5* 03NTMDev 5* (+73) 10 < 1762914654 180926 :amby!~ambylastn@host-81-178-157-25.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 > 1762914739 787793 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=167961&oldid=167960 5* 03NTMDev 5* (+379) 10 > 1762914908 873032 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=167962&oldid=167961 5* 03NTMDev 5* (+201) 10 > 1762915052 13651 PRIVMSG #esolangs :14[[07User:NTMDev14]]4 10 02https://esolangs.org/w/index.php?diff=167963&oldid=167818 5* 03NTMDev 5* (+14) 10 < 1762916489 453332 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :There's an optional addition that allows for 220 cells. Said addition also makes it easier to load a cell as a pointer in, um. I think 5 instructions. < 1762916512 871280 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Which seems like a lot > 1762920039 260221 PRIVMSG #esolangs :14[[07Talk:INTERCAL14]]4 10 02https://esolangs.org/w/index.php?diff=167964&oldid=167847 5* 03Jasper 5* (+209) 10/* Useful functions made using INTERCAL's unary / binary operators */ < 1762921119 99538 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :if you write a bubble sort pass to write back the output 1 element later than it was read, you don't need to decrement anything. if you make the array circular, the data will be in the correct places after a number of iterations equal to the array size, which is exactly how many you need for the array to be sorted. I have 25 instructions https://paste.debian.net/1405811/ < 1762921186 777122 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :apart from the harvard architecture and the coroutines (!) it seems like a fairly standard one-address machine < 1762921247 394092 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :the first 94 should be a 95, one-way counter to know when the sort is done < 1762922654 267396 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :!!! < 1762922662 726978 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I should... maybe look at writing an emulator soon, huh. < 1762923433 759987 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :sorear, awesome! Though I'm not sure what you mean by the bracketed numbers, they can't be pinboard numbers < 1762924449 472546 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Oh I see. Instruction numbers, and the second [0] is pinboard ... um. Did you index pinboards by 0? They go 1-8, with 0 meaning same pinboard. < 1762928155 573641 :pool!~nathan@user/PoolloverNathan QUIT :Ping timeout: 256 seconds < 1762928175 638005 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1762929804 555537 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :floor(log2(999999999999))+1 ... I think that's correct for how many bits needed to hold a 12 decimal digit number, right? < 1762930240 328748 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Remote host closed the connection < 1762930258 833051 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse > 1762931209 312041 PRIVMSG #esolangs :14[[07$14]]4 M10 02https://esolangs.org/w/index.php?diff=167965&oldid=144365 5* 03ThrowAwayLurker 5* (+90) 10Added easily inferable detail that still deserves explicitness; also semicolon because I'm a nerd and it makes it flow better > 1762931403 696939 PRIVMSG #esolangs :14[[07Backsharp14]]4 M10 02https://esolangs.org/w/index.php?diff=167966&oldid=90825 5* 03ThrowAwayLurker 5* (+4) 10Added dash > 1762931488 820536 PRIVMSG #esolangs :14[[07SQ14]]4 M10 02https://esolangs.org/w/index.php?diff=167967&oldid=80607 5* 03ThrowAwayLurker 5* (-9) 10User page links should be clearly user page links, thus the "user:" should be included > 1762932434 724684 PRIVMSG #esolangs :14[[07Action symbol14]]4 10 02https://esolangs.org/w/index.php?diff=167968&oldid=167579 5* 03Yayimhere2(school) 5* (-97) 10/* how it works */ > 1762932713 133486 PRIVMSG #esolangs :14[[07Tttt14]]4 10 02https://esolangs.org/w/index.php?diff=167969&oldid=91798 5* 03ThrowAwayLurker 5* (+505) 10Made it clearer and more professional/serviceable > 1762932944 173768 PRIVMSG #esolangs :14[[07Talk:Chimera14]]4 N10 02https://esolangs.org/w/index.php?oldid=167970 5* 03ThrowAwayLurker 5* (+216) 10Created page with "Isn't the language trivially Turing-complete as it allows for the computation of arbitrary lambda functions? ~~~~" < 1762933150 511831 :somelauw!~somelauw@host-bc.cgnat-f.v4.dfn.nl JOIN #esolangs * :somelauw < 1762933698 793863 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :*self.memory.get(tens, ones)? = self.a; < 1762933708 213165 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :It feels weird to have a question mark on the left of the assignment like that < 1762934018 956561 :tromp!~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343 JOIN #esolangs * :Textual User < 1762934056 682709 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :Sgeo: if you can use two pointers then you can do a bubble sort with pointers that you can only decrement by resetting < 1762934075 176892 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or does this have like a tape/drum memory with just one pointer because there's one head? < 1762934104 882384 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I think even with one head you can do a bubblesort, you just keep shifting the array forward in every iteration < 1762934129 466088 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :The "pointer" is two switches that can be increased up. sorear wrote a sort that does the shifting array forward thing < 1762934175 11973 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :Sgeo: don't forget the sign bit < 1762934178 497668 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I believe it is drum memory but that's not what the issue is. In the 220 memory model there is an instruction that can set the switches according to values in the accumulator < 1762934224 123983 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :sorear, thank you. 32 bits isn't enough anyway so rounding to 64 which is plenty < 1762934264 505679 :somelauw!~somelauw@host-bc.cgnat-f.v4.dfn.nl QUIT :Remote host closed the connection < 1762934389 682687 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :it's almost but not quite a decimal64 < 1762934449 910291 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I'm sort of treating them as integers and assuming the implicit decimal point only matters during multiplication and division < 1762934510 754282 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I should probably sleep soon < 1762934561 30769 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I want a closer picture of the keyboard so I can understand X and Y better. Do they... default to 0? Or alarm if used and not set? < 1762934749 403557 :svm!~msv@user/msv JOIN #esolangs msv :msv < 1762934913 301625 :msv!~msv@user/msv QUIT :Ping timeout: 265 seconds < 1762936561 368253 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer > 1762938359 621995 PRIVMSG #esolangs :14[[07Action symbol14]]4 10 02https://esolangs.org/w/index.php?diff=167971&oldid=167968 5* 03Yayimhere2(school) 5* (+112) 10/* how it works */ > 1762939135 202464 PRIVMSG #esolangs :14[[07Action symbol14]]4 10 02https://esolangs.org/w/index.php?diff=167972&oldid=167971 5* 03Yayimhere2(school) 5* (+517) 10/* examples */ > 1762939291 905661 PRIVMSG #esolangs :14[[07Action symbol14]]4 10 02https://esolangs.org/w/index.php?diff=167973&oldid=167972 5* 03Yayimhere2(school) 5* (+133) 10/* Computational class */ > 1762939592 750626 PRIVMSG #esolangs :14[[07Talk:Esolang Quality Rating System14]]4 10 02https://esolangs.org/w/index.php?diff=167974&oldid=106292 5* 03Yayimhere2(school) 5* (+540) 10 > 1762939871 526221 PRIVMSG #esolangs :14[[07Do you remember me?14]]4 10 02https://esolangs.org/w/index.php?diff=167975&oldid=167862 5* 03Yayimhere2(school) 5* (-1) 10 > 1762940195 931223 PRIVMSG #esolangs :14[[07Do you remember me?14]]4 10 02https://esolangs.org/w/index.php?diff=167976&oldid=167975 5* 03Yayimhere2(school) 5* (+27) 10/* Examples */ Added a see also section, with Also? > 1762940317 419460 PRIVMSG #esolangs :14[[07Do you remember me?14]]4 10 02https://esolangs.org/w/index.php?diff=167977&oldid=167976 5* 03Yayimhere2(school) 5* (+42) 10/* Semantics */ > 1762940453 350376 PRIVMSG #esolangs :14[[07Do you remember me?14]]4 10 02https://esolangs.org/w/index.php?diff=167978&oldid=167977 5* 03Yayimhere2(school) 5* (+41) 10/* Semantics */ > 1762940644 281318 PRIVMSG #esolangs :14[[07Do you remember me?14]]4 10 02https://esolangs.org/w/index.php?diff=167979&oldid=167978 5* 03Yayimhere2(school) 5* (+114) 10/* Semantics */ < 1762941082 124137 :tromp!~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1762943944 462043 PRIVMSG #esolangs :14[[07One-Instruction Cyclic Tag14]]4 10 02https://esolangs.org/w/index.php?diff=167980&oldid=154954 5* 03Yayimhere2(school) 5* (-52) 10/* Instruction TAG */ The placement of the tags is weird, so I "fixed" it. > 1762945315 715959 PRIVMSG #esolangs :14[[07Talk:Stroke14]]4 10 02https://esolangs.org/w/index.php?diff=167981&oldid=129057 5* 03Yayimhere2(school) 5* (+1068) 10 > 1762946453 783034 PRIVMSG #esolangs :14[[07Mascarpone14]]4 10 02https://esolangs.org/w/index.php?diff=167982&oldid=123948 5* 03Yayimhere2(school) 5* (+2) 10/* Stacks */ there was a missing "a" to my knowledge > 1762948025 339108 PRIVMSG #esolangs :14[[07InterWater14]]4 10 02https://esolangs.org/w/index.php?diff=167983&oldid=9082 5* 03Tpaefawzen 5* (+47) 10+au +cat > 1762948078 409305 PRIVMSG #esolangs :14[[07VENIAL14]]4 10 02https://esolangs.org/w/index.php?diff=167984&oldid=9049 5* 03Tpaefawzen 5* (+19) 10+catyr < 1762949956 978675 :svm!~msv@user/msv NICK :msv < 1762950444 806976 :APic!apic@apic.name PRIVMSG #esolangs :Hi < 1762950804 35539 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1762951451 958409 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : And I think if it *can't* sort then it's not a computer. ← what if it's able to produce tables of log, sin, cos? (IIRC this was Babbage's original motivation for inventing the computer) < 1762951646 334455 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: still just a calculator to me < 1762951657 861794 :int-e!~noone@int-e.eu PRIVMSG #esolangs :none of this is objective! < 1762951690 19924 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I mean my idea of a calculator is shaped by a pocket calculator that I used in school, which had trignometric and hyperbolic functions < 1762951701 798668 :int-e!~noone@int-e.eu PRIVMSG #esolangs :so it can't be that hard, right ;) > 1762951713 457728 PRIVMSG #esolangs :14[[07Talk:Esolang Quality Rating System14]]4 10 02https://esolangs.org/w/index.php?diff=167985&oldid=167974 5* 03Ais523 5* (+693) 10/* Computational Class points revamp */ thoughts < 1762951979 342845 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Pocket calculators with trigonometric functions are a sin. < 1762952079 35067 :int-e!~noone@int-e.eu PRIVMSG #esolangs :it's for a good cos < 1762952151 250947 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Well, in the burning pit you'll have time to work on your tan. (Okay, that's a stretch.) < 1762952192 42559 :sorear!sid184231@id-184231.uxbridge.irccloud.com PRIVMSG #esolangs :traditional card sorters are much simpler than anything that can do math < 1762952237 994435 :int-e!~noone@int-e.eu PRIVMSG #esolangs :necessary, not sufficient < 1762952299 498131 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :when I was a child I made a mechanical card sorter (in which the numbers to sort by were written in binary using holes and slots along the edge of the card < 1762952351 366799 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although it was mostly manual, you had to move the components into the right place by hand but that was only O(n log n) effort < 1762952366 246258 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(you have to do it log n times, and push the pin through n cards) < 1762952372 235394 :int-e!~noone@int-e.eu PRIVMSG #esolangs :radix sort is still cool < 1762952390 802194 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yep, the algorithm is basically binary radix sort < 1762952415 736999 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although the non-recursive version (sort by lsb, then sort by second-lsb, etc.) < 1762952434 325953 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, I just realised that radix sort is stable < 1762952560 930879 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :It always amuses me when reading the Lensman books when they have faster-than-light inertialess flight, antimatter ("negaspheres") and mind powers, but then rely on punch card databases to sort through people, and mechanical calculators to solve space ship navigation. Here's some choice quotes: https://0x0.st/KpK_.txt < 1762952628 223328 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Imagine solving "course-and-distance problems" at a rate of ten per minute! That's progress. < 1762952636 432844 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :at least in computer games, mixing technology from a large number of time periods, including the plausible future and the implausible future, often leads to a good game even though it doesn't make sense as a setting < 1762952640 632576 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so it wouldn't surprise me if fiction can do the same < 1762952858 645549 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Science did march on a little in the course of the series, it must be said. Those quotes were from a story originally published in 1939; it and the other books near it also consistently used the word "computer" to mean a person who makes computations. But in a 1947 sequel there's a reference to "the big computer at Ultra Prime" where context makes it clear it's an (electronic?) device of some < 1762952860 807129 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :sort. < 1762953169 334948 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :thinking about it, technology that is quick to invent doesn't necessarily correlate with technology that people imagine would be useful < 1762953188 826119 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a good example of a science-fiction technology that actually did turn out to be possible, and get invented, is television < 1762953225 864092 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :even before it was invented, it was quite common for science-fiction stories to have video-based communication devices and I think the word "television" had already been coined before the invention itself was created < 1762953379 628420 :int-e!~noone@int-e.eu PRIVMSG #esolangs :tele-vision is an old magic trope too, add film and telegraph and it's not that much of a stretch? > 1762953745 990789 PRIVMSG #esolangs :14[[07User:RaiseAfloppaFan392514]]4 10 02https://esolangs.org/w/index.php?diff=167986&oldid=167659 5* 03RaiseAfloppaFan3925 5* (+983) 10Added Esolang Quality Rating System ratings < 1762953793 550305 :int-e!~noone@int-e.eu PRIVMSG #esolangs :fizzie: hmm isn't there some science fiction that has space travel and then on board communication uses pneumatic tubes :) < 1762953870 551642 :amby!~ambylastn@host-81-178-157-25.as13285.net JOIN #esolangs amby :realname < 1762955320 910896 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot QUIT :Quit: ZNC 1.9.1+deb2+b3 - https://znc.in < 1762955320 980149 :simcop2387!~simcop238@perlbot/patrician/simcop2387 QUIT :Quit: ZNC 1.9.1+deb2+b3 - https://znc.in > 1762955953 89128 PRIVMSG #esolangs :14[[07Thueue14]]4 N10 02https://esolangs.org/w/index.php?oldid=167987 5* 03Yayimhere2(school) 5* (+1517) 10Created page with "'''Thueue''' is a [[dequeue]] based [[Thue]] style esolang. It can too do replacements, however only at the start and end of the string, and only on individual elements. == Semantics == Thueue uses the following syntax: ''D'' 1 [''x'']$ [''y'']$ < 2 [''x''] > 1762955974 35263 PRIVMSG #esolangs :14[[07Thueue14]]4 10 02https://esolangs.org/w/index.php?diff=167988&oldid=167987 5* 03Yayimhere2(school) 5* (-2) 10 > 1762956158 238917 PRIVMSG #esolangs :14[[07Thueue14]]4 10 02https://esolangs.org/w/index.php?diff=167989&oldid=167988 5* 03Yayimhere2(school) 5* (+23) 10/* Semantics */ > 1762956236 984243 PRIVMSG #esolangs :14[[07Thueue14]]4 10 02https://esolangs.org/w/index.php?diff=167990&oldid=167989 5* 03Yayimhere2(school) 5* (-23) 10/* Semantics */ > 1762956573 253042 PRIVMSG #esolangs :14[[07Talk:Bitwise Cyclic Tag14]]4 10 02https://esolangs.org/w/index.php?diff=167991&oldid=122871 5* 03Yayimhere2(school) 5* (+156) 10/* Turing-completeness of BCT without arbitrary memory string as input? */ > 1762956842 210464 PRIVMSG #esolangs :14[[07User:Yayimhere14]]4 10 02https://esolangs.org/w/index.php?diff=167992&oldid=167870 5* 03Yayimhere2(school) 5* (+13) 10/* esolangs */ > 1762956881 614611 PRIVMSG #esolangs :14[[07Thueue14]]4 10 02https://esolangs.org/w/index.php?diff=167993&oldid=167990 5* 03Yayimhere2(school) 5* (+0) 10/* Semantics */ < 1762956928 432494 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1762956949 7260 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan > 1762957095 590440 PRIVMSG #esolangs :14[[07Talk:Bitwise Cyclic Tag14]]4 10 02https://esolangs.org/w/index.php?diff=167994&oldid=167991 5* 03Ais523 5* (+306) 10/* Turing-completeness of BCT without arbitrary memory string as input? */ r to Yayimhere: you can just pad out the productions to ignore the extra digits < 1762957244 310796 :pr1sm!~pr1sm@24.91.163.31 JOIN #esolangs * :pr1sm < 1762958434 296554 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Remote host closed the connection < 1762958438 746176 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :I feel like one Lensman book had a speaking tube (not pneumatic, just your regular old tube), but I couldn't find it easily. < 1762958450 172205 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse < 1762958468 271544 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :They talk a lot about tubes because there's also multiple plot-relevant "hyperspatial tubes" (read: wormholes). < 1762958506 907692 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fizzie: well if you think about the world before the telephone is invented, it's unclear whether working electronic sound transmission or hyperspatial wormholes will be invented first < 1762958516 512152 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can probably imagine both of them and have no idea how to implement either < 1762958610 336132 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Fair, though this isn't a pre-telephone story. They do have ("ultra-wave") radios for at least ship-to-ship communication. > 1762958770 517491 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=167995&oldid=167939 5* 03Python yyds 5* (+143) 10 > 1762958787 113026 PRIVMSG #esolangs :14[[07User:Python yyds14]]4 N10 02https://esolangs.org/w/index.php?oldid=167996 5* 03Python yyds 5* (+212) 10Created page with "==Introductions== Python_yyds Hi world,I'm Python_yyds! I think esolang is interesting so I join it.~~~~" > 1762958822 817881 PRIVMSG #esolangs :14[[07CContains14]]4 10 02https://esolangs.org/w/index.php?diff=167997&oldid=150307 5* 03Yayimhere2(school) 5* (-20) 10Changed an incorrect title into a lowercase < 1762958828 774175 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :The hero "donned his headset" to ask for reports from different parts of the ship, so I think they're using something telephone-like also for intra-ship comms. > 1762958920 52380 PRIVMSG #esolangs :14[[07User:Python yyds14]]4 10 02https://esolangs.org/w/index.php?diff=167998&oldid=167996 5* 03Python yyds 5* (+69) 10/* Introductions */ < 1762958935 248688 :amby!~ambylastn@host-81-178-157-25.as13285.net QUIT :Ping timeout: 240 seconds < 1762958993 835761 :int-e!~noone@int-e.eu PRIVMSG #esolangs :. o O ( we'll sooner have flying cars than ubiquitous transcontinental real-time communication ) < 1762959034 875601 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: ooh, that's a tough one < 1762959122 302539 :amby!~ambylastn@host-78-151-24-169.as13285.net JOIN #esolangs amby :realname < 1762961350 369859 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: did you write https://esolangs.org/wiki/Algebraic_Brainfuck ? (i followed it from your RPython code) < 1762962106 339957 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: if yes, then i've reached "As a monoid", which i didn't yet read, but i already have two questions: 1. {scalemove,move}2 should probably be a specific subset of a more generic thing with N offsets and M values. I don't know whether that's a limitation of the listing syntax. and 2. i don't get omega (what it's good for). i can tell it's either no-op or an infinite loop, depending on whether k is 0 or not, respectively, but not why it's on this list. < 1762962202 43774 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(if that's explained later, just let me know. i'll get later eventually) > 1762962339 190514 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Cyclic Tag 5* 10New user account < 1762962393 254049 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :or maybe omega is on that list because otherwise there are some bf programs which cannot be represented with only the other items on that list? like an observable side effect that the program never stops? > 1762962412 576670 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=167999&oldid=167995 5* 03Cyclic Tag 5* (+301) 10 < 1762962432 879046 :int-e!~noone@int-e.eu PRIVMSG #esolangs :avih: it's a nonterminating piece of code, and the name is probably inspired by Combinatory Logic < 1762962455 42500 :int-e!~noone@int-e.eu PRIVMSG #esolangs :you could have rules like omega(k) x = omega(k) but nothing like this appears to be done there < 1762962464 802786 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(for k != 0) < 1762962475 626772 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :int-e: it's not necessarily non terminating, but it can be, yes. however that's not what i asked. < 1762962489 278260 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i asked why it's on this list. < 1762962532 718548 :int-e!~noone@int-e.eu PRIVMSG #esolangs :it's an absorbing element for a ton of stuff in the monoid < 1762962540 636883 :int-e!~noone@int-e.eu PRIVMSG #esolangs :but the page doesn't do anything with that (yet?) < 1762962569 729124 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ok, then i'm again bumping into my monoid no-knowledge issue. thanks. < 1762962691 682030 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :int-e: and do you know why {scalemove,move}2 exist explicitly on that list, and not implicitly as a subset of a more generic N pairs of (offset,value)? < 1762962719 311478 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :is that a limitation of the syntax used there? < 1762962801 99711 :DOS_User_webchat!~DOS_User_@72.red-88-1-117.dynamicip.rima-tde.net JOIN #esolangs * :[https://web.libera.chat] DOS_User_webchat < 1762962808 439259 :DOS_User_webchat!~DOS_User_@72.red-88-1-117.dynamicip.rima-tde.net CHGHOST ~DOS_User_ :user/DOS-User:11249 < 1762962846 18003 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :or is it because scalemove,move and scalemove2,move2 together are the building blocks which allow to express any set of N offset,value pairs? < 1762962915 277656 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I don't know. I guess the syntax is limited to a fixed number of arguments and http://www.cs.tufts.edu/~couch/bfmacro/bfmacro/ stops at move2() < 1762962955 66004 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(but then move is a subset of scalemove, so it could be removed too... i don't think i get what this list is supposed to represent, other than some list of possible macro definitions, not necessarily a minimal one) < 1762962971 527508 :int-e!~noone@int-e.eu PRIVMSG #esolangs :anyway, yeah, if you want the author's thoughts you'll have to wait for korvo to reply < 1762962992 697419 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :k, thx < 1762963043 152053 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(or, if idling on IRC isn't your thing, try the talk page(s)) < 1762963086 596383 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :the bouncer works for me ;) < 1762963107 792223 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it's not like i'm sitting and waiting for a reply.... < 1762963215 100893 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 QUIT :Ping timeout: 250 seconds < 1762963285 102448 :DOS_User_webchat!~DOS_User_@72.red-88-1-117.dynamicip.rima-tde.net JOIN #esolangs * :[https://web.libera.chat] DOS_User_webchat < 1762963289 906157 :DOS_User_webchat!~DOS_User_@72.red-88-1-117.dynamicip.rima-tde.net CHGHOST ~DOS_User_ :user/DOS-User:11249 < 1762963432 174431 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: and somewhat regardless, if your code (which i didn't try to follow yet) merely represents the program in some immediate translation to this or a similar form, and the performance comes from being executed efficiently? or does it also include some additional (post?)processing steps (optimizations) which aim to simplify the expression into fewer expressions, which translates immediately to shorter execution time? < 1762963448 762505 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :s/if your code/is your code/ < 1762963500 490567 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(like identifying redundancies and removing them from the expressions) < 1762963730 419999 :DOS_User_webchat!~DOS_User_@user/DOS-User:11249 QUIT :Remote host closed the connection < 1762964107 731063 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :and finally, assuming it does apply known equivalence rules (your program), does it end up in some optimal list? or is it only optimal for some subset of knowledge which can theoretically exist about a bf program? < 1762964277 394995 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :fwiw, while my interpreter is reasonably quick in some cases, i want to remove any specific "macros", and base it purely on observable side effects, hopefully ending up in some optimal execution list (wishful thinking). < 1762964298 831354 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I can answer this one, algebraically optimising BF will not necessarily reach a theoretically optimal point because optimally optimising a program is undecidable < 1762964317 757116 :int-e!~noone@int-e.eu PRIVMSG #esolangs :avih: anyway, "monoid" here is just a fancy term to capture the concatenation operation of programs with basic properites: there's a unit e (the empty program) with ex = xe = x for all programs x, and concatenation is associative, (xy)z = x(yz) < 1762964336 971319 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, you can imagine a program that searches for counterexamples to the Goldbach conjecture, that probably optimises into an infinite loop but good luck proving it < 1762964342 993986 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :int-e: yeah, i got that. i just read the monoid subsection. < 1762964415 340699 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: not familiar with the specifics, but yeah, i think i get the point, at least roughly. < 1762964419 919395 :int-e!~noone@int-e.eu PRIVMSG #esolangs :the definitions on the page seem to have mixed purposes... some are useful for translating into brainfuck; some others are useful for analyzing, optimizing, standardizing, and maybe compiling brainfuck < 1762964467 777581 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :int-e: my point exactly. i don't get what it's supposed to represent other than some set of macros. > 1762964484 575894 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Losbos 5* 10New user account < 1762964638 994958 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i hoped that it would represent some minimal set which is able to represent any bf program, and which is easy to optimize. but that minimal set has to be plus(int),right(int),loop(code),input,output < 1762964754 532266 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(there are likely other sets too, but this is the most obvious) < 1762964864 587437 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1762964909 624405 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 256 seconds < 1762965034 148476 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life < 1762965077 957155 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: re not possible in general, i think it should be possible to reach have some theoretical optimal result under some known constraints for the compiler, such as complexity of processing the input before starting execution. does that feel about right? < 1762965140 567791 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: hmm, that's interesting, "best available optimisations given a given computational class for the compiler" < 1762965158 96661 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I think it's still undecidable, any valid optimisation could be special-cased so you can do it in O(1) < 1762965169 357525 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :like, if you say the compiler is only allowed to run in O(N), then there must be some theoretical result of the most it can do with the program. same for O(N log N), etc < 1762965202 514175 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :some real compilers do have some special cases like that, e.g. clang recognises a common way to write the count-set-bits function and optimises it into the processor intrinsic < 1762965229 682962 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it'd take a lot of effort to prove that optimisation correct, but clang doesn't have to because it just matches the pattern directly, so it doesn't slow the compiler down at all < 1762965240 621777 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(at least in a computational-complexity sense) < 1762965375 522782 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :sure. pattern matching is one way to do that, but for that you need to collect a list of patterns. my approach is to ignore patterns, or at least only consider known basic equivalences, and on top of that build the execution list based on observable side effects < 1762965439 661720 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: it would be hard to come up with a theorem about this because it is not well-defined < 1762965459 261898 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :what's not well defined? observable side effects? < 1762965473 872447 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :"known basic equivalences" < 1762965488 997546 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :indeed. i hoped that would not be the case < 1762965490 493185 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs ::) < 1762965621 687983 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :currently my known equivalence is that a loop which effectively doesn't moves the head and modifies the head data by 1 is a counter. < 1762965646 392265 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, no, that one isn't actually true < 1762965653 309847 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because the head cell can be moved in an inner loop < 1762965655 466813 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* modified < 1762965665 882438 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess it's true if you don't allow inner loops to modify the looped-on cell either < 1762965673 514671 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, it won't necessarily be true that every iteration will do the same thing < 1762965717 615941 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :that's included in "doesn't move the head". obviously it's recursive for internal loops too. if an internal loop moves the head by unknown amount then it cannot be considered "not moving the head" < 1762965784 695982 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: no, I mean things like [->[-<+>]<] < 1762965799 914975 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it comes down to how much can you know about the state, and that's limited by the constraints you put on the compiler in terms of computational class < 1762965840 375824 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :sec, let me get what it does < 1762965877 898532 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(admittedly this specific example isn't useful, more complicated versions can be TC though) < 1762965969 361592 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: it cannot be said that it changes the counter by 1, at least not in some way which i can tell trivially < 1762966008 220527 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: right – the structure is "counter loop containing a balanced loop" but the inner balanced loop overwrites the counter < 1762966015 7601 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it has some interaction of the outer head value with the inner loop. if you could conclude that it's 0 (which you can't), then it would have been a counter. > 1762966134 414952 PRIVMSG #esolangs :14[[07One-Instruction Cyclic Tag14]]4 M10 02https://esolangs.org/w/index.php?diff=168000&oldid=167980 5* 03Aadenboy 5* (-12) 10 < 1762966172 188905 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :anyway, the idea is to collect knowledge as the program is processed, and maintain some known state at any point in time (this might include actual known values, but also knowledge that some cells have unknown values), and based the execution list creation on top of that < 1762966240 356683 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :and a loop which ends up moving head by an unknown amount means we now know nothing, and throw away all our existing knowledge. < 1762966380 188041 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(but sometimes we can know that amount, for instance if we know the loop moves the head left by 1 on each iteration (until head cell has value 0), and we also know that the previous cell has value 0, at which case we don't have to drop our knowledge. < 1762966495 401383 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(and we also know it's not actually a loop, but at most an "if") < 1762966606 100285 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :the interesting parts are 1. how to represent the knowledge and with which limitations. 2. how to produce the execution list using this knowledge. and i already have ideas for both. < 1762966798 893055 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :in a nutshell, the knowledge is respectively, the last known instruction per cell (which we may or may not have), and producing the list means we have to "flush" the knowledge as instructions as soon as we have to lose the knowledge about a cell - and if some other cell depends on the current value of this cell. example of when we have to drop the knowledge about cell X is when there's input into cell X. < 1762966932 804300 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :so before we store this new knowledge (that X is now unknown input), we have to "flush" (produce instructions which sets the cell with our existing knowledge - and everything else which depends on the value of this cell). < 1762967005 828112 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :and if each instruction can depend only on one other cell (and some constants), then it _should_ be a relatively simple graph. < 1762967050 913149 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :hopefully maintainable in no more than O(N log N), but not sure about that yet. < 1762967211 428837 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: To answer your biggest question: the "scale" and "move" terminology comes from bfmacro. The algebraic rules for those ops come from common lore; I collected them from various Brainfuck compilers and interpreters. < 1762967213 34064 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :an example of what such framework should be able to produce, for instance, is to translate the classic hello world program into a series of putchar instructions (each with an immediate value) < 1762967272 44085 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: IOW, they're some patterns which bf interpreters apply? < 1762967316 835870 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: Also, yes, there is an optimal TC fragment of the monoid given by loops over pointer-propagating terms. I don't know what its rank is; for a [[monoid]], its *rank* is the minimum number of letters in any equivalent syntactic monoid. (Intuitively: the smallest alphabet that still faithfully represents every program.) < 1762967326 289873 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :"TC" ? < 1762967334 516721 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: Yeah. That's not an original page at all; it's 100% collected lore. < 1762967348 401346 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :gotcha. what's "TC"? < 1762967374 827171 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, sorry. Turing-completeness. For a monoid, Turing-completeness usually means that it's not possible to decide whether an arbitrary term is in normal form. < 1762967388 781197 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :right < 1762967397 192778 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(why didn't i think of that?!) < 1762967401 97754 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(TC) < 1762967421 338042 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(It's okay, I'm prone to overusing jargon. I don't mind being asked to rephrase or simplify.) < 1762967454 33164 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it's ok, i don't mind asking if i don't get something, or at least declaring that :) < 1762967486 669418 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: Have you encountered the concept of *abstract interpretation* yet? It fits cleanly into the monoidal way of doing things and it formalizes your idea about having partial knowledge of the current runtime state. < 1762967504 75363 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :no < 1762967523 723465 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but it makes sense that i'm not the first to think about such model :) < 1762967575 164764 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Your idea makes plenty of sense. The idea is that a concrete interpreter computes *exactly* the right answer, but could spend unbounded time doing that; an abstract interpreter only *approximates* the answer, but never visits any part of a program more than a fixed number of times (often just one visit!) < 1762967623 890298 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ideally just once, but i don't know whether that's possible. < 1762967652 611087 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :or rather, whether O(N) is enough for whatever definition of ideal. < 1762967654 121405 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :My bf.py RPython interpreter uses abstract interpretation to do the optimization. It takes input expressions and splits them up into primitive pieces of the monoid, and then reassembles them step-by-step. TBH this is *not* the only way to do it, but it is very neat because part of the approximated value is the optimized program! < 1762967743 239008 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it does sound very neat. mind showing me the list of instructions it produces, if at all, for this? https://0.vern.cc/b.txt < 1762967772 98208 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, there will always be programs that you can't idealize. Suppose we write out the Goldbach conjecture as a program: for every even number, look for a pair of primes that sum to it; if there's no such pair, halt. The optimal representation of that program is either something like +[] or the empty program, depending on whether the conjecture is true. < 1762967802 906962 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :is your execution based on a list of instructions of some sort? like some IR of some machine model? or is the execution more implicit evaluation of something? < 1762967868 140021 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(2nd time "Goldbach conjecture" is mentioned. i really should check out what that is) < 1762967870 561372 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :https://bpa.st/GTNQ < 1762967923 367267 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :hmm.. so basically it "simplifies" the bf code into other bf code, and then executes it bf instruction after the other? < 1762967941 868895 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The abstract execution's based on the original monoid at the [[Algebraic Brainfuck]] page. I might switch over to the pointer-propagation monoid but that likely will require changing the entire frontend of the interpreter up to the parser. < 1762967981 636405 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The concrete execution's based on chaining basic blocks of actions, where each action has access to the tape and pointer, can do I/O, and must return an updated pointer. I picked this representation because it's JIT-friendly. < 1762968062 311058 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i see. but it still follows the original flow of the code. for instance it _can_ know, if it tried, in O(N) probably, that it produces a fixed list of output values < 1762968132 758034 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh! Yeah, the abstract interpreter doesn't currently simulate knowledge about the tape. There's a reason for that; algebraically, Brainfuck doesn't know what the tape's topology is like, so behavior which depends on that topology isn't safe to optimize around. < 1762968203 651633 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :*That* is because this codebase has a responsibility to generate *canonicalized* versions of programs; it doesn't try to outsmart the program author. This isn't like GCC or LLVM, which have lots of hacks in order to catch bad code written by users. < 1762968215 986603 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :in my model, where the only pattern it cares about is a counter loop, it should be able to know all the cell values before they're being printed, and therefore create a list of putchar statements of immediate values, where the cell values themselves has nothing which depends on them, and it's not an observable side effect, and therefore should disappear from the execution list completely < 1762968263 539232 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it does know the initial state. < 1762968272 823072 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Is unrolling the loop going to shrink the overall size of the code? It's undecidable, actually! In your case, the loop is only representing an initialized tape, but if the loop does any I/O then it wouldn't be possible to examine. < 1762968281 859740 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :that's enough to deduce the whole output in this specific case in one pass < 1762968325 756637 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it won't necessarily shrink the code size, but almost certainly reduce execution duration < 1762968368 822738 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sure. So, here's where I actually use bf.py: https://bbgauge.info/brainfuck.html These programs likely reduce to either +[] or [] depending on whether their underlying mathematical statements are true or false. We *don't know* the actual answers, but we can imagine how *hard* it would be to solve the problem by looking at how big the programs are. < 1762968375 77261 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :especially if loops end up running more than once < 1762968470 292009 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: tangentially related to the BB gauge (although not directly relevant), so you might be interested in it: https://codegolf.stackexchange.com/questions/97004/does-the-code-terminate-nobody-knows < 1762968478 790221 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i think this entire statement is based on me grokking that page you linked? < 1762968538 758767 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Yeah! I think I've got most of those documented here: https://bbgauge.info/problems.html < 1762968602 368784 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: Probably. But the short version's not hard to appreciate: when we don't know how hard something is, but we do know what the associated computation looks like, then we can compare the computations instead of the original thing. The computations are like representations of the thing. < 1762968637 878572 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: i do find it fascinating that your program is only second to Laurent's, because his code definitely unrolls multiplication loops, and then jit it. obviously i believe you, but i don't see how it can be... < 1762968706 205655 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: yeah, i do roughly understand it and think so too. < 1762968707 230408 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: RPython has a builtin unroller; every trace is unrolled and gets a prologue, because the traces can only be started at the top of while-loops. < 1762968788 227452 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :interesting. so basically you say you merely crunch the bf program slightly, and then let RPython grok and optimize it? < 1762968829 871007 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :akin to produce some c code from bf program, naively or near enough, and then let gcc do what it does? < 1762968891 219062 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :fwiw, while gcc is very good at optimizing such naive translation to c, it's meaningfully slower than a translation which unrolls multiplication loops. < 1762968921 48803 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yes. But without using libgccjit or libllvm. Here's an example JIT trace from running mandel.b: https://bpa.st/VSJA < 1762968921 671248 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i.e. compiling a native translation vs compiling a translation which unrolls mult loops < 1762968976 580368 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :sure. hence "akin" :) < 1762968981 289663 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Those merge points used to hold BF code; they would just print out the code like ">" or "+". But the IR no longer admits a nice pretty-printed format quickly, and jit_debug strings need to be constant for speed. < 1762969020 628504 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :so where is this optimizer? NIH RPython stuff? < 1762969035 791877 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Otherwise it's just SSA. Crucially, it's not *my* SSA; it's RPython's generated SSA that it built *while compiling* my interpreter. The SSA is roughly similar to what you'd get when debugging PyPy, and you can see that I'm really just using PyPy's environment variable to control the JIT. < 1762969059 850694 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(or s/NIH/own/ ;) ) < 1762969072 44251 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :"SSA"? < 1762969123 231958 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :https://rpython.readthedocs.io/en/latest/jit/optimizer.html is probably what you want to read. It's a very simple optimizer: one forward pass over an SSA IR, doing the standard Frances Allen optimizations like propagation and dead-code removal. Every trace is taken over *two* iterations of a loop, and that allows partial unrolling and a prologue just by comparing the iterations to see what changed. < 1762969140 751572 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Single Static Assignment. A property of IRs where a name is only assigned once, and never mutated. < 1762969142 177879 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :my question was where, not how ;) < 1762969160 683420 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but i get it, rpython has an optimizer of its own. < 1762969206 48025 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sorry, "where" seems loaded. Like, I know where to find https://github.com/pypy/pypy/blob/main/rpython/jit/metainterp/optimizeopt/unroll.py and I'm not going to hide it from you, but it's not a fun read. < 1762969208 560947 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :thanks. i roughly get it, but not familiar with the subject and terminology in general. < 1762969236 495306 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(but i get that it represents some class of IRs which have some known capabilities) < 1762969258 879865 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh! Okay, no worries. So, lucky 10000 for compiler engineers: most serious compiler backends use some sort of SSA. They have many many names for it, but the SSA property is really common. LLVM is a good example of a system that uses SSA. < 1762969284 629815 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :s/capabilities/properties/ < 1762969361 415386 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :yeah, i thought that might be the case, though had zero specific knowledge of it till now (and even now only the name and a property which i get, but not yet "expanded" mentally) < 1762969375 447188 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :If you were to suffer through a university compilers course, you'd either be given SSA or CPS (continuation-passing style, mind-hurting, usually means the school teaches Haskell, Scheme, or OCaml) as your paradigm. Probably also *basic blocks*: a hunk of code that does some ALU operations and then (conditionally?) jumps to another block. These are not easy concepts but they are ubiquitous in modern compilers. < 1762969435 734252 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :yeah, never got there myself :) i aborted my masters into the world of internet startups ;) < 1762969464 446967 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :and never took compiler courses in undergrad either < 1762969516 140558 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :was never into that really, but now, all those years later, bf brought me to it ;) < 1762969521 50188 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I get it. I was poached out of undergrad by Google, and because I'd pivoted from a music degree, I missed out on a lot. I've been cramming lectures from Youtube and reading papers for years, but I'm sure that there's still little gaps in my knowledge. < 1762969579 712237 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :who's knowledge doesn't have gaps? :) < 1762969627 526810 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but anyway, i do find it interesting, and hope i'll be able to implement the model of partial knowledge i described earlier. sounds cool to me, at least before the 1st line of code ;) < 1762969664 150531 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(i do have other bf code, but this is your standard patterns based) < 1762969703 984268 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah! Take your time; abstract interpretation is tough to understand, and I don't read French so I'm sure that I'm missing details in translation. But the overall approach that you're thinking of should work. < 1762969753 158609 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i think so too, the question is howhard it would be to turn it into reasonable code < 1762969792 654242 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :and c might not be the best for that, but it's my current weapon of choice < 1762969815 92189 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Just over the horizon, there's the field of *partial evaluation*. Given a Brainfuck program, and partial knowledge about the tape, we can produce a *residual* program that includes that knowledge and might be simpler or faster. < 1762969851 856876 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i get that < 1762969874 20382 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :This eventually leads to Futamura projections, which are what RPython actually does: we give RPython an interpreter and RPython gives us a compiler. There is a standard book on the topic, usually just called The Book, that you will want to read if you want to *hack* on any of these JIT toolkits: https://archive.org/details/springer_10.1007-3-540-47018-2 < 1762969922 472499 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, yeah, C sucks. The main issue with C is that, since it's not memory-safe, you have to fight two battles; you have to make sure that your interpreter's behavior is correct and also you have to not mess up memory accesses. < 1762969924 890078 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it's another way to look at my model, but in some way also the exact way to look at it. because the instruction it produces don't necessarily align with its source. it only cares to produce the observable side effects. so things could be out of order, etc < 1762969962 266982 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :C also lacks for abstractions. Something like ML is almost inevitable, or at least ML-style modules: SML, OCaml, Haskell, etc. < 1762970026 857392 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :not worried about memory access (as in, i rarely have such issues), but the challenge is making it do the work readably < 1762970077 475528 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i.e. write it in such a way that the abstraction is not buried at the low code levels, but rather out in the open < 1762970114 80162 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The Book has a couple sections on partial evaluation of C, BTW. They prototyped a *self-applicable specializer*: a program written in C that can optimize C programs and produce residues in C. (The Book will also explain why specializers have exactly three associated languages.) < 1762970138 167309 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :and of course, specify "the work" exactly first. currently i only have a mental model of what it does and how, but not yet the specifics < 1762970195 202219 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :which book is that? < 1762970200 549086 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(or did i miss it?) < 1762970251 504011 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :"Partial Evaluation: Practice & Theory", particularly the free 1998 PDF from archive.org linked above. < 1762970270 80488 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :the reason i like c is that it's probably the most portable language and relatively easy at that. i.e. you have a c compiler anywhere. < 1762970299 270166 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :oh, i did miss that. thanks. < 1762970340 532130 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I'd disagree with both of those, but I'm fairly biased; I've been part of multiple efforts to push memory-safe languages in the industry. C is a hack that arose because Unix was written for machines that didn't have enough memory to compile Fortran. C was what worked at the time. < 1762970352 568194 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But sure, C's a decent enough prototyping language. < 1762970362 111944 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :roughly the same with sh, btw, at the other end of the spectrum under some points of view :) < 1762970407 135188 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i find c and sh interestingly complementary, and together sort of complete. < 1762970448 584728 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Well, yeah, shell's a terrible hack. But shell's also an example of a *toplevel*, a system prompt that is always shaped differently from the internal REPL because it has to support interactive actions. ML and Smalltalk traditions have them too. < 1762970494 415347 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :yeah, though never used those. not even lisp et al. < 1762970524 444191 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I'd like to link some advice from multiple language designers: https://lobste.rs/s/vs08dv/how_design_new_programming_language_from The topic is whether C is a good language for compilers, and we explain the nuances fairly well. < 1762970535 652571 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i mean, i know how it works etc, but never tried anything in it. < 1762970571 896796 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(I'm the one in the green shirt. "...it implies that C is the preferred high-level prototyping language, which hasn't been true for decades and in fact might have never been true.") < 1762970575 198592 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: "we" as in you're one of the authors? < 1762970579 248048 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs ::) < 1762970600 185818 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :oh, i'm not making any such claims :) < 1762970634 552811 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yes. Andy C.'s another serious author; he works on Oils, a series of languages to replace shell. Drew is the author of Hare, a C competitor that I think is fundamentally flawed from the outset, and it's interesting to understand how Hare's limitations arise from his beliefs about C's practicality. < 1762970636 587062 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :just stated why i liked it. i also like js, and tcl (to a degree), and probably more too. < 1762970695 46035 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :I'm familiar with Oils, if that's the python thing which gets auto translated to c to produce a posix shell? < 1762970714 36389 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :c-cube is an OCaml maintainer. Danila F. teaches type theory and works on...Rocq, I think? S. Jamaan works on CHICKEN Scheme, related to Lisp and C. < 1762970773 855396 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i might have a look at some stage (at least skim it), but i don't expect to fully go over it (and the rest of the resources). but then, who knows... < 1762970817 325267 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :No worries. Language designers are used to having opinions about languages, but most folks don't really think about it other than what they need for the task at hand. Never forget: the average developer has 2.5yrs of experience and only knows either EMCAScript or Python. < 1762970829 942955 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i don't have a fixation for any specific language, but i'm more experience with imperative ones < 1762970837 960878 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :+d < 1762970865 934827 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i like whatever i can use to get the job done. < 1762970959 849611 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :and this tends to be things i have more experience with. not due to some inherent property of the language. < 1762970974 359458 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I like whatever I can use to express the task succinctly and without weirdness. Short programs are good. Programs that could expose weirdness are bad. Weirdness is when a machine does things that are outside the intended programming model: https://en.wikipedia.org/wiki/Weird_machine < 1762970983 622365 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :yup < 1762971026 857359 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(damn, 9s to respond, but i did go over all of it and did agree right away...) < 1762971093 35965 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, I'd have believed that you'd heard of this before. It was a big splash in security-research circles, and those of us into speedrunning had already known about the phenomenon for a while but didn't have a good name. Reference (1), Bratus.pdf, is a really good read. < 1762971144 727814 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :was not aware of that splash. i just read it and i think the same < 1762971196 695982 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(i obviously did not visit the link, but i agree and get what it might have regardless) > 1762971248 982796 PRIVMSG #esolangs :14[[07EUCS14]]4 10 02https://esolangs.org/w/index.php?diff=168001&oldid=167726 5* 03Hammy 5* (+231) 10 < 1762971249 978217 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :https://langsec.org/papers/Bratus.pdf It's got Sassaman as a co-author! Might have been his final paper. Wonder if we can get people to call them "Sassaman machines" instead. < 1762971329 194265 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Malbogoids > 1762971369 404746 PRIVMSG #esolangs :14[[07Turing Torment14]]4 10 02https://esolangs.org/w/index.php?diff=168002&oldid=167747 5* 03Hammy 5* (+43) 10/* Commands? */ < 1762971426 548982 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(I do consider Malbolge to be a Weird Machine) > 1762971488 275403 PRIVMSG #esolangs :14[[07Turing Torment14]]4 10 02https://esolangs.org/w/index.php?diff=168003&oldid=168002 5* 03Hammy 5* (+0) 10/* Examples, I guess? */ < 1762971723 692880 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: btw, do you think it's conceivable that rpython turns your output to the equivalent of printing a fixed string? < 1762971756 968405 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: No, it's not structurally capable of doing that, I think. < 1762971760 833259 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(re https://bpa.st/GTNQ ) < 1762971771 60684 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: because Malbolge doesn't have an intended programming model? < 1762971802 411108 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: yeah because it's basically designed to make looping programs humanly impossible to realize (and failed, but that took quite some time) < 1762971825 747653 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think a better viewpoint is that Malbolge *contains* a weird machine < 1762971836 585866 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :possibly more than once < 1762971842 591156 :int-e!~noone@int-e.eu PRIVMSG #esolangs :oh, maybe < 1762971862 347434 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :int-e, ais523: Taking this to its obvious conclusion, maybe the typical ISA is like a least-weird machine. < 1762971865 210885 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the whole stable-instruction / stable-NOP thing seems like an intentionally constructed weird machine to help make programming in the language easier to understand < 1762971887 251793 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: in such case, my (limited) experience with what gcc can do with various levels of bf-translated-to-c makes me think that it cannot be that fast. or at least i've not seen anything like it so far. < 1762971892 532130 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I feel like freestart Malbolge is well within my programming capabilities at this point, but I have no idea how to get the program started < 1762971903 566275 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like, an instruction that is always encoded as a single constant byte and always performs an ALU op that can be written as a linear/affine whatever of register bits, only having local effects, is sort of a best case. (Or, as Zim would say, worst case?) < 1762971944 844733 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: of course, typical ISAs are often more complicated than that < 1762971963 159613 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you kind-of need an extreme RISC to get something that's that conceptually simple < 1762971965 417911 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: It works because of a Pareto phenomenon: most hot loops are small and the program spends most of its time in relatively little code. As long as the JIT does well on those hot loops, it does well on the whole program. < 1762971977 855960 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :also, transport-triggered architecutres are conceptually even simpler < 1762971978 617017 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it would be interesting to see what rpython produces which then gets executed. < 1762972004 369900 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(except for how you do indirect memory access, which is conceptually complicated in one of those, you might need an extra level of indirection) < 1762972025 916423 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: yeah, i do get that. as i said gcc does an amazing job on naively translated bf to c < 1762972028 242187 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Sure. I'm thinking that you could see the typical ISA as like Malbolge, except that it's got the simplest kind of Malbolge-style encryption, and the clearest kind of Malbolge-style arithmetic, and... < 1762972045 455322 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Just to imagine a poset of weird machines over a single physical object, really. < 1762972047 817612 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :so i guess it's in the same neighborhood of things < 1762972071 621813 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: hmm, so I feel like the difficulty of Malbolge is in how the instructions interact with the encryption < 1762972088 228088 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Malbolge's "mistake" is that it has too many NOP-s, making NOP-cycles quite likely in a random permutation. < 1762972102 508457 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the instruction set isn't, in isolation, that terrible in an absolute sense, but it is really verbose < 1762972104 949807 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: Sure. In that specific case, GCC has a structural advantage; they implement "polytope" or "polyhedral" modeling for loops. It's the kind of thing that horribly increases compiler times but enables this highly-generalized loop-unrolling behavior that you're imagining. < 1762972120 494457 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and cares a lot about constants that Malbolge source code can't easily express < 1762972147 29265 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :gotcha < 1762972151 221638 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I mean, I don't know whether these are there by design... but I find it easy enough to believe that they're accidents. > 1762972162 460359 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168004&oldid=167962 5* 03NTMDev 5* (+1650) 10 < 1762972167 377801 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and this interacts with the encryption because the verbosity makes stable programs harder to write and the lack of expressing useful constants makes initialization harder (with initialization being the main reason Malbolge is difficult) < 1762972188 536417 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :most ISAs don't have this interplay between their semantics and their encoding < 1762972223 582114 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: well, there are plenty of other features of Malbolge which seem almost impossible that they're intentional < 1762972224 818695 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but i was not talking about this specific case. even in mandelbrot.b, gcc -O2 of 1:1 native bf-to-c translation is barely 2x-3x slower than very good bf-to-c result < 1762972268 812658 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: there are also way too many sheep and poodles in the clouds :P < 1762972282 793297 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like encrypting the instruction before a jump target, or the undefined behaviour (and usually segfault in practice) you get if you self-modify an instruction when D=C, or the infinite loop when trying to execute an instruction outside the ASCII range < 1762972289 631846 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but where it does differ, is hanoi.b. in that case, naive translation can result in an order of magnitude difference (or more, i didn't estimate, but it's a huge diff) < 1762972355 583990 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: So, have you read the pointer-propagation section yet? I only recently saw this, but I think that this is the true path forward. It unifies pointer movement and tape increments into a single big behavior, which should also unify some idiom-detection and loop-detection. > 1762972374 206101 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168005&oldid=168004 5* 03NTMDev 5* (-125) 10 < 1762972376 857461 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i think i stopped just there. i did finish the monoid part. < 1762972393 772678 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but i'll read it. < 1762972398 358035 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(Idiom detection is when we detect that a straight-line sequence of instructions, just ALU op after ALU op, can be turned into a smaller sequence of machine instructions. Loop detection is when we detect that a loop has a specific idiom inside.) > 1762972430 587490 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168006&oldid=168005 5* 03NTMDev 5* (+187) 10/* Conditionals / If Statements */ < 1762972492 637077 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: from initial glancing, i feel that goes over my head. i don't think i'm there for that yet. > 1762972508 490817 PRIVMSG #esolangs :14[[07ASTLang14]]4 10 02https://esolangs.org/w/index.php?diff=168007&oldid=168006 5* 03NTMDev 5* (+162) 10 < 1762972535 444412 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :it does feel like an interesting point of view, but i'm not anywhere near getting it < 1762972569 51575 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: It wasn't obvious for me either. Their insight is that we can always absorb any of the four essential actions, + - < >, into this representation. The monoid is just mathematical fluff. < 1762972638 933941 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like, suppose you've got a propagated pointer: you've got the offset, the adjustment, and the list of written tape cells. To absorb + or -, just inc/dec the written tape cell at the adjustment. To absorb < or >, just inc/dec the adjustment itself. < 1762972707 615711 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(BTW, this conversation's the last thing keeping me at the computer. Let me know when you need a break so that I can take 30min to do something else.) < 1762972711 994096 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i mean, i get why a list of anything can represent any sequence of +-><, but not its significance < 1762972775 798689 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i feel like this is a point of view which can result in finding equivalences where otherwise they're not obvious, but not how < 1762972812 152037 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It has to do with reducing the number of ways that a compiler represents an action. To detect an idiom or loop, the compiler needs to know every form of that idiom. [-] and [+] are equivalent. [->+<] and [>+<-] are equivalent. The number of forms quickly explodes; it's the main reason that I don't add more forms to bf.py. < 1762972821 667089 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: go :) thanks for your time. been interesting :) < 1762972867 285757 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :yeah, that's the sense i get as well, but nothing of the specifics of that < 1762972906 154775 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :No worries. This is giving me good ideas for how to improve the article. I'll be back in a bit. < 1762972913 69421 :int-e!~noone@int-e.eu PRIVMSG #esolangs :korvo: so you assume a finite cell size < 1762972916 235476 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs ::) < 1762972924 112435 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(and wrapping arithmetic) > 1762973469 455557 PRIVMSG #esolangs :14[[07HTMHell14]]4 N10 02https://esolangs.org/w/index.php?oldid=168008 5* 03Hammy 5* (+1107) 10Created page with "HTMHell (shortened to HTMH) is a weird esolang by [[User:Hammy]] that looks like HTML ==Commands== {| class="wikitable" |+ HTMH commands. |- ! Command !! Meaning |- | || Must be at the start of the program, if it isn't then start from where it is, if it > 1762975679 758459 PRIVMSG #esolangs :14[[0714]]4 10 02https://esolangs.org/w/index.php?diff=168009&oldid=166992 5* 03 5* (+321) 10 > 1762975700 72644 PRIVMSG #esolangs :14[[0714]]4 10 02https://esolangs.org/w/index.php?diff=168010&oldid=168009 5* 03 5* (+10) 10/* Truth Machine */ < 1762975888 350044 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: https://xkcd.com/1425/ . int-e: “Would you call a friend from half across the world? / If you’ll let us have his name and town and state, / You shall see and hear your crackling question hurled / Across the arch of heaven while you wait.” from 1911 (spoiler: vg vf gnyxvat nobhg genafngynagvp enqvb gryrtenz. vg orpnzr ninvynoyr ng ebhtuyl gur fnzr gvzr nf gur haqrefrn pnoyrf. ab < 1762975894 759844 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ybat-qvfgnapr gryrcubar lrg.) < 1762976453 359002 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ugh, it took way too long to read that rot13 without a translato < 1762976455 384458 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* translator < 1762977665 90376 :tromp!~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343 JOIN #esolangs * :Textual User < 1762979354 197554 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"the average developer has 2.5yrs of experience" => what? how can that be true? do they leave to management after five years in average or something? < 1762979377 616354 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or become rich in 5 years in average and retire forever? < 1762979378 867119 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: partly people dropping out, and partly that the rate of new programmers entering is increasing < 1762979388 570685 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :oh true < 1762979394 487196 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so they form a disproportionate portion of the sample < 1762979453 312806 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"way too long to read that rot13" => that's partly my fault, I deliberately rewrote it to remove some potentially revealing punctuation or capitals so it is spoilered better < 1762979578 226877 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :int-e: Yeah, precisely. I don't mind that particular choice so much, but it's still a choice. < 1762979639 9358 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oddly I find that bignum BF is often easier to implement in esolangs < 1762979656 387983 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wrapping at 256 can be quite difficult to implement because it's a large constant < 1762979660 934554 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Exponential growth is really unintuitive when it comes to snapshots. Regardless of where we stand, it looks like the past is nearly flat and the future is growing unbelievably fast. But the median time that an individual has spent in the field is shrinking because individuals enter the field so quickly. < 1762979683 607401 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and often your native way to represent numbers is either naturally unbounded, or not big enough to represent 256 so you have to use bignum-like tricks anyway < 1762979725 236339 :pr1sm!~pr1sm@24.91.163.31 QUIT :Remote host closed the connection < 1762979743 140316 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I suppose that one consequence of that is that just maintaining the relationships that you currently have, your cohort is going to be an exponentially-small corner of the ecosystem. In order to stay connected, one must endure a constant stream of young folks coming in with half-baked ideas. < 1762980115 43778 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: That said, if we take a slightly narrower cohort, of developers that are actively participating in Stack Overflow, then the median age jumps to about 15yrs of experience: https://survey.stackoverflow.co/2025/developers#education-experience-years-code This tells me something about SO's users compared to the median developer, but it's not surprising that SO users have more experience than average. < 1762980156 387352 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :korvo: that might be because people lie about how much experience they have, especially on SO, to get jobs < 1762980184 700881 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...There's also the possibility of a particular stats bias, *survivorship bias*, since people tend to wash out or burn out of software engineering. < 1762980246 907722 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :stack overflow is mostly a ghost town nowadays (which oddly has made it a much better website) < 1762980247 602684 :int-e!~noone@int-e.eu PRIVMSG #esolangs :korvo: huh, is it really unsurprising? one would think that as your experience grows you get increasingly less out of a platform like that < 1762980254 506713 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like, the typical tenure of a Google SRE is about 2yrs; the reason for that low number is because Google tends to run their SREs hot and burn them out. I lasted slightly longer than average. < 1762980261 66091 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, it's better to use than it was 5-10 years ago even despite the company in charge messing the site up < 1762980279 827145 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :korvo: sure, for Google it's believable < 1762980391 349310 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :int-e: I see a lot of old-timers giving extremely dated advice on the periphery of Stack Exchange, and I think that there's a kind of greybeards' refuge. But I could certainly imagine that if we were to sample users that don't use the rest of Stack Exchange then maybe they'd be younger. < 1762980422 492489 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Like IRC then, I guess. Except IRC isn't so grossly gamified. < 1762980468 688718 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(as far as old people go :P) < 1762980526 967532 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I dislike the gamification on SO both for its own sake, and because the incentives are wrong < 1762980533 903060 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sure. The ancient Greek polis system had (sp?) "gerountia", basically "old man's club", where the old men would sit around and talk about the old days and tell war stories and try to make a good impression on the youth. Not a bad idea in general but *terrible* if used as part of government, as in Sparta. < 1762980537 347638 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the most useful actions are not the actions that give the most points > 1762984575 579358 PRIVMSG #esolangs :14[[07User:Buckets14]]4 M10 02https://esolangs.org/w/index.php?diff=168011&oldid=167951 5* 03Buckets 5* (+11) 10 > 1762984607 921579 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=168012&oldid=167952 5* 03Buckets 5* (+12) 10 > 1762984649 414706 PRIVMSG #esolangs :14[[07Wycq14]]4 N10 02https://esolangs.org/w/index.php?oldid=168013 5* 03Buckets 5* (+311) 10Created page with "Wyq is an Esoteric programming language created by [[User:Buckets]] In 2021. {| class="wikitable" |- ! Command Example !! Instruction |- | Wyq A B || Memory[A] = Memory[A] nand Memory[B] then, Goto address (Memory[B] - 1). |} [[Category:Unknown computational class]] [[Categ > 1762984685 347640 PRIVMSG #esolangs :14[[07Wycq14]]4 M10 02https://esolangs.org/w/index.php?diff=168014&oldid=168013 5* 03Buckets 5* (+68) 10 > 1762984720 64971 PRIVMSG #esolangs :14[[07Special:Log/move14]]4 move10 02 5* 03Buckets 5* 10moved [[02Wycq10]] to [[Wyq]] < 1762984892 280113 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i don't recall how i got here (is it linked from one of the posted links earlier?), but this and the followup are interesting https://blog.regehr.org/archives/140 it's about whether program termination is considered an observable side effect (spoiler: yes in java, no in c++, unclear in c) < 1762985115 487803 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :avih: my optimising interpreter for The Waterfalll Model, if it recognises an infinite loop, compiles it into a deadlock < 1762985130 636485 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, not compiles, interprets it as < 1762985139 930179 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :then in this case it's observable < 1762985152 659420 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this seems to me like the sensible way to optimise infinite loops, I wonder why it isn't more common < 1762985175 12693 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :but the general question is interesting, as well as the differences between languages and their effect on optimizations < 1762985235 684369 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i might know how i got there, probably while reading about compiler optimizations. < 1762985288 652990 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :ais523: assuming it's not a side effect opens the door for further optimizations. < 1762985294 836053 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I've been gradually trying to design an IR (not as a major project that's likely to finish any time soon, just as a curious spare-time thing) and realised that infinite loops are really hard to handle properly in an IR because they introduce what's effectively a side effect in a way that doesn't show up to most side-effect analyses < 1762985321 611052 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :the ferme example is nice < 1762985327 319528 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it'd make things much easier to say "if things calculated within an infinite loop don't affect the rest of the code, you can skip the loop" < 1762985331 104821 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and C++ actually does that < 1762985374 882709 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :yeah < 1762985378 558171 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :GHC Haskell prints out "" and exits if it ever finds a cycle in the part of the object graph that it is currently evaluating. The way it does this is very slick and not portable beyond GHC's VM, relying on Haskell's lazy semantics: lazy graph traversal can mark nodes when it first visits them, and prints "" when it visits a marked node. < 1762985470 523613 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: this was mentioned at one of the comments. i think at the followup article < 1762985485 246456 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is allowed by the Haskell specification, which specifies that an abnormal termination and an infinite loop are considered the same outcome and a compiler can transform one to the other < 1762985488 337521 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I don't really like non-termination. I would like for my computer to finish what it's doing, please. < 1762985559 979295 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :sure, except that there are cases (and specific examples in these articles, including at the linux kernel) about use cases where not terminating is a desirable behavior < 1762985581 597859 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :s/desirable/intended/ < 1762985631 335813 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there's another similar case which I find very annoying, in which a function call can contain a synchronisation barrier and expose data it clearly doesn't have access to < 1762985650 533832 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :one example is firmware updater which enters infinite loop and expects the cpu watchdog to reboot < 1762985675 331945 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :let me try to fidn it < 1762985701 909447 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :skim those articles. they have several examples < 1762985759 960202 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: So, in terms of understanding the Haskell/ML way of thinking, there's an important old paper by the author of the Miranda language, "Total Functional Programming": https://ncatlab.org/ufias2012/files/turner.pdf This paper says that in addition to programs that always halt, we can write programs on *codata* which is infinite, and *never* halts. < 1762985792 896407 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :For all of the cases where we want to have an interactive machine that is constantly responding to a user, we can use codata. Maybe you disagree with this, but it's the meme that dons and others are implicitly bringing to the table. < 1762985852 764714 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :That said, I think that an infinite-loop intrinsic would be a fine compromise for a kernel or embedded app. I agree that sometimes an embedded device needs to enter a stuck state, and an intrinsic seems like a reasonable way to offer that control to the programmer without contaminating the language with *general recursion*. < 1762985858 536098 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i didn't express my opinion yet on this :) but without considering it deeply, i think (and thought also before reading these articles) that termination is an observable side effect < 1762985891 85754 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :i did consider it while thinking about my bf optimization model < 1762985924 322571 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :In the case of systems that have locking, any locks might be released if a program terminates but it might be held in a infinite loop otherwise < 1762985947 654151 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :exactly < 1762986038 128136 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :korvo: agreed, but c doesn't have an explicit halt instruction. < 1762986063 488246 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :found it: https://github.com/llvm/llvm-project/issues/64188 < 1762986068 410132 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :avih: C lacks many of today's CPU's instructions. In general, it's really a language for a particular abstract machine rather than a language for the CPU. < 1762986085 978371 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :for(;;); is such, but it's something the compiler deduces. not something the developer can express explicitly < 1762986111 770804 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :avih: I don't know how I got here (as in on this channel, as opposed to this IRC network) either < 1762986123 335137 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this has been bothering me so much, it's making me think that acquire/release are the wrong abstractions for software (despite being correct for hardware) < 1762986136 310336 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I kind-of assumed you followed me, but wasn't sure < 1762986157 8011 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(For this reason, as well as the case of knowing that a capability is no longer usable, in my hypothetical computer design, halting can be distinguished from infinite loops without I/O, although in some cases a program might halt without intending to, such as waiting for a condition that the kernel knows is impossible (e.g. for any one of an empty set of objects to be ready).) < 1762986163 875682 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :b_jonas: to that article :) < 1762986303 86106 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :anyway, i'm out for now. just wanted to drop that link because i found it interesting, and related to the earlier conversation in some way, and to this channel. later :) < 1762986376 357439 :APic!apic@apic.name PRIVMSG #esolangs :cu < 1762986380 370320 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Peace. < 1762986400 15488 :APic!apic@apic.name PRIVMSG #esolangs :☮ < 1762986408 352841 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :. < 1762986423 548813 :avih!~quassel@23.94.231.119 PRIVMSG #esolangs :(really tiny peace symbol) < 1762986429 929847 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: Oh, that's interesting to think about. With E-style message delivery (so-called "E-order" of deliveries) there's always a possibility for deadlock simply because we can create a promise which resolves to itself. < 1762986480 464131 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In Vixen, I suppose that the analogue would be some sort of omega-shaped execline script that constantly tries to invoke and wait for a copy of itself. Not gonna write that out because it sounds like a fork bomb. < 1762986485 709478 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :
ACTION lunch &
< 1762986648 163278 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: the C++ rule that an infinite loop without side effects is undefined behavior bothers me. if I write a program that tries to find a counterexample for the Goldbach conjecture, and the C++ compiler is smart enough to prove that there's no such counterexample, then it can make the program do anything, such as lie that it found a specific counterexample, or spawn demons. and if I write the program < 1762986654 169761 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :such that it doesn't even print the counterexample, it only prints that it found one, then the compiler doesn't even have to prove that there's no counterexample, it can just make the program lie that it found a counterexample regardless. this gets worse if I write an interpreter in C++ for a toy language. the compiler can compile my interpreter such that it works most of the time but may UB for some < 1762986660 177326 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :infinite loops in the interpreted program. to avoid this I have to deliberately insert something that has a side effect (possibly in only some infinitely many iterations) to the loop body, < 1762986690 620271 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: this is basically what avih's link above was about < 1762986743 554593 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and I'm not even sure what I should insert that is considered a side effect by the C++ standard but that the compiler can optimize away. does calling time() count as a side effect? normally that won't evne issue an actual kernel system call, it's one of the system calls optimized by magic. how about select(0,0,0,0)? is the compiler allowed to know that it has no side effect and so not count it as an < 1762986749 571484 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :observable side effect? a volatile write counts as a side effect, but the compiler probably also isn't allowed to optimize away the write. < 1762986830 598546 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :if I want to definitely not terminate that's easy, I can just write while(1) { pause(); volatile int m = 0; m = 1; } < 1762986843 644744 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but that's a kind of trivial case < 1762986905 235806 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think this problem is actually unfixable from within C++ – ideally you would want a volatile read that gets optimized out, but I'm not even sure that concept makes sense < 1762986953 201681 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you could write a function call to a function whose behaviour isn't visible to the calling code, but that couldn't be optimized out and would be slower than a volatile read < 1762987005 195467 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"c doesn't have an explicit halt instruction" => it doesn't, but unix has pause(). it's a funny one because this is basically the *only* reasonable use for the pause() system call. < 1762987046 737128 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but even if you didn't have pause, which is probably a historical accident, you can use sigwait or select with a long timeout etc < 1762987255 315444 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yes, a volatile read might work < 1762987602 359981 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: if you had a program that ran entirely in signal handlers < 1762987617 707568 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you could make pause in a loop the body of main, after setting the signal handlers up < 1762987625 410470 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(this is probably a bad idea but it would at least be reasonable) < 1762987717 609066 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :volatile has some other advantages: if you have a slow pure computation and want to measure rough time of how slow then you can write the results of the computation into a volatile to make sure the computation is just optimized away. also even if it's not optimized away completely, a volatile write is at least cheap. < 1762987723 528209 :amby!~ambylastn@host-78-151-24-169.as13285.net QUIT :Ping timeout: 256 seconds < 1762987750 92286 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :eg. it's cheaper than trying to do a system calls to ensure a side effect or something like that < 1762987796 984121 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :not standard C++, but thinking about it an empty asm volatile would probably work < 1762987834 224473 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :also volatile writes in C and C++ are very portable < 1762987857 287662 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yes, that's technically dependent on the CPU type and compiler, but probably works decently < 1762987880 898133 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :most asms permit the null string as a no-op < 1762987910 538850 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, the compiler might not necessarily be able to pass it to the assembler correctly < 1762987927 753432 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, but I'm not convinced that the compiler will know the asm syntax on all CPU architectures < 1762987952 455528 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :like if you're compiling for an uncommon architecture or with an uncommon compiler or compiler options < 1762988005 443925 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and it's also harder to input a dependency into an inline asm portably so that it can't be reordered to before the value is computed < 1762988086 825055 :tromp!~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1762988146 233054 :amby!~ambylastn@host-81-178-156-253.as13285.net JOIN #esolangs * :realname < 1762988758 482195 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I did write a program once that used pause() because I wanted to wait for a signal to set a variable before the program does anything else < 1762989025 708506 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: doesn't that go wrong if the signal arrives before the pause() call? < 1762989077 12837 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you would need a ppause() instead to avoid the race condition (which exists, but for some reason is called sigsuspend() instead) < 1762989121 705582 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :A while loop is used, so if a different signal arrives then it will pause() again < 1762989351 908920 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: no, the other way round < 1762989369 855823 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if the signal you're waiting for arrives before the program enters the pause() call < 1762989369 986362 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1762989379 712353 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :then pause() wlll be waiting for something that has already happened < 1762989415 366699 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :O, that is a valid point, if it occurs between checking the loop condition and calling pause() < 1762989493 656154 :pool!~nathan@user/PoolloverNathan JOIN #esolangs PoolloverNathan :nathan < 1762989598 157957 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1762989817 194939 :sftp_!~sftp@79.174.43.63 JOIN #esolangs * :sftp < 1762989895 497662 :sftp!~sftp@user/sftp QUIT :Ping timeout: 264 seconds < 1762989896 67774 :sftp_!~sftp@79.174.43.63 NICK :sftp < 1762989896 802166 :sftp!~sftp@79.174.43.63 CHGHOST ~sftp :user/sftp