00:26:26 -!- tromp has quit (Remote host closed the connection).
00:29:56 <tswett[m]> You know what we need more of? Antiprogramming languages.
00:30:32 <tswett[m]> With many programming languages, the natural state is that nothing happens, and you have to write code that causes the desired things to happen.
00:31:17 <shachaf> i,i substractive program synthesis
00:31:34 <tswett[m]> I define an "antiprogramming language" as a language in which the natural state is that anything could happen, and the sole purpose of the code is to prevent undesired things from happening.
00:34:15 <tswett[m]> fungot, does all that make sense to you?
00:34:15 <fungot> tswett[m]: how soon before gambit has had one.
00:42:08 <zzo38> Well, with C programming (at least with gcc), if you do not write any program then the linker won't work because there is no "main" function to start from.
00:47:51 -!- imode has joined.
00:48:33 <shachaf> zzo38: Do you like the gcc linker?
00:48:39 <shachaf> Should I write my own linker?
00:50:05 <zzo38> Write your own linker if you need to, I suppose.
00:50:32 <zzo38> The gcc linker seems to work for me; I haven't done much other stuff with it than just compiling C programs though
00:52:41 <zzo38> Can you make a global variable of zero length to indicate something that the linker can use to decide something? If so, does the GNU linker support that use?
00:54:21 <shachaf> Making a symbol to indicate something is a standard trick, I think.
00:55:11 <zzo38> Yes, I have seen that, although I have not seen them being of zero length.
00:56:08 <shachaf> I see. I'm not sure how you'd do that in C, but I assume linkers support it fine.
00:56:10 <zzo38> (GNU C accepts zero length structures and zero length arrays; the latter is normally only used as the last item in a structure, although I can think of some other uses too, some of which have to do with macros.)
00:58:34 <shachaf> Indeed with GNU extensions you can write "int thing[0];" to make an zero-length symbol.
01:03:27 -!- moony has quit (Ping timeout: 240 seconds).
01:04:47 -!- moony has joined.
02:08:08 -!- adu has joined.
02:16:04 -!- tswett[m] has quit (Changing host).
02:16:04 -!- tswett[m] has joined.
02:16:04 -!- tswett[m] has quit (Changing host).
02:16:04 -!- tswett[m] has joined.
02:45:12 <Cale> tswett[m]: "First, please don't delete my home directory. Actually, if you could just not delete files for now, that would be a great start."
02:45:13 -!- craigo has quit (Ping timeout: 264 seconds).
03:14:02 -!- moony has quit (Ping timeout: 260 seconds).
03:14:33 -!- moony has joined.
03:44:26 -!- imode has quit (Ping timeout: 256 seconds).
04:02:14 -!- imode has joined.
04:19:02 -!- tromp has joined.
04:23:52 -!- tromp has quit (Ping timeout: 256 seconds).
04:36:38 <zzo38> Do you have some comments of the custom Magic: the Gathering set that I was making up?
05:26:34 -!- zseri has quit (Quit: zseri).
05:31:32 <Cale> I don't think I saw it, but my commentary would be fairly uninformed -- I only watch some M:tG players from time to time, haven't actually gotten into playing it myself.
05:31:57 <zzo38> O, OK.
05:32:03 <Cale> Link?
05:32:26 <zzo38> http://zzo38computer.org/mtg/zivstr/
05:32:51 <zzo38> There is a HTML export of the card set there; you can also download the TeXnicard file.
05:36:29 <zzo38> (Not all cards are custom; some are reprints. However, I intend to add more custom cards too. Also, the rarities and other stuff may be changed, too.)
05:36:36 <Cale> Kjugobe's Trick wow, haha
05:37:16 <Cale> High skill ceiling card
05:46:01 <zzo38> Yes, that card can be used for a few things
05:46:07 <Cale> What kinds of player counters are in the set?
05:46:53 <zzo38> So far, I don't think there are any counters on players in this set, but I may add some later. Also, it can be used together with another set, potentially.
05:47:25 <Cale> Ah, I was looking at Kjugobe's Pet
05:47:33 <zzo38> Yes, I was guessing that.
05:49:49 <Cale> I wonder if there's a way to make profitable use of the sacrifice mechanic on Goblins of the Flarg.
05:50:17 <zzo38> Yes, I thought of that too, maybe a card can be added to take advantage of that. (That card is a rather old card.)
05:54:22 <Cale> Against non-red opponents, it'll just be a 1/1 for 1, which would be outclassed by a lot of other 1-mana creatures these days, but it depends on what's legal to play of course.
05:55:06 <Cale> But yeah, if there was a sweet combo :D
05:55:42 <shachaf> Cale: Hale
05:55:53 <Cale> hellochaf
05:55:56 <shachaf> Have you played any of these "deck building roguelike" games that people are into nowadays?
05:56:18 <Cale> I've played Slay the Spire
05:56:28 <Cale> Though it was back when there were only two clases
05:56:30 <Cale> classes*
05:56:33 <shachaf> I played a lot of that.
05:56:59 <shachaf> The two newest classes are fun.
05:58:46 <zzo38> I have not heard of such "deck building roguelike" game, but now I did.
05:59:21 <Cale> I've played a lot of roguelike roguelike games, especially Caves of Qud
06:01:03 <Cale> I have a screenshot from StS here https://cale.l5.ca/share/Slay%20the%20Spire%20-%204496.png
06:01:36 <Cale> (I'm holding a hand representing 4496 damage)
06:02:08 <shachaf> Barricade + Entrench?
06:02:30 <Cale> I forget what else was in my deck
06:02:36 <Cale> Barricade sounds right
06:02:39 <shachaf> I mean, you had the block doubling card.
06:02:44 <shachaf> I can see barricade in the power list.
06:02:57 <Cale> ah, yeah
06:02:57 <shachaf> Too bad that still doesn't -- wait, you haven't gotten the game's final boss, I guess, because that was only added with the third character?
06:03:09 <Cale> Yeah, this was a final boss at the time
06:03:36 <shachaf> Yes. There's a top secret fourth act now.
06:09:03 -!- adu has quit (Quit: adu).
06:33:02 -!- zzo38 has quit (Ping timeout: 260 seconds).
06:33:51 -!- zzo38 has joined.
06:52:22 -!- imode has quit (Ping timeout: 246 seconds).
07:15:45 -!- tromp has joined.
07:40:27 -!- tromp_ has joined.
07:41:33 -!- ArthurStrong has joined.
07:43:47 -!- tromp has quit (Ping timeout: 240 seconds).
08:01:01 -!- TheLie has joined.
08:05:42 -!- b_jonas has quit (Quit: leaving).
08:09:17 -!- cpressey has joined.
08:27:44 -!- Phantom_Hoover has joined.
08:38:49 -!- tromp has joined.
08:41:51 -!- tromp_ has quit (Ping timeout: 246 seconds).
08:49:40 -!- TheLie has quit (Remote host closed the connection).
08:53:10 -!- S_Gautam has joined.
09:33:36 -!- Sgeo has quit (Read error: Connection reset by peer).
10:10:48 -!- rain1 has joined.
10:35:16 -!- atehwa has quit (Ping timeout: 256 seconds).
10:40:25 -!- atehwa has joined.
10:45:12 <int-e> shachaf: https://gist.github.com/int-e/8e606cd6e3eeb2d8b4296cbb21d6515f is the von Neumann neighborhood experiment I did last month, in case you're interested.
10:46:23 <shachaf> That's a lot of code.
10:46:26 <int-e> hmm, those links aren't right, should be anchors
10:48:08 <shachaf> What was the reason for using assembly and not intrinsics?
10:48:38 <int-e> shachaf: mainly one less level of indirection
10:49:01 <int-e> (I'd have to map the instructions to the intrinsics)
10:50:07 <shachaf> Hm.
10:50:24 <int-e> Also I had already written the x86-64 version, so I was already in manual register scheduling mode anyway.
10:51:34 <int-e> And yes, it's a lot of code... but it felt like a good level of complexity for a reality check (compilers vs. manually written assembly code)
10:52:23 <int-e> And honestly I was surprised to save almost 20%, I expected less.
10:53:33 <int-e> The version I actually used in the challenge was the generic one.
10:56:06 <int-e> Anyway I think the main thing that kills the SSE2 code is the awkwardness of doing 128 bit shifts.
11:00:49 <shachaf> What's the awkwardness?
11:00:56 <int-e> I guess AVX would enable higher throughput, but that interacts awkwardly with cycle-finding.
11:01:11 <shachaf> Oh, is it shifting between lanes or something?
11:02:13 -!- Lord_of_Life_ has joined.
11:02:33 <int-e> The awkwardness is that the full register moves, vpsrldq and so on, work in 8bit multiples. This compares infavorably to the x86_64 code which has shld and shrd...
11:02:49 -!- S_Gautam has quit (Quit: Connection closed for inactivity).
11:04:02 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
11:04:02 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
11:05:03 <shachaf> Oh, that's surprising.
11:05:05 <int-e> So basically >> 10 becomes *3* shift instructions and a bitwise or, instead of a shld and another shl. And the code is shifting a lot.
11:05:53 <int-e> uhm, "full register moves" was "full register shifts" in my brain
11:06:07 <int-e> (I guess moving is a kind of shifting?)
11:07:52 <shachaf> It's been a long time since I wrote SIMD code.
11:08:28 <int-e> Yeah this is a bad example for that anyway.
11:09:09 <int-e> I mainly did it because while I expected it to be slower than the x86_64 version, I wasn't entirely sure (and it is quite a close call anyway).
11:09:53 <shachaf> I guess a full register shift is a pretty unusual SIMD operation.
11:10:02 <int-e> (Obviously this is just my best effort... I may have missed some optimization opportunity.)
11:10:23 <int-e> Yeah, the "M" doesn't really apply here.
11:11:43 <int-e> The most satisfying idea here was the use of a sorting network.
11:13:04 <int-e> (The alternative would've been a combination of two half-adders (to combine pairs of inputs) and two full adders)
11:14:19 <shachaf> I like sorting networks.
11:14:33 <shachaf> Perhaps sorting networks are this.
11:16:22 <int-e> In any case, it was a fun experiment.
11:17:16 <int-e> And I managed to be cited twice in http://www.research.ibm.com/haifa/ponderthis/solutions/May2020.html :)
11:19:41 <int-e> shachaf: Anyway, I would expect the code to be the same speed or maybe a cycle slower with intrinsics.
11:20:06 <shachaf> Sure, I'm not suggesting it would make for faster code than writing assembly yourself.
11:20:38 <int-e> (the compiler's register allocation still kind of sucks... they get away with this because the CPUs make register-register moves mostly free)
11:20:57 <shachaf> POn
11:20:58 <shachaf> DER
11:21:07 -!- Phantom_Hoover has quit (Ping timeout: 260 seconds).
11:21:13 <int-e> shachaf: right
11:21:33 <shachaf> Are register allocators just doomed to be pretty good but not that good?
11:21:37 <int-e> (there's no good way of making a capital n at 3 pixel width)
11:22:03 <int-e> shachaf: Good question, I don't know, because compilers and CPUs are co-evolving.
11:22:04 <shachaf> If you're willing to give your optimizer more time, can it just solve the register allocation problem optimally, or is that intractable?
11:22:41 <shachaf> Of course there's also that.
11:23:17 <shachaf> I would be happy to give my compiler more time in super-optimized mode (and I want it to be much faster in regular mode).
11:24:12 <shachaf> Also, can you reuse these things between runs? For example a CDCL solver can probably remember its best learned clauses for the next run (and check whether whether they're still valid), maybe you can reuse that work in something like this?
11:24:28 <int-e> Which is actually an argument in favor of better register allocation in compilers... because we are increasingly focussing on energy efficiency and all that register renaming machinery isn't working for free.
11:24:28 <shachaf> Of course you could do regular incremental building too but maybe something deeper would be worthwhile, I don't know.
11:25:19 <int-e> reusing optimizations, sure, that's "just" a software engineering problem.
11:25:53 <shachaf> Well, I mean reusing learned clauses between *different* instances that are similar.
11:26:17 <shachaf> If you spend a lot of time running the optimizer on one function and then make a small change, maybe you can get an optimal solution quickly.
11:26:21 <int-e> There are superoptimizers, and I expect that reusing previous optimized code is pretty important there.
11:26:32 <shachaf> Though now that I write it out it seems a little implausible that it would work that well.
11:26:56 <int-e> But meh. I'm speculating instead of researching.
11:27:05 <shachaf> What are you researching?
11:27:43 <int-e> I mean this concrete question. Superoptimizers *exist*, surely people have written about them and how they're used as well.
11:28:20 <int-e> (Though somehow, the only context in which I've actually seen them is the Ethereum VM... :-/)
11:28:58 <int-e> I bet GPU vendors also have their own superoptimizers... which they run whenever a new game is released, distributing the results with a driver update.
11:29:45 -!- TheLie has joined.
11:30:21 <int-e> `? device
11:30:24 <HackEso> A device is a browser session. Please verify your device.
11:30:31 <int-e> Still ^ annoys me every single time.
11:30:47 <myname> huh?
11:30:51 -!- Phantom_Hoover has joined.
11:30:58 <int-e> myname: 'Subject: [GitHub] Please verify your device'
11:31:10 <int-e> No, it's the same PC every single time.
11:31:17 <myname> ah
11:31:48 <int-e> (Well, maybe a couple of them.)
11:36:27 <int-e> Ah I can't spell "comparator".
11:49:46 -!- cpressey has quit (Quit: Lunch.).
11:50:07 <shachaf> i,i Gentlemen, it's a nuclear [browser session].
11:59:09 <int-e> shachaf: That's all well and good, but have you verified it?
11:59:25 <int-e> We just can't let devices go unverified.
12:00:17 <shachaf> int-e: GPU drivers special-casing shaders of specific games compiled with superoptimizers? What a dismal perspective.
12:01:02 <int-e> shachaf: I think it's the reality.
12:01:21 <shachaf> Sounds plausible.
12:01:37 <int-e> (No proof. But what else would they do in those driver updates that speed up newly released games, and why else would those drivers be so ridiculously big?)
12:02:17 <int-e> And super-optimizers are just more plausible than *people* working on manually optimizing those shaders all day.
12:05:04 <int-e> Actually I can't even say that it's *bad*.
12:06:03 <int-e> nVidia or AMD spending a couple of days of server farm time for the benefit of all the players of a game sounds like a pretty good deal.
12:07:51 <int-e> So all I can potentially complain about is wasted bandwidth...
12:17:17 <int-e> What is a 0' (or O') oracle in computability theory?
12:18:38 <int-e> I tried Google and it gave me loads of 
12:18:54 <int-e> Ignore that.
12:19:19 <int-e> I tried Google but forgot my Google 101, namely adding the field of interest as a keyword.
12:19:50 <int-e> The answer is here: https://en.wikipedia.org/wiki/Turing_jump#Examples
12:22:05 <int-e> Without the field of interest it gave me loads of database related hits, I wonder why ;-)
12:23:50 <int-e> Duckduckgo tried to be smart and turned out to be useless. Query: 0' oracle computability --> Answer: Did you mean 0' oracle compatibility?  plus a lot of hits for that...
12:24:15 <int-e> (putting "computability" in quotes helped, but it didn't even suggest that!)
12:26:38 <shachaf> int-e: For the benefit of players of AAA games, anyway. I'd rather have nVidia and AMD give developers the tools to make their programs fast themselves.
12:34:14 -!- Phantom_Hoover has quit (Ping timeout: 240 seconds).
12:40:59 <int-e> Yeah there's that.
12:49:43 <int-e> It's kind of unavoidable... in the gamer market segment, framerates in AAA titles is the main competetive factor.
12:51:09 <int-e> So whether it's GPU vendors lending expertise to the game developers, or optimizing shaders post release... something like that is bound to happen. And they may consider their internal tools not polished enough or too trade-secreted to be shared more widely.
12:52:04 <shachaf> Well, Intel doesn't send you CPU driver updates that recompile the code for popular programs to be faster.
12:52:13 <shachaf> I mean, uh, I mean, I sure *hope* they don't do that.
12:52:35 <int-e> Who's Intel again. (From a GPU market perspective, I mean)
12:53:21 <shachaf> I mean for CPU programs, not GPU.
12:53:24 <int-e> And only half kidding anyway.
12:53:37 <int-e> Ah.
12:55:08 <int-e> Intel isn't in the right position for that I suppose. It would be funny if VMs (e.g. Javascript ones) would be doing that for commonly distributed scripts.
12:55:18 <int-e> (/programs)
12:55:56 <FireFly> Kind of surprised they aren't, tbh
12:56:00 <int-e> But one key difference here is that the machine code isn't a trade secret.
12:56:02 -!- sprocklem has quit (Ping timeout: 256 seconds).
12:56:14 <FireFly> (well, browsers, and targetting key popular libraries)
12:56:27 <int-e> FireFly: same here, actually
12:57:16 <int-e> And who knows, maybe it's done and I just don't know.
12:57:23 * FireFly nods
12:57:33 -!- sprocklem has joined.
12:57:38 <shachaf> Well, it would be nice if GPU machine code wasn't a trade secret.
12:57:49 <int-e> OTOH maybe there are just too many versions of each Javascript library for this to be attractive.
13:04:06 -!- ArthurStrong has quit (Ping timeout: 272 seconds).
13:34:27 <esowiki> [[Thue]]  https://esolangs.org/w/index.php?diff=73188&oldid=73110 * Yoel * (+0) /* External resources */
13:40:56 -!- wib_jonas has joined.
14:03:19 -!- cpressey has joined.
14:05:53 -!- tromp has quit (Remote host closed the connection).
14:24:34 -!- S_Gautam has joined.
14:45:29 <esowiki> [[BF-ASM:8]] M https://esolangs.org/w/index.php?diff=73189&oldid=73186 * DmilkaSTD * (-36) I dont think this is a brainfuck derivative
14:49:51 -!- tromp has joined.
15:03:50 <esowiki> [[BF-ASM:8]]  https://esolangs.org/w/index.php?diff=73190&oldid=73189 * DmilkaSTD * (+534) 
15:05:46 -!- TheLie has quit (Remote host closed the connection).
15:07:55 <cpressey> I noticed the "2020" category looked empty so I refreshed it.  There are already 149 pages in it.  There were 200 in all of 2019.
15:09:46 <esowiki> [[BF-ASM:8]] M https://esolangs.org/w/index.php?diff=73191&oldid=73190 * DmilkaSTD * (+40) Comments in the code
15:11:17 <esowiki> [[BF-ASM:8]] M https://esolangs.org/w/index.php?diff=73192&oldid=73191 * DmilkaSTD * (+1) invisible change
15:15:23 <esowiki> [[User:DmilkaSTD]]  https://esolangs.org/w/index.php?diff=73193&oldid=73120 * DmilkaSTD * (+18) 
15:18:04 <esowiki> [[BF-ASM:8]]  https://esolangs.org/w/index.php?diff=73194&oldid=73192 * DmilkaSTD * (+204) 
15:26:07 <esowiki> [[BF-ASM:8]] M https://esolangs.org/w/index.php?diff=73195&oldid=73194 * DmilkaSTD * (+113) uhm, useful.
15:27:27 <esowiki> [[Asvi]]  https://esolangs.org/w/index.php?diff=73196&oldid=72239 * DmilkaSTD * (+114) 
15:27:55 <wib_jonas> cpressey: https://esolangs.org/wiki/Special:Log?type=create shows page creations, in case you want to know who created the most pages
15:29:03 <cpressey> What's our stance on languages that claim to be Turing-complete (i.e. they've been put in the "Turing complete" category, they have "Computational class: Turing complete" in their infobox) without even including a proof sketch?
15:29:23 <cpressey> I mean, it's not obvious to me that https://esolangs.org/wiki/(1)_Grace_sent_you_a_message is TC
15:29:28 <cpressey> It's plausible, but not obvious
15:30:23 <wib_jonas> cpressey: sometimes the Turing-completness is obvious. if it's not obvious and the page says nothing about it, not even a reference to some external doc, then I think we can remove the category and modify the text.
15:33:20 <wib_jonas> cpressey: https://esolangs.org/wiki/(1)_Grace_sent_you_a_message is turing-complete because you can translate 1.1 to it by doing one replacement step of the 1.1 program in a brainfuck program, set the resource limit such that that brainfuck program never overflows, and just make the two brainfuck programs in the Grace program identical
15:33:49 <wib_jonas> The problem is that it might be uncomputable
15:34:19 <wib_jonas> I'm not sure if it is
15:35:25 <wib_jonas> Heck, it's definitely more than TC. It computes recursively enumerable languages I think.
15:36:03 <wib_jonas> We should probably categorize it [[Category:Nondeterministic]] [[Category:Uncomputable]]
15:37:05 <wib_jonas> And my draft proof above is wrong, because Grace is defined such that the iteration of the brainfuck programs leads to an output that must match the input
15:40:55 <esowiki> [[Talk:(1) Grace sent you a message]]  https://esolangs.org/w/index.php?diff=73197&oldid=72830 * Chris Pressey * (+307) 
15:44:40 <cpressey> I can see how it could be TC if you use one of the LBA's to compute a single step of a TM and then iterate -- in fact I don't see why you'd need two LBAs, just iterating one should work.
15:48:41 <wib_jonas> cpressey: you need two TMs because the iterated process has to generate all possible inputs of Grace, so it has to be nondeterministic in some way
15:49:21 -!- tromp has quit (Remote host closed the connection).
15:49:36 <wib_jonas> cpressey: the run of a Grace program always starts from an empty state, then modifies it iteratively by nondet transforming it to some possible output
15:50:00 <wib_jonas> then the program becomes accepting if the state can reach the input of the Grace program
15:50:43 <wib_jonas> this sadly makes IO for Grace ugly, because it can't support just any input format, you need to put some marker to distinguish inputs from strings you use as intermediate states
15:51:31 <wib_jonas> but if you use an input convention where, say, all inputs to Grace must start with a 1, and the intermediate states start with a 0, then you can compute any recursively enumerable set with a Grace program 
15:51:35 <cpressey> tbh I don't see how you get any of that from the article
15:52:04 <wib_jonas> which part?
15:53:32 <wib_jonas> the paragraph above the last one tells how the program transforms a string, starting from the empty string, with brainfuck black boxes, by feeding the string as an input to bf and replacing it with the output
15:54:07 <esowiki> [[User:PythonshellDebugwindow/GUI Display Language]] M https://esolangs.org/w/index.php?diff=73198&oldid=73165 * PythonshellDebugwindow * (+89) 
15:54:26 <cpressey> "the iterated process has to generate all possible inputs of Grace, so it has to be nondeterministic" -- no it doesn't?
15:54:28 <wib_jonas> then the last paragraph describes the IO convention of Grace, that is, that the Grace input must match the last state, and that this is nondeterministic in the sense that the Grace machine accepts an input string if there's any accepting path to it
15:54:39 <cpressey> You can deterministically generate all possible inputs?
15:54:56 <wib_jonas> cpressey: hmm ok, that's true, you could do that too
15:55:10 <wib_jonas> because there's no special mark for which state is final
15:55:41 <cpressey> anyway if Hakerh400 is as bored as their user log makes them look hopefully they'll be happy to explain why they claim it's TC
15:57:35 <wib_jonas> cpressey: still, for Turing-completeness, all you'd need is to pick one fixed non-empty string as a conventional input, and then compile your program to brainfuck iterations such that it outputs that special string if your program halts
15:57:56 <wib_jonas> then the Grace program will accept the special string iff your original program halts
15:58:18 <wib_jonas> and yes, for that much, one brainfuck program is enough
15:58:27 <wib_jonas> the second brainfuck program just makes it more powerful than TC
15:59:00 <wib_jonas> though not more powerful for any one fixed input, admittedly
16:00:44 -!- cpressey has quit (Quit: WeeChat 1.9.1).
16:01:47 <esowiki> [[User:PythonshellDebugwindow/GUI Display Language]] M https://esolangs.org/w/index.php?diff=73199&oldid=73198 * PythonshellDebugwindow * (+80) /* ArrayLib.guidl */
16:09:58 -!- wib_jonas has quit (Quit: Connection closed).
16:23:00 -!- tromp has joined.
16:24:49 <esowiki> [[User:PythonshellDebugwindow/GUI Display Language]] M https://esolangs.org/w/index.php?diff=73200&oldid=73199 * PythonshellDebugwindow * (+225) /* Standard libraries */
16:25:53 <esowiki> [[User:PythonshellDebugwindow/GUI Display Language]] M https://esolangs.org/w/index.php?diff=73201&oldid=73200 * PythonshellDebugwindow * (+45) /* Other */
16:30:06 -!- Sgeo has joined.
16:30:33 <esowiki> [[Special:Log/newusers]] create  * Shaman *  New user account
16:30:50 <esowiki> [[User:PythonshellDebugwindow/GUI Display Language]] M https://esolangs.org/w/index.php?diff=73202&oldid=73201 * PythonshellDebugwindow * (+201) /* ArrayLib.guidl */
16:34:12 -!- S_Gautam has quit (Quit: Connection closed for inactivity).
16:39:23 <esowiki> [[Esolang:Introduce yourself]]  https://esolangs.org/w/index.php?diff=73203&oldid=73171 * Shaman * (+262) 
16:48:59 -!- HQ has joined.
16:59:40 -!- zseri has joined.
17:12:26 -!- b_jonas has joined.
17:31:57 -!- tromp has quit (Remote host closed the connection).
17:34:22 -!- imode has joined.
17:38:34 -!- HQ has quit (Quit: I probably fell asleep again).
17:47:55 -!- tromp has joined.
18:11:18 -!- TheLie has joined.
18:13:12 <esowiki> [[Brainfuck implementations]] M https://esolangs.org/w/index.php?diff=73204&oldid=73172 * PythonshellDebugwindow * (+29) /* Implementations including Hardware */ cat
18:27:59 <esowiki> [[User:PythonshellDebugwindow/GUI Display Language]]  https://esolangs.org/w/index.php?diff=73205&oldid=73202 * PythonshellDebugwindow * (+603) /* Brainfuck interpreter */
18:40:42 -!- TheLie has quit (Ping timeout: 246 seconds).
18:48:13 -!- ais523 has joined.
18:48:25 <ais523> b_jonas: Grace is definitely computable, it allows the 0 case to enter an infinite loop
18:48:40 <ais523> thus it can be computed simply by running all possible computations interleaved and seeing if any of them output 1
18:49:12 <b_jonas> ais523: hmm...
18:49:34 <b_jonas> so it's exactly turing-complete?
18:49:44 <b_jonas> I guess you're right
18:50:11 <ais523> for a TCness proof, I think it's sufficient for one program simply to create longer and longer internal states, and the other program to do all the real work
18:50:42 <b_jonas> ais523: that would work too, yes
18:50:58 <esowiki> [[Special:Log/newusers]] create  * WiseMan *  New user account
18:51:47 <ais523> I think a much more interesting question is whether deterministic Grace is TC, I'm not convinced that it isn't
18:52:04 <b_jonas> though in a string replacement language like 1.1 or Thue, any one rule will increase the string length only by a constant term, so you can directly represent such a rule in Grace
18:52:15 <ais523> (i.e. with only one program rather than two)
18:52:23 <ais523> it clearly would be if not for the linear boundedness
18:52:46 <b_jonas> ais523: yes, it's still TC if you want a fixed Grace input, say always give "1" as the input. 
18:52:57 <b_jonas> ais523: you can translate 1.1 into it, or a deterministic version of Thue 
18:53:09 <b_jonas> where the brainfuck program always executes the first rule that matches
18:53:13 <esowiki> [[Surtic]] M https://esolangs.org/w/index.php?diff=73206&oldid=72919 * Digital Hunter * (-35) 
18:53:15 <ais523> ah right, yes, or any language which works by transforming an internal state one step at a time
18:53:25 <b_jonas> 1.1 is a bit more complicated because you also need to store the finite control state in the string
18:53:28 <ais523> where each individual step grows the string only finitely
18:53:44 <ais523> actually my first thought for this was MiniMAX
18:54:02 <ais523> but that's awkward because you need a weird representation of the instruction pointer and old instruction pointer
18:54:42 <b_jonas> ais523: would a version of Thue that always does the first replacement rule that applies work?
18:54:47 <ais523> hmm, that made me think of an entirely different problem: what's the minimum number of word-pairs needed for the Post Correspondence Problem to be TC?
18:55:02 <ais523> b_jonas: yes
18:55:12 <b_jonas> is there a name for that deterministic Thue or something close?
18:55:23 <b_jonas> perhaps even an article on esolangs.org?
18:55:27 <imode> y'all talkin about thue.
18:55:39 <b_jonas> it's not 1.1, because 1.1 has a finite control state, so it's actually much harder to translate
18:55:48 <ais523> deterministic Thues have been talked about quite a bit, but there are two different ways to determinize Thue
18:55:56 <ais523> one is to always take the first rule, one is to always take the first position in the program
18:55:59 <imode> one is prioritization of rules and...
18:56:01 <imode> yeah.
18:56:02 <b_jonas> ais523: yeah
18:56:12 <b_jonas> in this case either one would work
18:56:15 <ais523> come to think of it, 2C would work great for this
18:56:18 <b_jonas> because you can translate either one to brainfuck
18:56:30 <ais523> as one step of 2C is a finite state machine
18:56:47 <imode> I've been working on a "brainfuck" to Thue translator since yesterday, funny this comes up now.
18:57:20 <ais523> how many tape cells do you need to convert arbitrary finite state machines to BF? my guess is 2, possibly 1 is enough
18:57:47 <ais523> (IIRC, 3 is enough to be TC if you have bignum cells, but obviously an FSM doesn't need bignums)
18:58:11 <imode> 1 would be enough, wouldn't it?
18:58:24 <imode> or would you need 2, one for state and one for input.
18:58:44 <ais523> oh, I didn't even think of putting the state in a cell
18:59:01 <ais523> I was thinking you use the IP to record the state, in which the hard part is whether or not you can escape from brackets without forgetting what you're doing
18:59:20 <ais523> you probably need 2 cells simply because you can't escape a loop unless the current cell is 0
18:59:33 <ais523> meaning that in 1-cell brainfuck, you can't remember anything across a ]
18:59:53 <imode> yeah.
19:00:03 <b_jonas> ais523: there's also one-tape thue, in which the input, every string state, every search string, and every replacement string must contain exactly one "1"
19:00:09 <b_jonas> which works like a two-stack machine
19:00:12 <ais523> a conditional-goto version of BF would only need one cell to implement an FSM, and it only needs that cell to be able to read the input
19:00:28 <b_jonas> and you can check that it's locally deterministic
19:00:53 <ais523> hmm, this implies that structured programming can actually make languages less powerful sometimes
19:00:55 <b_jonas> cpressey: ^
19:01:26 <imode> yeah, that's kind of why I got off of it.
19:01:28 <b_jonas> basically you can translate a two-stack finite control machine to a Thue program that is intrinsically determinisitic, that's what I wanted to say
19:01:31 <imode> it's too restrictive.
19:02:40 <b_jonas> ais523: https://esolangs.org/logs/2020-06-01.html#lZb
19:03:58 <b_jonas> also, do prolog variants really use different atoms as the head of a non-empty list?
19:05:13 <b_jonas> yes they do. SWI prolog uses '[|]' as the head, gnu prolog uses '.' as the head
19:06:39 <b_jonas> This is like one of those weird BSD vs Sysv differences, isn't it?
19:08:41 <b_jonas> they also represent the empty list differently
19:12:38 <b_jonas> apparently in gnu prolog, the atom '[]' is the empty list, and '.'(Car,Cdr) is a non-empty list; in swi prolog, '[|]'(Car,Cdr) is a non-empty list, and the empty list isn't even an atom (wtf)
19:13:22 <esowiki> [[Jumper]] M https://esolangs.org/w/index.php?diff=73207&oldid=65648 * PythonshellDebugwindow * (-4) /* RAM */
19:16:09 <ais523> I think traditionally in Prolog, '.' is the name of the cons operator
19:16:20 <b_jonas> ais523: that's what I thought too
19:16:36 <ais523> I guess it's a good name because it's one of the few things that never parses as an operator naturally
19:16:44 <ais523> so it's unlikely to clash with a user-defined operator
19:17:01 <b_jonas> yes, nor does it parse as an atom
19:17:17 <ais523> `` swipl -qg 'display(/(A,B)).'
19:17:19 <HackEso> ​/(_380,_382)
19:17:24 <ais523> `` swipl -qg 'display(A/B).'
19:17:25 <HackEso> ​/(_380,_382)
19:17:30 <ais523> ah, OK
19:17:42 <ais523> for a moment I though it was making a distinction and got very confused
19:17:54 <ais523> GNU prolog uses infix notation when displaying operators, I think
19:17:54 <b_jonas> the parser makes a distinction
19:18:04 <b_jonas> ``` swipl -qg 'true(A,B)'
19:18:06 <HackEso> ERROR: -g true(A,B): catch/3: Undefined procedure: true/2 \ ERROR:   However, there are definitions for: \ ERROR:         true/0
19:18:12 <b_jonas> ``` swipl -qg 'L=true(A,B)'
19:18:13 <HackEso> No output.
19:18:28 <b_jonas> ``` swipl -qg 'L=true(A,B).'
19:18:29 <HackEso> No output.
19:18:34 <b_jonas> ``` swipl -qg 'L=true(A,B), display(L).'
19:18:34 <ais523> that's not a distinction between infix and prefix
19:18:35 <HackEso> true(_380,_382)
19:18:41 <b_jonas> ``` swipl -qg '(A true B), display(L).'
19:18:42 <HackEso> ERROR: -g (A true B), display(L).: Syntax error: Operator expected \ ERROR: (A \ ERROR: ** here ** \ ERROR:  true B), display(L).
19:18:50 <ais523> "true" isn't an operator
19:18:54 <b_jonas> yeah
19:19:07 <ais523> I think you can make things into operators in Prolog but forget how
19:19:22 <ais523> ``` swipl -qg 'display(!(A,B)).'
19:19:23 <HackEso> ​!(_380,_382)
19:19:30 <ais523> oh wow, I'm kind-of surprised that worked
19:19:38 <ais523> ``` swipl -qg '!(x,y).'
19:19:39 <HackEso> ERROR: -g !(x,y).: catch/3: Undefined procedure: !/2 \ ERROR:   However, there are definitions for: \ ERROR:         !/0
19:19:48 <ais523> looks like you can call a predicate ! if you want to
19:19:54 <ais523> presumably only if it has argumetns
19:20:31 <ais523> or maybe ! is implemented as a predicate that looks back along the call stack somehow?
19:20:48 <b_jonas> I think you could, but the above output doesn't really prove that
19:20:54 <ais523> most Prologs have a cut equivalent of setjmp/longjmp, but doing it without the setjmp is impressive
19:21:12 <ais523> I know the above output doesn't prove it, but it does make it more likely
19:24:07 <b_jonas> anyway, prolog doesn't have vararg predicates, so when it tries to execute a !, it can look up the atom together with its arity, and then find a very special magic builtin 
19:24:28 <b_jonas> similarly for 2-arity ;
19:24:49 <ais523> you could use assert in a loop to emulate a varag predicate, but you'd have to stop generating at some maximum number
19:24:54 <b_jonas> it might even represent !/0 and !/2 with different words in the head internally
19:25:05 <ais523> also ; doesn't have to be magical, you can implement it in standard Prolog
19:25:13 <ais523> it's , that's magical
19:25:27 <b_jonas> ; is sort of magical because of how it behaves on the right side of a ->
19:25:40 <ais523> I thought that was just operator precedenc
19:25:43 <ais523> *precedence
19:25:45 <b_jonas> no
19:26:20 <b_jonas> ``` swipl -qg '(true->R=0;R=1), R.'
19:26:20 <HackEso> ERROR: -g (true->R=0;R=1), R.: '<meta-call>'/1: Type error: `callable' expected, found `0' (an integer)
19:26:27 <b_jonas> ``` swipl -qg '(true->R=0;R=1), display(R).'
19:26:29 <HackEso> 0
19:26:38 <b_jonas> ``` swipl -qg '(true->R=0;R=1)=..L, display(L).'
19:26:39 <HackEso> ​[;,->(true,=(_380,0)),=(_380,1)]
19:26:44 <b_jonas> hmm maybe it is
19:27:05 <b_jonas> ok sorry, I'm wrong
19:27:10 <b_jonas> maybe it's -> that's magical then?
19:27:16 <b_jonas> one of them has to be magical
19:27:44 <ais523> ``` swipl -gq 'assertz((or(X,Y) :- X)), assertz((or(X,Y) :- Y)), (true->or(R=0,R=1)), display(R).'
19:27:45 <HackEso> 0
19:27:58 <ais523> ``` swipl -gq 'assertz((or(X,Y) :- X)), assertz((or(X,Y) :- Y)), (true->or(R=0,R=1)), display(R), fail.'
19:27:59 <HackEso> 01
19:28:06 <ais523> ``` swipl -gq 'assertz((or(X,Y) :- X)), assertz((or(X,Y) :- Y)), (true->R=0;R=1), display(R), fail.'
19:28:08 <HackEso> 0
19:28:12 <ais523> OK, ; is magical
19:28:24 <ais523> or, wait, no
19:28:29 <ais523> ``` swipl -gq 'assertz((or(X,Y) :- X)), assertz((or(X,Y) :- Y)), (true->(R=0;R=1)), display(R), fail.'
19:28:30 <HackEso> 01
19:28:37 <ais523> yes, nonmagical, it's just operator precedence
19:29:00 <b_jonas> hmm wait, let me test this
19:29:06 <ais523> actually I'm not sure , is magical, I just can't see a way to define it except in terms of itself
19:29:32 <ais523> ``` swipl -gq 'assertz((or(X,Y) :- X)), assertz((or(X,Y) :- Y)), or((true->R=0),R=1), display(R), fail.'
19:29:33 <HackEso> 01
19:29:41 <b_jonas> ``` swipl -gq 'assertz((or(X,Y) :- X)), assertz((or(X,Y) :- Y)), ((true->R=0);R=1), display(R), fail.'
19:29:42 <HackEso> 0
19:29:49 <b_jonas> ``` swipl -gq 'assertz((or(X,Y) :- X)), assertz((or(X,Y) :- Y)), or((true->R=0),R=1), display(R), fail.'
19:29:50 <HackEso> 01
19:29:52 <b_jonas> ^
19:29:59 <ais523> yes, we both thought of that test at once
19:30:00 <b_jonas> yeah, you tested the same thing
19:30:06 <ais523> that does look somewhat magical
19:30:34 <b_jonas> I guess it might still not be magical, if say (A;B) just checks whether the head of A is ->
19:30:44 <b_jonas> a normal predicate could do that
19:30:48 <ais523> I tend not to use -> anyway because it makes my head hurt, this shows why
19:31:08 <b_jonas> you know you can translate -> to ! right?
19:31:19 <ais523> I'd find that much clearer
19:31:41 <ais523> although doesn't the translation need an auxiliary predicate sometimes to control the scope of !?
19:31:50 <b_jonas> yes, it needs an auxiliary predicate
19:35:09 <ais523> I wonder why Lisp is as popular as it is, given the existence of Prolog
19:35:16 <ais523> I would have thought Prolog was just a strictly better Lisp
19:35:24 <ais523> that said, neither language is all that popular
19:38:27 <b_jonas> ais523: well the good news is, olvashato compiles conditionals or pattern matching to -> in general, but the current version optimizes them to ! when they're at the top level of a predicate
19:38:38 <int-e> Meh, Prolog has an awful execution model.
19:39:00 <ais523> you don't actually have to make use of the backtracking
19:39:03 <b_jonas> so it will make your head hurt less, and that was specifically the goal, though not for your head in particular, but for the head of the professor that read the homework prolog program generated with it
19:39:24 <b_jonas> however, I think the version that I used to submit the homework didn't have that optimization yet
19:39:41 <int-e> ais523: but backtracking is the default, you have to actively fight it if you don't want it
19:39:47 <b_jonas> or maybe it did have it, it just didn't have the similar optimization for the sml output? I dunno
19:39:52 <ais523> int-e: only if you use nondeterministic predicates
19:40:16 <int-e> and the syntax isn't all that great either.
19:40:18 <ais523> if all your predicates are deteriministic the evaluation order is the same as Lisp
19:40:18 * int-e shrugs
19:40:45 <int-e> I don't like Prolog. Lisp at least has meta-programming going for it.
19:41:13 <ais523> the point is that Prolog can be meta-programmed in exactly the same way
19:41:21 <b_jonas> ais523: no, prolog is not a strictly better list, because if you write a function composition expression like (a (b c)) in lisp, where a and b are functions, then in List you have to make up a variable name for the temporary, like (b(C, O), a(O, ...)) where O is the temporary variable that never appears in lisp
19:41:38 <ais523> b_jonas: oh yes, that's a good point
19:41:49 <b_jonas> ais523: also lisp has convenient first class functions, mutable bindings, mutable vectors, and some more convenient builtins
19:42:05 <int-e> (Lisp's main problem is one of attitude. The so called "common" lisp is huge, complex, badly documented unless you already know Lisp, and completely ignores the fact  that there's a plethora of languages outside of Lisp that you might want to bind to.)
19:42:17 <ais523> at one point I was considering a Prolog variant where predicates had a "return value", so writing A=f(B,C) in the variant would be equivalent to f(B,C,A) in actual Prolog
19:42:21 <esowiki> [[Jumplang]] N https://esolangs.org/w/index.php?oldid=73208 * PythonshellDebugwindow * (+893) Created page with "'''Jumplang''' is a [[brainfuck]]-derived esolang by [[User:PythonshellDebugwindow]] designed to be easier to implement in another esolang than normal brainfuck.  ==Difference..."
19:42:22 <b_jonas> ais523: mutable stuff is specifically hard to translate to prolog, whereas lisps have builtins for it (though they may differ between common lisp and scheme)
19:42:38 <b_jonas> ais523: that prolog variant exists, I think it's called Mozart or something
19:42:57 <int-e> But Lisp at least seemed worth using to me at some point until I ran into those problems. Prolog... never appealed to me except as a declarative-ish programming curiosity for simple backtracking solvers.
19:43:21 -!- tromp has quit (Remote host closed the connection).
19:44:18 <ais523> actually, I think I realised what I prefer about deterministic Prolog compared to Lisp: the quoting mechanisms are so much nicer
19:44:45 <ais523> that's probably a consequence of return values not existing, though
19:44:45 <b_jonas> ais523: apparently it's called Oz language and the implementation is called Mozart, just to confuse people
19:45:08 <ais523> hmm, maybe Prolog could do with some sort of scoped assert
19:45:15 <b_jonas> ais523: but the point is, you don't need quoting mechanisms if you program lisp like a sane procedural language
19:45:25 <ais523> Prolog does mutability just fine, its issue is that it's all global
19:45:40 <ais523> b_jonas: yes you do, e.g. when setting a variable
19:46:05 <ais523> if you do (set a b) then Lisp will attempt to evaluate both a and b, in order to generate the name of the variable it's setting and the value it's setting it to separately
19:46:07 <b_jonas> ais523: not for scheme, no. you might need it in lesser lisp variants, but those have other drawbacks too
19:46:20 <b_jonas> ais523: no, that's common lisp weirdness, we don't do that in scheme at all
19:46:46 <ais523> b_jonas: well in Common Lisp you normally use a macro setq that's just set with the first argument quoted
19:46:49 <b_jonas> you don't want to be able to access just any local variable by name, would you?
19:46:54 -!- tromp has joined.
19:47:05 <b_jonas> that just makes optimization much harder than it should be
19:47:09 <b_jonas> scheme doesn't have that feature
19:47:21 <b_jonas> you can still access *global* variables by name, and mutate them too, if you want
19:47:27 <b_jonas> like in perl or python
19:47:29 <b_jonas> but not locals
19:47:40 <b_jonas> so the normal way to set a variable is (set! variablename value) 
19:47:59 <ais523> ah, I always assumed that was analogous to setq, but maybe not?
19:48:02 <b_jonas> and that's the only builtin that can mutate a variable, though there are some other builtin macros
19:48:17 <b_jonas> ais523: it's analogous to setq, but there's no set that can modify a local variable by name
19:48:24 <ais523> it's magical because the name is being interpreted differently depending on the scope in which set! appears
19:48:45 <ais523> whereas setq is literally just adding an apostrophe
19:48:58 <b_jonas> ais523: you could say that, it's one of the few built-in expression types, but you can define a macro that does exactly that, 
19:50:17 <ais523> fwiw, many Lisp programmers prefer to use recursion rather than mutable variables; I wonder if that's related to issues of identifier scoping?
19:50:31 <ais523> although maybe not, when I program OCaml I often choose to use recursion rather than mutable variables
19:50:38 <b_jonas> define is way more magical (it's still implemented as a macro, but it's implemented like -> can be implemented in prolog, where lambda looks in its body to find defines)
19:51:06 <ais523> (variables in OCaml are like variables in Algol; the variable /itself/ is immutable once assigned, but the variable's /contents/ can be mutable)
19:51:31 <ais523> it's like writing int *const x = malloc(sizeof(int)) in C
19:51:34 <b_jonas> ais523: do they really? there are very convenient macros to encapsulate that kind of recursion with immutable variables changing from one iteration to another, and I think lisp programmers would mostly use those, just like Haskell programmers
19:52:02 <ais523> b_jonas: I mean, instead of writing a loop that repeatedly mutates some variables
19:52:25 <b_jonas> ais523: well yes then. but I think Haskell and SML programmers do that too.
19:52:36 <ais523> you write a function that's the loop body, give those variables as arguments, and have it "mutate" the variables from one loop iteration to the next by calling itself with differnet arguments
19:52:41 <b_jonas> lisp just makes the mutating version easier than in SML and much easier than in Haskell
19:52:59 <b_jonas> heck, while we're there, you do that in prolog too, don't you?
19:53:01 <ais523> the mutating version is pretty easy in OCaml given the sugar that exists
19:53:12 <ais523> b_jonas: I do it in anything that's remotely functional, I may be unusual though
19:53:22 <b_jonas> yes, it's pretty easy in scheme too because of macros that sugar it
19:53:36 <ais523> `` ocaml --help
19:53:37 <HackEso> ​/hackenv/bin/`: line 5: ocaml: command not found
19:53:41 <ais523> aww
19:53:57 <ais523> although it'd be quite complex to hook up to HackEso as it is
19:54:02 <ais523> it's not a very commandliney language
19:54:20 <b_jonas> we don't have gnu prolog either
19:54:33 <b_jonas> ``` ghc --version
19:54:34 <HackEso> bash: ghc: command not found
19:54:39 <b_jonas> ``` ghci --version
19:54:40 <HackEso> bash: ghci: command not found
19:54:53 <b_jonas> we can't have everything in HackEso
19:54:57 -!- craigo has joined.
19:55:06 <b_jonas> it already does a lot
19:57:47 <ais523> so this is what an imperative loop looks like in OCaml: https://tio.run/##HYtLDsIwDAX3OcVjx2cBLQskUHuVCBGHWnJt1EZqbx/cLt@8Gfu8R6lVqGBFh4ky2gdYwzKwEA4rejRIFuD/swPnjY2W0Lp@QxlIN3L1TTLvxRl3XNC8vPlNrCWSJmGl41x8fqPl6NTNU0imVOsf
19:58:28 <ais523> I like how clear the use/mention distinction is in OCaml, it distinguishes very clearly between a variable and its value
19:58:41 <b_jonas> ais523: ok, then that does seem to be stronger syntactic sugar than what scheme has
19:58:57 <b_jonas> oh wait, it has a reference
19:59:02 <b_jonas> then that is a mutating loop
19:59:09 <ais523> yes, that's a mutating loop
19:59:14 <ais523> not sugar for a recursive loop
19:59:14 <b_jonas> you can do that in scheme or SML then
19:59:21 <shachaf> I like the ALGOL 68/BLISS style but I'm not sure whether it's too complicated in practice.
20:00:04 <b_jonas> SML has mutable cells, the same kind that OCaml has; scheme doesn't directly have them, but you can implement them easily as library functions based on either mutable bindings, or on mutable conses, or on mutable vectors.
20:00:06 <shachaf> Especially if you have a whole bunch of !s in one line, for a bunch of mutable variable dereference and array indexing and so on.
20:00:33 <b_jonas> but for a simple loop like that, you wouldn't do that
20:00:44 <b_jonas> ais523: how does the sugar for a recursive loop like that work in OCaml?
20:00:46 <shachaf> Probably you can implement mutable cells in Scheme in terms of continuations if you want to be all schemey about it.
20:01:05 <b_jonas> shachaf: eek
20:01:33 <b_jonas> oh right, I needn't ask that, that's what Rosetta Code is forr
20:01:49 <ais523> b_jonas: here's the recursive version: https://tio.run/##HYtLDsIwDAX3OcVjx2cBLQskUHuVCBGHWnJt1EZqbx/cLt@8Gfu8R6lVqGBFh4ky2gdYwzKwEA4rejRIFuD/swPnjY2W0Lp@QxlIN3L1TTLvxRl3XNC8vPlNrCWSJmGl41x8fqPl6NTNU0imVOsf
20:02:26 <shachaf> Another thing is that if you convert something from an immutable to a mutable variable, you need to change x to !x everywhere in your code.
20:02:32 <ais523> or an alternative version: https://tio.run/##RYsxDsIwEAR7v2LLBISAUFAg@IqFnDOc5JxRYiQX/N1sCsQ1u7Oay@E@pdaSFMwSEHBFfFsoms19cMTuhq5nq2tbrUpDI2PKIwbCAeUpxmFPlLQI6wYnbPmt5vC716xWvNiY1KRbCvHhc/RcUfvLXwyoTo0xnFv7Ag
20:02:33 <shachaf> It admittedly has different semantics.
20:02:34 <b_jonas> ais523: ^ I don't think that's the url you wanted to paste
20:02:36 <b_jonas> the first one
20:02:59 <ais523> oh yes, I pasted the same link twice
20:03:10 <ais523> just use the second one, then, the match is more idiomatic than an if/then anyway
20:04:01 <b_jonas> I think you could translate that latter one to SML or haskell in a straightforward way; in lisp you'd have to use an if or some other conditional construct rather than pattern guards
20:04:34 <ais523> you can do it using if just fine, but OCaml's if syntax is ugly if the inside of the if is nontrivial
20:04:35 <b_jonas> oh yeah, we now have egel as our esoteric functional language with pattern guards too
20:05:35 <ais523> I would be surprised if there were constructs in OCaml that didn't translate easily to SML, apart from the object-oriented stuff and maybe polymorphic variants
20:06:57 <ais523> they belong to the same language family, after all
20:08:26 <esowiki> [[Talk:Esoteric coder]] N https://esolangs.org/w/index.php?oldid=73209 * DmilkaSTD * (+118) Created page with "== Uhm.. == Esocoder sounds better --~~~~"
20:08:33 <b_jonas> ais523: yes, they share a common ancestor
20:08:55 <b_jonas> and yes, I should eventually get back to the egel language and install a version with a working wrapper to HackEso
20:09:04 <b_jonas> because it's such a conveniently useful esolang
20:10:05 <ais523> polymorphic variants are great, incidentally, they make some programming tasks (e.g. writing compilers for which intermediate representations have different constructs legal at different points in the compile) much easier
20:10:37 <b_jonas> that sounds nice. what are they?
20:10:55 <ais523> you basically just use enum tags at will, matching only on the tags you expect to be present at that point in the program, and generating only the ones you're supposed to generate
20:10:58 <b_jonas> are they open variants (like Haskell classes) or closed variants (like Haskell algebraic data types with disjuction)?
20:11:10 <ais523> and the compiler statically checks that the producers and consumers match up
20:11:18 <b_jonas> ah, anonymous closed variants then
20:11:23 <ais523> yes
20:11:43 <ais523> anonymous closed variants where you can reuse the same tags across different variants, perhaps with different types for the associated data
20:12:02 <b_jonas> can you also typedef specific unions of them, so that you get saner error messages from the typechecker?
20:12:05 <ais523> yes
20:12:08 <b_jonas> good
20:12:15 <b_jonas> yes, that sounds like very useful
20:12:47 <ais523> they can be open as well, if you write a match where the last case is _ then the type system takes note of that
20:13:04 <ais523> and will let the caller supply you anything
20:14:13 <b_jonas> in other languages, you have to simulate them in one way or another. you can simulate them with a wrapper to the largest enum type; or, if the related types are in a tree structure (which is common but not universal) with nested enums; or with some crazy magic in Haskell
20:14:18 <b_jonas> I don't remember how the last one works
20:14:22 <esowiki> [[User:Emerald]]  https://esolangs.org/w/index.php?diff=73210&oldid=73166 * Emerald * (+2) Fixed heading size
20:15:13 <b_jonas> oh yeah, also with defining each type as separate enums and using compiler magic to write implicit cast functions from one to the other
20:15:35 <ais523> the OCaml implementation isn't quite as good as it could be, occasionally you need to explicitly write casts
20:15:44 <ais523> I'm not entirely sure what causes that to happen
20:16:01 <b_jonas> I was just thinking of these because I have an interpreter that may require such variant types where there are two related enums that overlap but neither is a subset of the other
20:16:49 <b_jonas> ais523: do you still have to write explicit casts if the involved enum types are closed and there are no free type paramters?
20:17:16 <ais523> b_jonas: it's confusing, I haven't figured out the exact trigger, it doesn't happen very often
20:17:37 <ais523> I think it's something like, if you use the same variable in two different contexts, and one context allows more variants than the other
20:17:41 <ais523> you need to write a cast
20:17:42 <b_jonas> no wait, that's not what I wanted to ask
20:17:49 <ais523> because the type inference algorithm is expecting each variable to have only one type
20:18:15 <b_jonas> ais523: do you still have to write explicit casts if the involved enum types are closed and there are no free type paramters, and the content of every constructor is exactly the same type everywhere (as opposed to a constructor appearing with different types, one of which is a subtype of another)?
20:18:35 <ais523> so if x can be either `A or `B, you can use it as a parameter to a function expecting a [`A | `B], or as a parameter to a function expecting a [`A | `B | `C]
20:18:46 <ais523> but if you try to use it with both, you need to write a cast or the type inference algorithm gets confused
20:19:16 <ais523> I think that's the only case that needs a cast, though
20:19:17 <b_jonas> ais523: how do you use the same variable as two different ones of those if the variable is immutable?
20:19:43 <ais523> b_jonas: well the variable is either a `A or a `B, right?
20:19:53 <ais523> so any function which accepts `A and `B as possible tags should be able to accept it
20:21:21 <ais523> or, hmm, this works: https://tio.run/##fcqxDsIwDIThnae4sR0YgLECCXiQFBU7WAoOal2pQ989xIi523@nLw@PdyolkYFxBs86mGRFf8X@ggNW9Devo9fd6wTRnfu47f9qqUoYNs4Ee9FPUprIXSWfUdQC6TOJUjNZnTFkDvVtGEvbdpskOinlCw
20:21:30 <b_jonas> ais523: is that even if you explicitly type the variable to an enum that can be `A or `B, as opposed to some case where the type inference just can't derive that because of confusing loops?
20:21:36 <ais523> so either the bug with casting has been fixed, or the cause is more complex
20:22:18 <ais523> here's how it looks with an explicit type: https://tio.run/##fYsxDsIwDEV3TvHHdmCAbiCQgGMglKLiBEvBqVpX6tC7hxgxd3v2fy91z0/MOZLC4wQ/SaecBO0F2zN2WNBejfZGN6MGLBvzw7r/t2YccC@rDY9SsIcOE0Hf9KsojmRN0fuBRR3JK7JQNWo5g0velW/lMdf1cVUJpuT8BQ
20:22:48 <b_jonas> ais523: wow, that looks like it has way too few parenthesis for something like this
20:23:40 <ais523> just for you, the same program with no parentheses: https://tio.run/##jYtBCsJADEX3PcW/gAt1p1hQjyEylZqMgTEjbQpd9O7jRFyLu5f893J/e6ZSEhkYB/CkvUlWdEesWqyxoDs5bZzOTluINu7H3/7XmrHDpa4@XGshDBsmgj3oU1EayZuqc5WXFqMNojFkDqLmj1e9LZDekyjtm/iPVsob
20:23:46 <b_jonas> I'll assume the cause is more complex, and it involves a case where the type inference algorithm can't easily see that the function can get only an `A or `B
20:23:51 <ais523> if you remove the explict type from x it has no brackets either!
20:24:08 <b_jonas> heh
20:24:20 <ais523> (|>) is the equivalent of flip ($)
20:24:25 <ais523> from Haskell
20:24:29 <esowiki> [[Jumplang]] M https://esolangs.org/w/index.php?diff=73211&oldid=73208 * PythonshellDebugwindow * (+190) 
20:24:48 <ais523> and is probably the more readable argument order
20:25:06 <ais523> I'm not sure if OCaml even has ($) in its standard library, but it's easy enough to implement
20:25:34 <esowiki> [[User:Emerald]]  https://esolangs.org/w/index.php?diff=73212&oldid=73210 * Emerald * (+319) Persuade
20:25:36 <ais523> OCaml operator names get a bit weird sometimes, because for mental parseability, all operators that start with the same first character have the same precedence
20:25:43 <b_jonas> ais523: the (general) identity function was added to the rust standard library only like a year ago
20:25:46 <ais523> e.g. |> has the same precedence as ||
20:25:47 <b_jonas> and it's useful
20:26:01 <b_jonas> and yes, it's also trivial to implement 
20:26:05 <ais523> what type does it have?
20:26:14 <b_jonas> ais523: it's a generic function actually, so no single type
20:26:15 -!- rain1 has quit (Quit: leaving).
20:26:16 <ais523> (in Rust, it's obvious in most languages)
20:26:30 <ais523> right, I was trying to figure out how you typed it in Rust
20:26:41 <b_jonas> it's like fn<T> identity(v: T) -> T { v }
20:26:46 <int-e> > let f = \case True -> 1; False -> 2 in map f [False ..] -- does this have too few parentheses as well?
20:26:49 <lambdabot>  [2,1]
20:26:49 <ais523> ah right, of course
20:26:56 <b_jonas> so the specific type for any one T is fn(T) -> T
20:27:12 <b_jonas> the generic one doesn't have a type and can't be used as a first-class value
20:27:34 <b_jonas> sort of like in C++ until perhaps lately when they made them usable as a class value with a templated overloaded () operator
20:27:50 <ais523> I guess you could set T to dyn Any, but that isn't all that useful a type
20:28:14 <ais523> … would identity even work on dyn Any, or would you need a box?
20:28:27 <b_jonas> ais523: I don't think it would work, or at least it wouldn't be useful
20:29:01 <b_jonas> ais523: one of the reasons why the identity function is useful is that it lets you write type ascriptions, sort of like (expression :: SomeSpecificType) in haskell
20:29:11 <ais523> ah, that isn't what I was guessing at all
20:29:19 <esowiki> [[User talk:Emerald]]  https://esolangs.org/w/index.php?diff=73213&oldid=73170 * Emerald * (+205) /* Tips For Making a Golfing Language */
20:29:23 <b_jonas> so you write them as identity<SomeSpecificType>(expression) in rust
20:29:28 <ais523> I thought you used it as a parameter to a higher-order function
20:29:32 <ais523> and no, you don't write them as that
20:29:37 <ais523> the < in that is the less-than operator
20:29:42 <b_jonas> yeah
20:29:49 <ais523> identity::<SomeSpecificType>::(expression)
20:29:53 <b_jonas> identity::<SomeSpecificType>(expression)
20:29:56 <ais523> not sure on the last ::
20:30:03 <b_jonas> no, I think it's a :: only on the left
20:30:11 <b_jonas> and I think the right one is an error
20:30:26 <ais523> yes; there /is/ a context where you need the :: on the right too, but it isn't that context
20:30:32 <b_jonas> and yes, you can also use it as a parameter to a higher-order function, which is the official argument for why it's in the stdlib now
20:31:25 <b_jonas> the same thing is useful in C++ too by the way, where it's not in the standard library yet, but I've used it for years in my previous work 
20:31:38 <b_jonas> I call it ret_cast but I don't think that's a standard name
20:32:09 <ais523> it's very similar to static_cast, I guess
20:32:20 <ais523> the only difference is that you can take its address, I think?
20:32:32 <b_jonas> no, that's not the difference
20:32:37 <ais523> thus letting you use it as a function argument even without giving it an argument
20:32:50 <b_jonas> the difference is that it doesn't do certain explicit conversions that static_cast would do without a warning
20:33:05 <ais523> oh, such as long to int?
20:33:12 <b_jonas> no, long to int is the one I want to do without a warning
20:33:21 <b_jonas> numeric conversion is my primary use for ret_cast
20:33:26 <b_jonas> and that's why it has a rather long definition,
20:33:37 <ais523> I kind-of assumed static_cast would warn for the weirder conversions
20:33:38 <b_jonas> because you need to suppress warnings about implicit number conversion in that one function
20:33:40 <ais523> but maybe it doesn't
20:33:47 <ais523> void* to intptr_t, for example
20:34:02 <ais523> I guess there has to be a way to show that's intentional
20:34:11 <b_jonas> I think static_cast will call a one-argument constructor marked as explicit, without a warning
20:34:17 <b_jonas> that's the main problem
20:34:26 <b_jonas> but the detailed rules are so complicated that I can't remember them
20:34:28 <b_jonas> C++ is weird
20:34:41 <b_jonas> so I gave up and just use ret_cast whenever I don't want such a surprise
20:36:52 <b_jonas> the definition is: #if _MSC_VER \ #pragma warning(push) \ #pragma warning(disable: 4244 4267) \ #endif \ template<typename dest_type, typename src_type> inline dest_type ret_cast(src_type &&x) { return std::forward<src_type>(x); } \ #if _MSC_VER \ #pragma warning(pop) \ #endif
20:37:26 <b_jonas> and I think there's some magic syntax to suppress the same warnings in gcc/clang too, but it's not the same as in MSVC and I haven't looked up what it is
20:37:52 <ais523> thinking about it, void* to intptr_t should be reinterpret_cast, really
20:38:04 <ais523> but maybe there are machines in which the bits actually change
20:38:15 <esowiki> [[ReThue]]  https://esolangs.org/w/index.php?diff=73214&oldid=50430 * DmilkaSTD * (+24) 
20:38:33 <ais523> what are the two warnings being disabled?
20:38:36 <b_jonas> ais523: I think it's a reinterpret_cast, not a static_cast, and the bits can change in a reinterpret_cast, but again I'm not sure about the rules
20:38:58 <b_jonas> ais523: uh, something about implicit numeric conversion, but I'm not sure what, I'd have to look it up in the MSVC docs
20:39:15 <ais523> oh, I see, you're explicitly turning off long-to-int style warnings
20:39:33 <ais523> I don't know enough C++ to properly follow the moves here
20:39:45 <b_jonas> https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=vs-2019
20:39:57 <ais523> if you use ret_cast on a variable, does its value get moved? I'm guessing no, because prefix && acts only on rvalues?
20:40:52 <ais523> also wow is that site badly organized
20:41:00 <ais523> you can't guess the URL for any particular warning
20:41:08 <b_jonas> ais523: admittedly that's for an old verions of MSVC I think
20:41:13 <b_jonas> but yes 
20:41:19 <ais523> because it depends on some arbitrary grouping that you wouldn't be able to learn without first finding the page for the warning
20:42:37 <b_jonas> ais523: if you use it on a non-const varible of say type int, then it gets instantiated with src_type being int &, in which case the magic && in the argument list disappears because there's a & before it, and the function takes int & as a type, so it takes a non-const reference to the variable and copies ity
20:43:12 <esowiki> [[Language list]] M https://esolangs.org/w/index.php?diff=73215&oldid=73150 * PythonshellDebugwindow * (+15) /* J */ + [[Jumplang]]
20:43:34 <b_jonas> whereas if you call it on an rvalue of type int, say ret_cast<long)(3+x), then the src_type is derived to be int, the function takes an argument int &&, and moves that value
20:43:44 <b_jonas> for an int this doesn't matter too much, because moving and copying it is the same thing
20:43:46 <ais523> how C++
20:44:09 <ais523> even Rust's move vs. copy rules are more complex than I'd like
20:44:13 <ais523> but this is worse
20:44:19 <ais523> (yes, I know Rust's are simple)
20:44:41 <b_jonas> but for a non-trivial type where moving and copying isn't the same, it can matter, and this mostly does the Right Thing^TM, except if you try to pass an initializer-list into it
20:45:07 <esowiki> [[User:PythonshellDebugwindow]] M https://esolangs.org/w/index.php?diff=73216&oldid=73162 * PythonshellDebugwindow * (+99) /* Languages */
20:50:57 <b_jonas> also, today I read some of the (easy parts of) the source code of ImageMagick, to figure out what the interface of a certain public API function in MagickWand is, since it wasn't properly documented
20:52:38 <b_jonas> luckily the command line ImageMagick programs are implemented (mostly) in terms of MagickWand (the high-level C api of ImageMagick), so the source code for that has a place where it calls this function, and I could find out what it expects as the second argument from there
20:52:47 <zzo38> Which function?
20:53:23 <zzo38> (And, what version of ImageMagick?)
20:53:50 <b_jonas> MagickSetImageChannelMask and ImageMagick 7
20:54:07 <b_jonas> this corresponds to the -channel setting in command line
20:54:42 <b_jonas> the second argument is a bitmask for which enum values are defined in a header
20:56:35 <b_jonas> and I need this for the -combine operation, which takes multiple grayscale images and converts them to a single image with those used as different channels, but you have to tell what those channels are, eg. RGB, RGBA, IA, CYMK, etc, and you use the -channel option for that
20:56:55 <b_jonas> and then you have to restore that setting with +channel, which calls the same function with some default argument
20:59:24 -!- tromp has quit (Remote host closed the connection).
21:02:27 -!- TheLie has joined.
21:02:34 <zzo38> Do you know if the latest version of ImageMagick supports YCoCg, and if it supports farbfeld, and if it supports pictures with custom separations?
21:04:26 <b_jonas> zzo38: I don't know if it supports YCoCg specifically. It has some formats that read YUV and convert it to RGB immediately, and the inverse for writing. It probably doesn't have too much support for keeping an image as YUV, but you can probably still do it just have to be careful with all operations that assume RGB or CYMK.
21:04:58 <b_jonas> and I don't know about custom separations, but I think ImageMagick 7 specifically improved about handling custom channels or color spaces compared to ImageMagick 6
21:05:04 <b_jonas> I don't know the details though
21:05:16 <zzo38> Yes, I thought I read that too, but I don't know the details either.
21:06:53 <b_jonas> it says there's a "YCbCr" and "YCbCrA" format, I don't know if that's the same as YCoCg; and there's a YUV format for YUV with subsampling
21:08:59 <esowiki> [[Jumplang]]  https://esolangs.org/w/index.php?diff=73217&oldid=73211 * Emerald * (+726) Commands
21:12:30 <zzo38> I think it isn't the same as YCoCg.
21:14:37 <b_jonas> zzo38: anyway, I mostly used ffmpeg to read or write YUV format, but not too much, mostly ffmpeg just did conversion to/from YUV formats implicitly because that's how jpeg and and many compressed video formats store colors
21:16:27 <zzo38> Although conversion between YCoCg and RGB is lossless anyways, so simply if you want to use file formats that support YCoCg, there is no need for ImageMagick to support them directly, unless you want to directly manipulate the data in YCoCg format, such as to separate them.
21:17:39 <b_jonas> zzo38: also I used ffmpeg to read uncompressed bayer mosaic frames, which is what digital color camera sensors actually capture, and high-end cameras can send you the raw uncompressed thing (if you can take the bandwidth)
21:17:42 <esowiki> [[Jumplang]] M https://esolangs.org/w/index.php?diff=73218&oldid=73217 * PythonshellDebugwindow * (+50) /* Commands */ clarify
21:18:06 <b_jonas> ffmpeg can read them and debayer them 
21:18:19 <b_jonas> and then I encode that to a lossy compressed video
21:18:23 <esowiki> [[Jumplang]] M https://esolangs.org/w/index.php?diff=73219&oldid=73218 * PythonshellDebugwindow * (+36) /* Differences from brainfuck */
21:18:37 <zzo38> O, OK. I have not worked with that, although it does seem something you may want to deal with.
21:18:47 <esowiki> [[Jumplang]] M https://esolangs.org/w/index.php?diff=73220&oldid=73219 * PythonshellDebugwindow * (+63) /* Commands */
21:18:58 <zzo38> But I think the raw camera format is TIFF, so requires parsing all of the TIFF stuff?
21:19:58 <b_jonas> zzo38: there are various brand-specific raw camera formats, some of which are TIFF, and most of them are compressed to some amount for photo cameras, because compression is useful; the uncompressed bayer was for a video camera,
21:20:37 <b_jonas> there the hard part is getting the uncompressed raw video stream (in a high enough frame rate that we need) through the network, and we did set up a network that has bandwidth for that, 
21:21:34 <b_jonas> and if you do have such a bandwidth then the compression would just hurt. this was over ethernet, but some other camera models send similar uncompressed bayer frames through USB instead
21:31:35 -!- tromp has joined.
22:03:28 <zzo38> Other possibility might be to use a kind of digital video connection, although I think that they are not designed for use with Bayer frames. Still, you could perhaps use Digi-RGB with monochrome or pre-interpolated data, and then if they are pre-interpolated (which must be done in a reversible way, if this is to be done), to reverse this operation on the receiver.
22:05:35 <b_jonas> zzo38: we don't need to reverse the debayering. we want to debayer it anyway, transform it to some YUV format with chroma subsampling, and compress it. ffmpeg can do all those steps for me.
22:06:11 <b_jonas> all this is for digital cameras; feed from analog cameras is worse because it's often interlaced odd/even rows
22:07:45 <zzo38> Yes, you usually don't need to reverse the debayering. But I don't know if someone will sometimes need it.
22:16:51 -!- tromp has quit (Remote host closed the connection).
22:20:17 <esowiki> [[Talk:Jumplang]] N https://esolangs.org/w/index.php?oldid=73221 * Emerald * (+1016) /* Turing-Completeness */ new section
22:20:53 <esowiki> [[Talk:Jumplang]] M https://esolangs.org/w/index.php?diff=73222&oldid=73221 * Emerald * (+25) /* Turing-Completeness */
22:25:00 <esowiki> [[Jumplang]]  https://esolangs.org/w/index.php?diff=73223&oldid=73220 * Emerald * (+18) /* Turing-completeness */
22:47:05 -!- ArthurStrong has joined.
22:53:29 <zzo38> I looked at the documentation of GNU troff, which describes the font file format it uses. It lacks some features that TeX has, and has some features that TeX doesn't have. Such as, the only ligatures it supports are "ff", "fi", "fl", "ffi", and "ffl"; the metrics includes not only italic correction but also left italic correction and subscript correction.
23:04:48 -!- Lord_of_Life_ has joined.
23:05:23 -!- Lord_of_Life has quit (Ping timeout: 258 seconds).
23:06:11 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
23:07:43 -!- TheLie has quit (Remote host closed the connection).
23:17:14 -!- zseri has quit (Quit: zseri).
23:18:34 <esowiki> [[Jumplang]] M https://esolangs.org/w/index.php?diff=73224&oldid=73223 * PythonshellDebugwindow * (-64) 
23:37:42 <esowiki> [[(1) Grace sent you a message]]  https://esolangs.org/w/index.php?diff=73225&oldid=72821 * Hakerh400 * (+558) /* Computational class */
23:39:36 <esowiki> [[Talk:(1) Grace sent you a message]]  https://esolangs.org/w/index.php?diff=73226&oldid=73197 * Hakerh400 * (+112) /* Computational class */