00:11:43 <zzo38> I have installed Xfig 3.2.8 and already found two things wrong that I corrected; one is that one file doesn't check if it should use Xaw3d or not (and therefore won't compile without Xaw3d), and other is that clicking the rulers to scroll will always scroll the same amount instead of depending on where you clicked on.
00:12:59 <zzo38> (Fix amounts scrolling is still possible by pushing the arrows, though)
00:23:06 <zzo38> (Although, the scrolling working is not really a bug; it is documented. But, it is inconsistent with xterm.)
00:32:46 <zzo38> In future, hopefully function to be added can include: additional keyboard commands (e.g. quick access to object attributes), text with TRON code, and possibly some others too.
00:46:36 -!- Lord_of_Life has quit (Ping timeout: 248 seconds).
00:47:31 -!- Lord_of_Life has joined.
01:52:38 -!- Noisytoot has quit (Remote host closed the connection).
01:59:43 -!- Noisytoot has joined.
02:37:27 <esolangs> [[User:GUAqwq]] https://esolangs.org/w/index.php?diff=117365&oldid=117230 * GUAqwq * (-1959) Replaced content with "==My esolangs== * [[Tetrastack]] (TC) * [[Transet]] (TC)"
02:39:34 <esolangs> [[Transet]] https://esolangs.org/w/index.php?diff=117366&oldid=117356 * GUAqwq * (-3)
03:00:44 -!- ais523 has quit (Quit: sorry about my connection).
03:07:05 <esolangs> [[Bawkbawk]] M https://esolangs.org/w/index.php?diff=117367&oldid=117354 * Lilchiky * (+4) /* +4 bytes */
03:16:12 -!- moony3 has quit (Ping timeout: 255 seconds).
03:16:46 -!- moony has joined.
04:15:43 <esolangs> [[Bawkbawk]] M https://esolangs.org/w/index.php?diff=117368&oldid=117367 * Lilchiky * (+240) two new commands!
04:17:25 <esolangs> [[Bawkbawk]] M https://esolangs.org/w/index.php?diff=117369&oldid=117368 * Lilchiky * (+32) /* Truth machine */ gets an upgrade!
05:01:22 <zzo38> Why doesn't Xfig set the focus of windows when they are displayed? All other Xaw-based programs (including ones that I write myself) do so automatically, without needing to adding anything special into the program.
07:23:50 <zzo38> I fixed it by adding a window manager setting specific for this program, although that doesn't seems best way to do it.
07:32:22 -!- Koen has joined.
08:12:22 -!- Sgeo has quit (Read error: Connection reset by peer).
08:37:21 -!- sprout_ has joined.
08:37:51 -!- sprout has quit (Ping timeout: 260 seconds).
09:30:49 <esolangs> [[NASAL]] M https://esolangs.org/w/index.php?diff=117370&oldid=117318 * Kaveh Yousefi * (-4) Rectified an orthographic mistake.
09:35:01 -!- cpressey has joined.
09:42:24 <cpressey> I haven't read the paper in detail, but to shachaf's original question, I can't see what having more than one group-based memory cell could give you over having just one, because I can't think of any case where you can't encode the information that resides in two elements of a group into a single element of a combined group. Then again, IANAGT.
09:44:13 <cpressey> I think there probably groups that you can augment a FSM with, that make it Turing-complete, or make it into a PDA, etc. I think the idea is more about investigating what groups relate to what computability classes.
09:44:37 -!- arseniiv has joined.
09:45:06 -!- __monty__ has joined.
10:25:52 <int-e> PDA seems easier with a monoid
10:26:38 <int-e> (The point is, you can have pure right inverses with a a^-1 = 1 but not a^-1 a = 1. Can't do that in groups.)
10:37:50 <int-e> cpressey: Especially in the case of groups, the term "memory" is a bit misleading since the automaton can't inspect it. With inspection capabilities having more than one group could become useful. Without I agree that you get the same effect with direct products.
10:41:32 <int-e> (There are /probably/ tricks to get a PDA with a group. I just can't work it out.)
10:41:58 <esolangs> [[Special:Log/newusers]] create * Moltony112 * New user account
10:44:41 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=117371&oldid=117326 * Moltony112 * (+152) /* Introductions */
11:06:43 <esolangs> [[Talk:Nice]] https://esolangs.org/w/index.php?diff=117372&oldid=117359 * None1 * (+151)
11:07:27 <esolangs> [[User:None1/ToDo]] https://esolangs.org/w/index.php?diff=117373&oldid=117178 * None1 * (+67) /* Content */
11:10:10 -!- sprout_ has changed nick to sprout.
11:26:22 <cpressey> Yeah, groups might have too much symmetry to make a PDA, I dunno.
11:27:36 <cpressey> For a more bizarre take, we might observe that 1 counter isn't enough to make a PDA and 2 counters is too many, so how many counters do you need to make a PDA, anyway? 1.414, perhaps?
13:00:58 <cpressey> int-e: true, the automaton can't inspect the "memory", but a thought just occurred to me. If the automaton is non-deterministic then we can think of its choice points as guesses of the value of the memory cell, and the accepting paths will be those where all of those guesses were correct. Not sure if this is a good substitute for actually being
13:00:58 <cpressey> able to inspect the cell, but it... sounds somewhat plausible.
13:02:19 <cpressey> I should probably read the paper, it's just that that's, like, a lot of concentration-commitment that I don't want to make atm
13:02:35 <cpressey> Would rather run my mouth off on IRC apparently
13:20:24 <int-e> Yeah, I assumed that we were going to use non-determinism.
13:21:02 <int-e> I have not read the full paper either. I skimmed for keywords, saw some hints of product constructions...
13:21:15 <int-e> And I checked some definitions.
13:25:45 <int-e> cpressey: The point I was making about monoids was basically that yes, you can actually get inspection through speculative execution, so to speak. If you have a a^-1 = 1 but no reduction for b a^-1 (b != a) or a^-1 b (b = a allowed), then thats exactly the same as popping a from a stack. And you still have product monoids, so you can have many stacks. So that'll be TC.
13:26:17 <int-e> "that" being "appending a^-1 to the monoid component"
13:30:28 <esolangs> [[Starfish]] M https://esolangs.org/w/index.php?diff=117374&oldid=107982 * ApisNecros * (+1) Change link to https
13:40:13 <esolangs> [[Alpha]] N https://esolangs.org/w/index.php?oldid=117375 * Infinitehexagon * (+589) Created page with "'''Alpha''' is an esoteric programming language that is part of a series by [[User:Infinitehexagon]] on Greek esolangs that will be a derivative of the previous esolang with more commands, less commands, or modified commands. So far it has 6 commands. {| class="wik
13:41:27 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117376&oldid=117375 * Infinitehexagon * (+69)
13:44:28 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117377&oldid=117376 * Infinitehexagon * (+106)
13:49:32 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117378&oldid=117377 * Infinitehexagon * (+115)
13:53:37 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117379&oldid=117378 * Infinitehexagon * (+22)
14:04:48 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117380&oldid=117379 * Infinitehexagon * (+180)
14:10:23 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117381&oldid=117380 * Infinitehexagon * (+245)
14:10:41 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117382&oldid=117381 * Infinitehexagon * (+7) /* Hello World */
14:13:05 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117383&oldid=117382 * Infinitehexagon * (+43)
14:16:16 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117384&oldid=117383 * Infinitehexagon * (+59)
14:16:31 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117385&oldid=117384 * Infinitehexagon * (+1)
14:17:57 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117386&oldid=117385 * Infinitehexagon * (+2)
14:18:17 <esolangs> [[User:Infinitehexagon]] https://esolangs.org/w/index.php?diff=117387&oldid=116600 * Infinitehexagon * (+14) /* My Esolangs (chronological order) */
14:26:04 <esolangs> [[DStack]] M https://esolangs.org/w/index.php?diff=117388&oldid=51744 * Europe2048 * (+0) Fixed a typo.
14:54:19 <esolangs> [[Bawkbawk]] M https://esolangs.org/w/index.php?diff=117389&oldid=117369 * Lilchiky * (+437) life becomes easier
14:55:59 <esolangs> [[Bawkbawk]] M https://esolangs.org/w/index.php?diff=117390&oldid=117389 * Lilchiky * (+0) /* Commands */ wut happened?
14:56:29 <esolangs> [[Bawkbawk]] M https://esolangs.org/w/index.php?diff=117391&oldid=117390 * Lilchiky * (-9) /* Commands */ wut happnd agen?
14:56:52 <esolangs> [[Bawkbawk]] M https://esolangs.org/w/index.php?diff=117392&oldid=117391 * Lilchiky * (-1) /* Commands */ HUH?
14:57:14 -!- Europe2048 has joined.
14:57:32 <esolangs> [[Bawkbawk]] M https://esolangs.org/w/index.php?diff=117393&oldid=117392 * Lilchiky * (+12) /* Commands */ this must work
14:58:16 <Europe2048> Oh, hi +esolangs! I'm User:Europe2048 on Esolangs.
15:00:37 <esolangs> [[Bawkbawk]] M https://esolangs.org/w/index.php?diff=117394&oldid=117393 * Lilchiky * (+7) /* Text to Bawkbawk */ fixin' the script
15:03:00 -!- Europe2048 has left.
15:03:03 -!- Europe2048 has joined.
15:04:51 <cpressey> The IRC channel is quiet a lot of the time these days, but there is occasional activity. The logs tell the story
15:05:09 <esolangs> [[Bawkbawk]] M https://esolangs.org/w/index.php?diff=117395&oldid=117394 * Lilchiky * (-443) script doesn't work :c
15:07:45 <cpressey> I joined Libera recently too. The last time I was here was back in the freenode era.
15:11:12 <Europe2048> What's your Esolangs username and how long ago did you join Esolangs?
15:11:52 -!- wib_jonas has joined.
15:12:01 <wib_jonas> cpressey: you were here in spirit though. and in the quotes file.
15:13:52 -!- ais523 has joined.
15:14:51 <ais523> cpressey and I have both been involved with esolangs for ages (cpressey longer than me)
15:15:04 <Europe2048> My Esolangs username is Europe2048, what's yours?
15:15:31 <ais523> both somewhat predictable
15:15:57 <Europe2048> Also, wow, you created a lot of esolangs.
15:16:27 <ais523> I got better at it over time
15:16:44 <ais523> I am mostly interested in Turing tarpits and golfing languages, but the tarpits are much easier to create
15:17:16 <Europe2048> Which of your languages needs to be improved?
15:18:05 <ais523> the newer ones generally don't have a whole lot of decisions to be made when designing them – and when I do find an improvement, often it's a language of its own
15:18:35 <wib_jonas> yep, you can't really modify them, keep it or condemn it, those are the choices
15:18:43 <ais523> e.g. https://esolangs.org/wiki/Brainpocalypse_II is usually easier to implement than https://esolangs.org/wiki/Brainpocalypse, and also runs faster, but some languages find the original Brainpocalypse to be a better fit
15:19:06 <ais523> the sorts of languages that can be modified easily are the sort that have lots of commands
15:19:30 <ais523> e.g. I modified https://esolangs.org/wiki/Esimpl earlier this year because the program wasn't conveying all the information that an interpreter needed
15:20:03 <ais523> (and to answer your earlier question, yes, esolangs is a bot)
15:21:54 <ais523> for Turing tarpits, the computational class proof is often part of the language in spirit; it is often possible to improve those
15:22:09 <ais523> typically by allowing the language to be implemented using fewer resources
15:22:15 <esolangs> [[Pokecontest]] M https://esolangs.org/w/index.php?diff=117396&oldid=88351 * PythonshellDebugwindow * (+9) Stub
15:23:03 <wib_jonas> that's often true for toy languages with lots of choices too, funnily. it's easier to make entirely new languages than trying to save my old interpreted languages (psz, geo and scan)
15:23:24 <Europe2048> wib_jonas and ais523, check out my language: https://esolangs.org/wiki/Deadfish++
15:24:38 <Europe2048> Note: it's high-level because you can store strings in variables.
15:24:45 <ais523> Europe2048: I think that sort of language is designed pretty commonly
15:24:53 <ais523> there are a lot of esolangs like it, and it gets hard to choose between them at some point
15:24:57 <cpressey> I used to design esolangs, but not as much anymore. I still, uh, do things with, uh, languages an' stuff, but yeah
15:25:10 <ais523> not that it's a bad design, just that it's a commonly repeated one
15:25:32 <Europe2048> But I think my extension is the most powerful by now.
15:27:13 <wib_jonas> you get one point from me for pretending that you are extending Deadfish instead of Brainfuck, even if in these sorts of extensions the base language is totally irrelevant because all the power comes from the extensions
15:28:26 <ais523> power in esolangs can be hard to define, when you get up to higher levels
15:28:50 <ais523> (at the lowest level, you can consider X to be more powerful than Y if X can implement Y more efficiently than Y can implement X – with very low-level esolangs this is normally obvious)
15:29:28 <wib_jonas> ais523: you said recently that Blindfolded Arithmetic is Turing-complete with just two variables. have you ever written a draft proof down for that? or did I misunderstand that and you only said three variables?
15:29:36 <ais523> it's linked at the bottom of the article
15:29:56 <ais523> http://nethack4.org/esolangs/blindfolded-arithmetic-2var.txt
15:31:05 -!- tromp has joined.
15:31:15 <Europe2048> ais523, this definition proves that Deadfish++ is indeed more powerful than Deadfish.
15:31:50 <wib_jonas> I'll have to look at that because two variables needs more complicated tricks than three. This is a good way to get more value out of existing interesting languages, by considering obvious restrictions.
15:31:52 <Europe2048> Because you can't implement Deadfish++ with Deadfish - there is no input in Deadfish.
15:32:11 <ais523> Europe2048: most languages are more powerful than Deadfish
15:32:14 <wib_jonas> I should perhaps get back to trying to figure out how the restricted versions of Amycus work
15:32:39 <ais523> today I have been trying to find the minimum Turing-complete value of d in Spiral Rise
15:33:28 <ais523> I'm think it's likely that 3 is possible – instead of implementing a tag system, you would implement a Couplet 2C variant
15:33:47 <ais523> (which is more powerful than tag in terms of efficiency with which it can implement things, so it'd be a good change anyway)
15:34:18 <ais523> 2 does not seem obviously impossible, but is a very obnoxious language to program in
15:34:48 <ais523> obviously you can't do 1, because "divmod by 1" does not have any computational power
15:35:06 <ais523> err, minimum Turing-complete *integer* value
15:35:10 <ais523> Spiral Rise technically works on non-integers
15:36:51 <ais523> the language would be defined – it might be hard to implement though
15:37:23 <wib_jonas> as for blindfolded arithmetic, https://esolangs.org/wiki/Analytical_Engine_Programming_Cards , which claims to be kind of a reconstruction based on Babbage's plans, somehow uses 50 digit wide numbers, with full multiplication of two 50 digit numbers to 100 digits, and full division of 100 digits by 50 digits to 50 digits divisor and reminder. the
15:37:24 <wib_jonas> 50 digits sounds way too many to me, and I don't understand why anyone would plan for that wide numbers. I understand why we want SIMD on wide registers today, but nothing that would allow that is present in the language that they describe, so it's not about that.
15:37:27 <ais523> it turns out that, once you go beyond the rationals, there isn't a reliable way to tell whether an expression evaluates to 0 or not
15:38:06 <ais523> wib_jonas: the Analytical Engine's predecessor was intended to produce tables of various expressions
15:38:19 <wib_jonas> ais523: I still say that there is a decently easy way for quadratic irrationals (expressions with numbers, field operations, and square roots), despite that when I once tried to implement the algorithm I failed
15:38:24 <ais523> presumably some level of accuracy was required in the output, and more accuracy would be required in the intermediate calculations for the output to be right
15:38:53 <wib_jonas> ais523: ok, but I don't think even that would require 50 digits
15:39:14 <ais523> I get the feeling that Babbage was pretty ambitious
15:39:26 <ais523> and computer programming was pretty undeveloped at the time
15:39:36 <ais523> so maybe Babbage thought it'd require 50 digits, even if he was wrong?
15:40:21 <wib_jonas> I get the feeling that Babbage is irrelevant here, and people are just projecting whatever retrofuturistic thing they want to imagine to Babbage because it sounds better that way, sort of like with Leonardo da Vinci
15:40:38 <wib_jonas> (but you could say that I do the same with Gauss so who am I to say that)
15:41:06 <wib_jonas> Europe2048: https://esolangs.org/wiki/Analytical_Engine_Programming_Cards
15:41:38 <ais523> wib_jonas: https://en.wikipedia.org/wiki/Nested_radical implies it can be done for square roots specifically
15:42:06 <ais523> unless, there is some sum of square roots that can't be proven to equal or not equal 0
15:43:13 <wib_jonas> ais523: yes it can be done for square roots, the question is just whether you can consider that algorithm easy, and I am arguing that you can
15:43:44 <ais523> there is complexity due to the distinction between the positive square root and the negative square root
15:44:13 <wib_jonas> you can also do computations with roots of arbitrary algebraic numbers described by a polynomial of which it is a root and some bounds, but nobody claims that the algorithms for that one is easy, and there are very few implementations for that
15:45:04 <wib_jonas> ais523: no, I don't believe there is complexity from the sign of the square root. you only allow real numbers and positive square roots, and that doesn't cause any complexity.
15:45:33 <wib_jonas> the algorithm is so simple that it's taught to high school mathematics competition preppers at least
15:46:11 <ais523> Europe2048: the syntax b_jonas linked appears to have a P command that prints numbers
15:47:21 <wib_jonas> as for Babbage, are there any esoteric programming languages that claim to be based on *Leibniz's* plans instead of Babbage's? Leibniz lived much earlier so I think you could get away with much more freedom there, yet everyone refers to Babbage instead.
15:47:53 <Europe2048> ais523: No, I meant to output characters.
15:48:32 <ais523> I don't think the Analytical Engine could output characters
15:48:49 <ais523> after all, it was intended for calculating tables of numbers
15:48:53 <ais523> …and ASCII hadn't been invented yet
15:51:23 <ais523> you don't necessarily have to do anything with it
15:51:26 <wib_jonas> oddly enough, https://esolangs.org/wiki/Analytical_Engine_Programming_Cards seems to describe that it can output characters, near the bottom of "Attendant Cards", which would be statements executed by the human operators of the machine, so presumably the machine just instructs them to copy the table header from the card to the printout with a pen
15:52:46 <cpressey> wib_jonas: Did Leibniz have any ideas for machines other than https://en.wikipedia.org/wiki/Stepped_reckoner and the https://en.wikipedia.org/wiki/Calculus_ratiocinator ? The former might be a tad too basic, and the latter a tad too ambitious...
15:54:23 <wib_jonas> cpressey: I'm thinking of the latter. it's too ambitious, which is exactly why you can write good fan fiction about it, since it's not a specific planned machine but a goal for what the machine should do
15:55:37 <cpressey> Europe2048: what languages do you like? Not just esolangs, but other languages also
15:55:43 <ais523> I think the reason people like the Analytical Engine is that it's very well-documented and we know pretty much exactly what Babbage was planning
15:56:56 <wib_jonas> ais523: if that's so then why is https://esolangs.org/wiki/Analytical_Engine_Programming_Cards so different from https://www.ioccc.org/years-spoiler.html#1992_buzzard.1 when both claim to be based on the Analytical Engine?
15:57:57 <wib_jonas> Buzzard's IOCCC entry claims that the Engine would be doing blindfolded arithmetic, only with more than just six variables; while the Programming Cards has usable conditional branches
15:59:00 <wib_jonas> I can understand if the IOCCC entry uses built-in C integer arithmetic just to work as an IOCCC entry, but the blindfolded part is central to that entry and is not required for it to work as an IOCCC entry
15:59:25 <ais523> it may be that not all the people have actually read the documentation
15:59:35 <wib_jonas> the entry specifically wants to show how to program blindfolded, because Babbage supposedly designed his machine blindfolded
15:59:38 <ais523> I haven't, just read reports written by other people who read it
16:00:36 <ais523> oh right, re: conditionals, I think they might still have been in development when Babbage died?
16:05:06 -!- FreeFull has joined.
16:06:04 -!- Europe2048 has set topic: Welcome to the 20th international hub of esoteric programming languages of the noncriminal sort, and unicorns! | https://esolangs.org | logs: https://logs.esolangs.org/.
16:13:03 <ais523> wib_jonas: I'm actually reading Ada Lovelace's notes, she definitely mentions conditionals existing
16:13:27 -!- Europe2048 has left.
16:13:31 -!- Europe2048 has joined.
16:13:32 <wib_jonas> hmm, that's a bit disconcerting, that means the IOCCC entry was based on a lie
16:14:19 <ais523> actually, that was even in a bit she translated from Babbage's notes, rather than one she came up with herself
16:14:31 <ais523> although Babbage didn't give details, just said conditionals would be required
16:15:30 <ais523> oh wow, Ada Lovelace invented single static assignment
16:15:48 <ais523> …and then it took decades for compiler writers to rediscover it :-D
16:19:19 <cpressey> Europe2048: What do you want to talk about?
16:20:22 <ais523> wib_jonas: for variables
16:23:54 <cpressey> Europe2048: Deadfish++ looks not very hard to implement (I say this as someone who's been writing language implementations for many years though).
16:24:19 <cpressey> (And also, in contrast to some languages on the wiki that are literally impossible to implement)
16:25:13 <Europe2048> But the real hardest part about implementing is the Unicode variables and strings in variables.
16:25:41 <ais523> you're using Python, aren't you? Python 3 supports Unicode very well, and can store strings in variables that are normally used to store numbers
16:25:58 <cpressey> I was just about to say that. It was a pain in 2.x, but much better now
16:26:53 <ais523> you don't need OOP for this, old-fashioned imperative code will work fine
16:26:55 <Europe2048> Also, it is very hard to implement the if-else syntax.
16:27:05 <Europe2048> Because of these problems, my language is high-level.
16:27:25 -!- Thelie has joined.
16:27:36 <cpressey> If you don't have much experience writing parsing code, then the "if" syntax might seem difficult, because of the nesting
16:28:37 <cpressey> There's also some infix expressions and, well, not much indication of what the precedence rules are
16:28:44 <ais523> I am upset that efficient parser generators aren't generally easier to use (to the extent that parser combinator libraries have caught on despite having terrible worst-case performance)
16:29:30 <cpressey> I think I will need to be afk for a little bit now though. Nice meeting you Europe2048
16:30:28 <wib_jonas> ais523: dunno, the impression that I get is that people just keep making ambiguous hard to parse languages for some reason. I no longer believe the traditional narrative that old languages like Fortran had an odd grammar and ambiguities because the theory of formal languages wasn't developed yet.
16:30:50 <wib_jonas> Modern languages are the same, so the problem can't be the lack of theory of formal languages.
16:31:21 <ais523> wib_jonas: a good parser generator would be able to detect most reasonable ambiguities in a language
16:31:36 <ais523> or, to put it a better way, prove reasonable languages unambiguous, or complain if they aren't
16:31:42 <wib_jonas> people can already detect the ambiguities, and they insist on keeping the language that way
16:31:52 <wib_jonas> I don't think the problem is the lack of tools there
16:31:59 <ais523> there are languages for which ambiguity checks are uncomputable, but they don't resemble anything you'd design intentionally
16:33:27 <wib_jonas> but on the plus side, rustc now manages to parse three different syntaxes, such that not only you can link crates compiled from different syntaxes to the same runtime, but you can actually invoke macros that are written in one syntax inside a source file with another syntax. that means they can fix some of the more annoying ambiguities.
16:33:38 <ais523> I think lack of *good* tools is a problem – people don't currently use the tools because they aren't good enough, and thus don't get the ambiguity warnings
16:34:29 <ais523> wib_jonas: the Rust ambiguity that bothers me most is probably that in «x.f(a)», «f» could either be an inherent impl or a trait impl
16:34:36 <wib_jonas> I am very much hoping that at some point they'll allow Foo() instead of Foo when Foo is an argumentless constructor for a struct or enum variant, and then in yet another version they *require* the parenthesis after argumentless constructors in patterns (not in expressions), to solve that ambiguity
16:35:01 <Europe2048> OK, let's finish talking with implementation. What do you think should be added to my language?
16:35:02 <ais523> and the rules for resolving the ambiguity have some really weird consequences
16:35:28 <ais523> wib_jonas: I personally believe that Rust should have enforced case-of-first-letter for identifiers
16:36:00 <wib_jonas> ais523: why is that one a problem? in `x.f(a)`, f can also be a trait impl from multiple different traits, so that's like ordinary clash between imported identifiers. do inherent impls make this any more complicated?
16:36:01 <ais523> that would also solve that ambiguity (in addition to other annoying situations like the turbofish)
16:37:11 <ais523> wib_jonas: basically the problem is that there is no way to disambiguate to use *only* an inherent impl and not a trait impl – the default is to use the inherent, and the only disambiguator picks the trait impl
16:37:16 <wib_jonas> ais523: I'm not sure. I don't like case-of-first-letter rule, but I'm not sure if that's because it's inherently a bad idea, or only because it reminds me of Haskell and prolog
16:37:35 <ais523> this means that, if both the inherent and trait impl exist, and then the inherent impl gets deleted, there is no way to stop the trait impl being used, so your code breaks silently in cases where you really want to use the inherent impl only
16:37:49 <ais523> (unless you don't import the trait, but you might need to use it elsewhere in the code)
16:38:15 <Europe2048> OK, let's finish talking with implementation. What do you think should be added to my language?
16:38:57 <wib_jonas> ais523: if that's the problem, can't you just define a new trait, move the method changing it from inherent to trait, because of the ambiguous syntax existing code that tries to call the old inherent method will still work, but you can disambiguate by naming the trait
16:39:46 <wib_jonas> at one point some ruster tried to explain to me why inherent methods are different from a train method from an anonymous trait, but I forgot what the reasoning was and whether it made sense
16:39:49 <ais523> wib_jonas: assuming you control both files in question, that probably works
16:41:16 <ais523> one ambiguity that isn't a problem in practice, but I find amusing, is the lexer ambiguity on input like «0.0»
16:41:32 <ais523> which could lex as either a single float, or as "the first tuple field of the integer 0"
16:42:04 <wib_jonas> yes, that comes up in python and languages like that. not quite 0.0, but for eg. 2.sin which you have to write as 2 .sin instead
16:42:28 <lambdabot> (Num (b -> c), Num (a -> b)) => a -> c
16:42:48 <ais523> wib_jonas: that actually isn't an ambiguity, it's just a consequence of using a lexer that isn't sufficiently context-aware
16:43:21 <ais523> «(2.)» sin doesn't parse, after all, so the other meaning is invalid and thus it isn't ambiguous
16:43:54 <ais523> I am increasingly convinced that using a separate lexer is wrong, and the better solution is to improve the quality of scannerless parsers
16:43:54 <wib_jonas> ais523: it can be an ambiguity if you have numeric literals like 0.5f or 0x4p-3
16:44:38 <ais523> wib_jonas: you mean on "0.f" specifically? I can't see a way to do it with the hex float
16:45:17 <wib_jonas> 0x0.A is a hex float, with A being a hex digit, but 0x0 is a number and you can try to call the .A method on it
16:45:31 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117397&oldid=117386 * Infinitehexagon * (+328)
16:45:51 <wib_jonas> or 0x0.Ap0 if you insist on the p being present
16:45:52 <ais523> wib_jonas: I thought hex floats had a mandatory "p" specifically because of that
16:46:06 <wib_jonas> 0x0.Ap0 is a hex float, 0x0 .Ap0 is a method call on 0x0
16:46:07 <ais523> but right, I forgot they could have decimal points earlier
16:46:24 <ais523> 0x0 .Ap0 isn't a method call, it's a property query
16:46:39 <wib_jonas> it's a method call in python or ruby where this problem comes up
16:46:41 <ais523> …ooh, unless you can call a hex float as a function?
16:46:47 <ais523> I think parsers allow that even if lexers don't
16:46:55 <ais523> * even if the compiler as a whole doesn't
16:47:19 <ais523> "SyntaxWarning: 'int' object is not callable; perhaps you missed a comma?" "TypeError: 'int' object is not callable"
16:47:30 <ais523> no, ipython3, I was actually trying to call an int to see what the error message would be
16:47:39 <wib_jonas> in C++ traditionally it's no problem because numeric literals are of built-in types and they don't have members so you can't subscript them. this is no longer true because of user-defined literals, but those come with their ambiguities already
16:47:47 <ais523> the SyntaxWarning suggestst that the parser does understand that calling an int isn't a sensible thing to do
16:48:10 <ais523> …curious that it's only a warning, though
16:48:14 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117398&oldid=117397 * Infinitehexagon * (+40)
16:48:52 <ais523> oh, because it might be dead code, and type errors happen at runtime not compile time in Python!
16:49:06 <Europe2048> Let's stop talking about implementing my language.
16:49:07 <ais523> so erroring at compile time would violate the spec
16:50:35 <ais523> yep, «if False: 0()» gives a SyntaxWarning but runs without issue
16:50:38 <esolangs> [[Alpha]] https://esolangs.org/w/index.php?diff=117399&oldid=117398 * Infinitehexagon * (+38)
16:51:29 <ais523> I really don't know Python that well, partly because a) I don't like it very much and b) I know Perl very well, meaning that I rarely have an incentive to use Python for anything
16:51:36 <ais523> (other than dealing with existing code that's already written in Python)
16:52:04 <wib_jonas> wait, do you *still* know Perl very well, even the changes from the last ten years or so?
16:52:53 <ais523> wib_jonas: not as well as I used to, although I've been catching up to some extent recently
16:53:11 <ais523> part of the problem is that the static analysis tool I have hooked up to my editor isn't so great at modern Perl
16:54:17 <ais523> …also it mislead me recently, I had a function that actually did need to "return undef;" (which is normally a classic Perl mistake), I managed to silence the warning with "return (undef);" instead
16:55:26 <esolangs> [[User:Europe2048]] M https://esolangs.org/w/index.php?diff=117400&oldid=117237 * Europe2048 * (+20)
16:56:18 <wib_jonas> I don't understand, why is that misleading?
16:56:48 <ais523> wib_jonas: because linters shout at you when you do it and thus you assume your code is wrong, when actually you got it right first time
16:57:15 <ais523> I think all this stems from the usual ambiguity about what null, undef and friends actually mean
16:58:19 <ais523> when undef represents the lack of valid data, it should become () in list context; but when it represents one valid datum (that itself represents the lack of valid data), it should become (undef) in list context
16:59:13 <ais523> the former is more common, but in this case I waned the latter
16:59:26 <wib_jonas> .oO( see NONE vs None1 recently on the esowiki)
17:00:53 <wib_jonas> and you could be explicit about it and write `return scalar();` but then that might confuse readers who don't know all the rules of perl because they'll that that means `return scalar($_);`
17:01:27 <ais523> or «return scalar(())» which is 0 I think?
17:02:16 <ais523> is there an easier way to pass a 0-element list to «scalar» than «scalar(@{[]})»?
17:03:28 <ais523> ah right, (0,1,2) parses as a comma expression in scalar context, not a list literal, so you really do need @{[…]} to force list context
17:03:48 <wib_jonas> that question doesn't literally make sense, but for what you want, perhaps `scalar(my@k)` or, if you're golfing, `scalar(my@~)`
17:04:09 <ais523> wib_jonas: I most commonly use «scalar» to get at the length of an array
17:04:34 <wib_jonas> you can, but that's what the 0+ grenade is for
17:05:21 <ais523> if you're golfing, «scalar(@_)» (outside a function) :-)
17:05:39 <ais523> pick a variable that doesn't need to be declared
17:07:00 <ais523> (or, well, if you're golfing normally you don't turn strict mode on, so that you don't need to declare anything)
17:07:04 <wib_jonas> `perl -weuse strict; print "A=", scalar(@~);
17:07:10 <wib_jonas> `perl -weuse strict; print "A=", scalar(@k);
17:07:12 <HackEso> Global symbol "@k" requires explicit package name (did you forget to declare "my @k"?) at -e line 1. \ Execution of -e aborted due to compilation errors.
17:07:32 <wib_jonas> punctuation variables are implicitly in main:: regardless your current package, and don't need to be declared
17:08:25 <wib_jonas> the drawback is that most punctuation variables with @ sigil don't get recognized as an interpolation in a string-like literal, only with a $ sigil
17:08:37 <wib_jonas> but in your case with scalar that's not a problem
17:09:27 <ais523> I don't commonly interpret arrays into strings anyway, unless I badly need to use $" as the separator rather than $,
17:11:02 <ais523> actually, more recently I've generally been doing the commas "by hand" – probably influence from all the Rust programming I've been doing
17:12:44 <wib_jonas> perl's syntax rules are arcane and I may have misrepresented them above by the way
17:16:37 <ais523> BEGIN{} is possibly one of the hardest-to-implement constructs in any practically used language, which is impressive given how innocent it initially looks (and given that there's an END{} which is apparently symmetrical but actually not)
17:17:41 -!- wib_jonas has quit (Quit: Client closed).
17:20:35 <ais523> Europe2048: really we should have a guide on how to implement esolangs, but I'm not sure whether there's anyone who'd be in an appropriate place to write it
17:20:46 <ais523> it is normally easier than implementing non-esoteric programming languages
17:21:22 <Europe2048> Yeah, non-esolangs are much more complex than esolangs.
17:21:38 <Europe2048> Take, for example, Python and LOLCODE.
17:21:56 <ais523> LOLCODE is basically a simple practical language with swapped-out keywords
17:54:28 -!- chiselfuse has quit (Remote host closed the connection).
17:54:43 -!- chiselfuse has joined.
19:02:43 -!- cpressey88 has joined.
19:06:23 -!- cpressey has quit (Ping timeout: 245 seconds).
19:07:00 <b_jonas> yeah, I don't think there's much to say about how to implement esolangs in general that doesn't apply to implementing any programming language. if the esolang is hard to implement with traditional techniques, that's because it has some unique twist that is specific to that one esolang and so you the writer of that esolang-implementation book won't predict it.
19:10:53 -!- cpressey88 has changed nick to cpressey.
19:11:11 -!- Thelie has quit (Quit: Leaving.).
19:15:39 <cpressey> ais523: I differ from your position on seperate lexing. A seperate lexer is exactly what makes "0.0" unambiguously a float. The idea of "oh how can I can disambiguate this from someone trying to access the field "0" of the integer "0" doesn't even come up. I consider this a good thing.
19:20:03 <b_jonas> cpressey: yeah, but in modern C++, the lexer has a bunch of exceptions, and at least one exception to an exception, in how to lex certain digraphs. they aren't about that particular case, but still
19:20:51 <b_jonas> (and ruby's lexer and parser handily beats that in its odd rules and exceptions and exceptions to exceptions and whitespace-dependence)
19:21:01 <zzo38> I also think that since there is no field "0" of integer "0", that it makes sense. However, in C the /* for beginning of comments is like two tokens that would be able to go together, so that is not as sense.
19:21:21 <b_jonas> (though I think for ruby it's only at parsing stage, not the lexing stage)
19:28:53 <b_jonas> C comments remind me. many languages that have a nontrivial lexer or parser have their parsing rules defined such that they're easy to parse when you read the input string forward, but may be hard if you read it backwards. C comments are like this: if you have a long file with lots of instances of `/*/` and a `/**/` at the end but no other instances of `*/` then, if you read backwards, you won't know
19:28:59 <b_jonas> which parts of the file are comments and which aren't, each `/*/` flips them back and forth, you only find out which ones were comments when you reach the beginning of the file and find out the parity of the `/*/` markers.
19:30:12 <b_jonas> (this gets worse with modern C++ R-strings)
19:30:29 <b_jonas> so my question is, what languages do you know of that are easier to parse when you read the string backwards?
19:35:07 -!- Europe2048 has quit (Quit: Client closed).
19:38:03 -!- cpressey has quit (Ping timeout: 245 seconds).
19:41:42 -!- cpressey has joined.
19:44:33 -!- Europe2048 has joined.
19:48:38 -!- arseniiv has quit (Quit: gone too far).
19:52:01 <zzo38> I don't know of any that are easier backward, at least, that I can think of right now. Do you know?
19:56:18 <b_jonas> I have one candidate that may be easier
19:56:30 <zzo38> (Although, I think there are some where you might have to search backward to find an ending delimiter of something)
19:58:12 <b_jonas> the lexer of lojban the constructed language (not programming) is easier backwards, on two counts
19:58:21 <ais523> cpressey: I don't think that argument changes my mind – the separate lexer is in effect making an arbitrary decision, and even though that decision is correct this time, it could easily be incorrect in other cases
19:58:36 <ais523> having a combined parser and lexer means that you become aware that the case exists, and can choose how to resolve it
19:59:14 <ais523> b_jonas: I think yacc's grammar is LR(1) backwards but LR(2) forwards
19:59:45 -!- Europe2048 has quit (Quit: Client closed).
20:00:40 <ais523> (assuming a separate lexer, and that the lexer doesn't have a special case for "identifier followed by colon" – that special case is a hack used to get yacc to be able to parse itself)
20:01:36 <b_jonas> the lexer rules are defined such that you can find the boundaries of words in spoken lojban, where the speaker doesn't usually pause between every pair of words, from the sequence of phonemes, assuming you can also distinguish stressed vowels and hear the rare mandatory pauses
20:04:43 -!- cpressey has quit (Quit: Client closed).
20:05:11 <b_jonas> there are three common kinds of tokens (words) in lojban: grammar words which are short, substance words, and names. names end with a consonant followed by a mandatory pause, so it's easy to find their end, and you search backwards for some substrings to find the start. in substance words the syllable before the last is stressed but other syllables aren't stressed, so it's easy to find the end of the
20:05:17 <b_jonas> word. each substance word has two adjacent consonants as either its first or second consonant cluster, and grammar words are always single syllables with no adjacent consonants. so once you cut at pauses and after syllables following a stressed syllable, you have chunks that are made of a number of grammar words followed by a substance word, and from the first consonant cluster you can *almost* tell
20:05:23 <b_jonas> where the substance word starts, but that can leave two possibilities for the boundary.
20:06:35 <b_jonas> there is a nice but kind of hard to understand set of lexer rules that always disambiguate between those two possibilities, and it's a regular language too so in theory it's easy either forwards or backwards, but I find that in practice it's easier to understand backwards.
20:09:19 -!- Franciman has joined.
20:09:35 <b_jonas> you need in theory unbounded lookahead forwards for the lexing, though of course in practice very long words will be hard to understand anyway so they won't occur often regardless of this disambiguation problem
20:10:01 <b_jonas> ais523: that's a nice example
20:10:15 -!- Franciman has left.
20:11:42 <b_jonas> fizzie: in the HTML render of the channel logs, for a TOPIC message, the render puts a sentence ending period right after the topic, which is confusing because the topic often ends in an URL. I wonder if we should do something about that.
20:12:03 <b_jonas> like put a space before the period for example
20:12:21 <b_jonas> uh, full stop. that's what people call a sentence-ending period.
20:15:09 <b_jonas> ais523: I guess if you're used to LL and LR parsers then you could even say that your basic RPN calculator language is easier to parse backwards, which is ironic because RPN syntax was designed because it's easy to interpret when read forwards
20:21:20 -!- cpressey has joined.
20:25:28 -!- Europe2048 has joined.
20:25:35 -!- Europe2048 has left.
20:25:38 -!- Europe2048 has joined.
20:25:58 <b_jonas> fungot: when you return, will you logread and answer all our questions from when you were away?
20:27:42 <b_jonas> Europe2048: this channel is logged, so fungot will in theory be able to read what people had said earlier
20:30:13 <cpressey> ais523: Well, I'm not trying to change anyone's mind. When I have a hand-coded parser I almost always use a seperate lexer. (I once had an esolang where the lexer's rules could be changed dynamically, btw.) But, when I write in Haskell I use parsec, and having it use a seperate lexer is more hassle than it's worth. But I usually miss it, to
20:30:13 <cpressey> some degree, as it forces me to think about whitespace and such in all the places where I normally wouldn't.
20:34:38 <b_jonas> I have recently (in the last three years) written two different simple parsers for my dayjob, both in python, and they both have a separate lexer. One is just a tab-separated csv parser, where fields can be quoted with double-quotes in which case crs and lfs and tabs in the quoted part aren't special, and doubled double quotes represent a single double quote. so the lexer finds double-quoted fields,
20:34:44 <b_jonas> unquoted fields, unquoted tabs, unquoted newlines. then the parser acts turns this to a table (with possibly header lines), or a sequence of such tables separated by blank lines.
20:36:42 <cpressey> One of the 'orrible things about parsing in the stone age of FORTRAN and BASIC was that space was at such a premium that Every Byte was Sacred, so puttingtokenstogetherwithnointerveningwhitespaceorsymbols was a thing. That is something that we can luckily afford to avoid now.
20:37:27 <b_jonas> The other parses a custom line-oriented format, one for which I made the other end that writes it too. I designed quoted strings sensibly for this so I don't have to deal with the mess of quoted or unquoted newlines or separators. So the source file is line-oriented, newlines always separate lines, \x1F always ends a string, and you quote a control character as \x10 followed by the control character
20:37:33 <b_jonas> xored with \x20, plus there's a special abbreviation to quote crlfs as \x11 because they're common in the strings that I want to quote.
20:40:14 <b_jonas> The lexer still has to tokenize the line to various tokens, which it just does left to right with a simple regex. And then the parser takes the first word of the line, which tells what kind of line it is, and handles it accordingly to put most of the data in some custom objects (and ignore the rest), and calls some callback functions so in theory I can parse files without keeping the whole structure in
20:40:20 <b_jonas> memory (this is currently unnecessary, I could easily have the whole structure in memory without problems, but it doesn't cost much to plan ahead).
20:43:42 -!- cpressey96 has joined.
20:46:48 -!- cpressey has quit (Ping timeout: 245 seconds).
20:47:05 <ais523> cpressey96: some early BASIC interpreters stored the parse tree rather than the text, I think
20:47:11 <ais523> and pretty-printed it when you asked for a program listing
20:47:35 <ais523> presumably the parse tree either a) was smaller or b) needed to be stored anyway
20:48:28 -!- cpressey96 has quit (Ping timeout: 245 seconds).
20:49:22 -!- cpressey has joined.
20:54:11 -!- cpressey has quit (Client Quit).
20:56:13 <b_jonas> ais523: really? I believe they stored a *lexed* string, encoding keywords in a consistent easy to parse way, and so printed the listing with canonical form of tokens and whitespace. the tokens are encoded as one or two bytes for compactness. still other interpreters already *input* keywords differently from ordinary identifiers, so you can't type PRINT or COS as its sequence of letters, you have to use
20:56:19 <b_jonas> a possibly shifted key combination for them. I think this was also used for algol besides basic.
20:57:52 <esolangs> [[Special:Log/newusers]] create * Thatgaypigeon * New user account
21:00:58 -!- cpressey has joined.
21:01:52 <b_jonas> my Sharp EL-5120 calculator is of the latter kind. all keywords are stored as just one byte, even though they can take up up to six character cells on screen. ABS looks like the letters A B S followed by a space, but if you enter them that way they won't mean the ABS function.
21:02:30 <b_jonas> representing keywords as one byte makes sense of course because the hardware is limited: slow CPU and just 20 kilobytes of RAM
21:06:58 * cpressey is more than passingly familiar with the [de]tokenization of Commodore BASIC 2.0 programs
21:07:12 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=117401&oldid=117371 * Thatgaypigeon * (+314)
21:08:01 <b_jonas> cpressey: what machine is that basic used on?
21:08:01 <esolangs> [[User:Thatgaypigeon]] N https://esolangs.org/w/index.php?oldid=117402 * Thatgaypigeon * (+29) Created page with "''Nothing to see here... :p''"
21:08:08 * cpressey wonders if that dynamically-change-the-lexing-rules gimmick would be worth resurrecting into a new esolang
21:09:18 <ais523> b_jonas: oh, storing it lexed rather than parsed is possible – it's hard to tell as a user
21:09:24 <cpressey> b_jonas: At least the VIC-20 and the Commodore 64, possibly other Commodore computers.
21:09:52 <b_jonas> cpressey: I assume you don't count C where the parser needs to know if an identifier is a type for making the parse tree; or prolog where you can declare any ordinary identifier to be parsed as an infix operator from now
21:11:07 <ais523> hmm, I thought the most vexing parse was C++-specific; is there a C version of it?
21:11:43 <cpressey> b_jonas: I may be confused - surely the *lexer* doesn't need to know the type of anything in C?
21:13:04 <ais523> cpressey: I think it's sort-of backwards, the parser needs to know what's been declared as a type which means that the lexer has to work it out so that it can tell the parser
21:13:18 <cpressey> Being able to define infix operators is of course a handy thing, but that too is mostly in the parser; to the lexer the identifier is still an identifier
21:13:46 <ais523> C-INTERCAL has lexing rules for pretty much any possible infix operator, including ones that don't exist, in case it ends up getting defined at runtime
21:14:06 <ais523> I have no idea if this is the usual way to handle runtime-defined syntax, but it seemed esoteric enough
21:14:53 <b_jonas> cpressey: the lexer doesn't need to know to separate words, but there has to be a layer above the lexer but below the LR-parser or similar that changes identifier tokens to one of two different tokens, as in type name or normal identifier (more than two for C++).
21:15:46 <b_jonas> and prolog is similar, you can tokenize the input without such tricks, but then between the tokenizer and the parser you have to tell which identifiers are infix operators (and their precedence and fixity)
21:16:32 <cpressey> You can regard this logic as "between the lexer and the parser" if you like; I see it as part of the parser; at any rate there is nothing requiring you to see it as part of the lexer
21:16:57 <ais523> in OCaml, the precedence and fixity of a user-defined operator is based on its first character
21:17:19 <ais523> which is a clever fix to this sort of problem
21:17:46 <b_jonas> I think FORTH has a different trick: it has identifiers that are executed right after they're lexed, so you can define a token so that the part of the source code after that has a custom lexical syntax instead of using the normal lexer, and this is how the " comment marker is implemented, it just reads characters and ignores them until it finds a terminating "
21:17:56 <b_jonas> nut I don't use FORTH much so I may be wrong here
21:17:59 <ais523> (and also makes programs easier to read, you can see an operator you don't recognise whose name starts with «>» and still be able to mentally parse it because you know how the «>» operator parses)
21:19:22 <cpressey> For dynamically changing the lexing rules in an esolang, I was thinking that (unlike in Bear Food, my old esolang) this facility should be used in some non-gratuitous way. i.e. you have to change the lexing rules, in order to... perform conditionals or something.
21:19:30 <fizzie> b_jonas: I don't know if it could just omit the full stop. I mean, it's maybe a little inconsistent with the other lines, but the colon kind of serves the purpose of delimiting the fixed part, and it's not that unreasonable to expect everything after the colon is just literal.
21:19:34 <fizzie> Alternatively, I could format it the same way quit messages are formatted. "X has quit (foo)." "X has set the topic (bar)."
21:20:29 <b_jonas> also J has the colon conjunction which, if its right argument is the number 0 (for example like 0 :0), will read lines from the same input as the source code so they aren't parsed like normal source code lines, and while usually you use this in a static way like bash here documents, you can invoke it at runtime conditionally or in a loop if you want
21:20:53 <ais523> cpressey: did you see Advance The Wheel!
21:20:58 <b_jonas> fizzie: I'm fine with omitting the full stop
21:20:59 <ais523> it's not quite the same, but you reminded me of it
21:21:20 <ais523> (it's a turning tarpit, but conditionals affect the wheel rather than the instruction pointer, meaning that the same commands run but are interpreted differently)
21:21:26 <b_jonas> cpressey: also I think perl6 was planned to have a crazy dynamic lexer and parser where you can define syntax at runtime in ways that make me (and probably ais) shudder
21:21:35 <b_jonas> but I don't know how much of that ever got implemented
21:22:00 -!- Europe2048 has left.
21:22:00 <fizzie> I am not sure how I'm going to remember to make that happen the next time I do some changes. I was also supposed to update the HTTP server library to see if it would let me re-enable stalker mode without it hanging up.
21:22:12 <ais523> b_jonas: Perl 6 regex is basically a full-on context-free language parser, but I think it's implemented by backtracking
21:22:32 <ais523> but it wouldn't surprise me if the interpreter was supposed to parse itself with regex that could be changed at runtime
21:23:46 <cpressey> I'll have to look at Advance The Wheel but for now I've got to call it a night
21:24:00 <b_jonas> fizzie: parenthesis around the topic don't help, it joins the URL just as much as the period does
21:35:54 -!- __monty__ has quit (Quit: leaving).
21:36:05 <b_jonas> cpressey: oh, and TeX has runtime definable lexer, but only in as much as it has a table of the 256 bytes and you can assign each one to one of, I think, 17 possible built-in categories
21:36:25 <b_jonas> you can't define new lexing rules or anything, just say which character is which kind
21:37:49 <b_jonas> and the categories are actually changed during runtime in a few cases
21:39:35 <b_jonas> I presume you're not interested in cases where the lexer just has a small fixed number of modes with similar but slightly different lexing modes, and you can switch between those modes dynamically, like bash in which (shopt -s extglob) changes how round parenthesis are lexed in some cases, but only starting from the next line
21:40:58 <b_jonas> (and this is dynamic because you can run shopt programmatically so the lexer can't tell from just lexing when it will be called)
21:45:34 <Noisytoot> fizzie: How quit messages are formatted varies by client. In the protocol, they're formatted as ":X!user@host QUIT :foo"
21:46:29 <fizzie> Yes, but I meant on the logs website.
21:48:29 <b_jonas> Noisytoot: what fizzie says, I specifically asked about the html renders on his log wibsite
21:56:33 -!- Melvar has quit (Quit: WeeChat 4.0.4).
22:04:38 -!- Melvar has joined.
22:12:20 <zzo38> In PostScript you can't change the lexer but you can read from currentfile (which is the file containing the program), so that can make syntax highlighting difficult sometimes.
22:13:19 <zzo38> Is there regular expression library that you can use units other than bytes and Unicode?
22:14:07 <b_jonas> oh right, TeX can also read lines from its source file, can't it?
22:15:10 <zzo38> I don't think so (other than by opening it as a separate file), although you can change the catcodes in TeX
22:16:46 <b_jonas> zzo38: I think the C++ standard's regex library can use user-defined character types. there are serious restrictions on what such a type can be like, but I believe it can at least be bigger than what holds a unicode character.
22:18:59 <b_jonas> zzo38: any fixed size, it's a C++ template. I think it has to be trivially copiable and stuff like that so it can't own memory on heap, but I'm not sure about the details, you'll have to ask #C++ to be sure
22:20:14 <b_jonas> zzo38: https://en.cppreference.com/w/cpp/regex/regex_traits describes the details, but I never looked at what that does because I don't think I'll ever define custom character types
22:24:14 <b_jonas> also I think perl regexen supports UTF8-E or something similar, I don't know if you'd count that as unicode
22:26:48 <b_jonas> hmm, I wonder if that's true
22:27:30 <zzo38> Well, even if it is true, it means it is limited to the size and requires converting to UTF-8 if it is not already, anyways
22:27:42 <Melvar> regex-applicative (a Haskell library) has the symbol type as a type parameter. You can use an arbitrary predicate to build a one-symbol matcher so there’s no real constraint on what can be used for the symbol type.
22:28:03 -!- cpressey has quit (Ping timeout: 245 seconds).
22:30:42 <zzo38> Due to the document about a finite automaton before, I had considered you could also use an arbitrary monoid, although actually implementing such a thing may be difficult in the general case other than a free monoid.
22:32:00 <b_jonas> zzo38: UTF-8 and UTF8-E are self-synchronizing so the regex implementation can mostly just use a byte string matcher, except when unicode character properties or unicode case sensitivity is used.
22:33:54 <zzo38> Yes, I know UTF-8 has that property that you can easily use that, although you might want to define your own properties and macros, and like I said you might not want UTF-8 anyways since the data might be in a different format
22:36:11 <b_jonas> sure, but I can't really imagine how supporting arbitrary formats could work, so byte-based and utf16-based is what you have, plus C++'s crazy library
22:37:34 <b_jonas> oh, and ucs32-based, I think python can match ucs32 though probably only limited to the 21 bits of modern unicode
22:39:11 <zzo38> Most likely the units would be some integer, e.g. 8-bits, 16-bits, 32-bits, or 64-bits; you probably won't need more than that, although external procedures for matching might sometimes be needed (which is possible with PCRE, anyways), and some kind of syntax to be able to work such a thing (perhaps including macros, e.g. if it is UTF-8) might be of use
22:41:26 <b_jonas> right. existing libraries can already do 8-bit and 16-bit, with basically character sets except that the few dozen characters special for regex syntax will be interpreted as ascii. the C++ regex library can do 32-bit or 64-bit.
22:42:00 <b_jonas> and any byte-based matcher can do 31 bits or 63 bits if you encode the string as UTF8-G or UTF8-E respectively
22:43:29 <b_jonas> if you want something fancier then you'll probably have to study the research paper and implementation of TRE https://laurikari.net/tre/ and then write your own regex matcher
22:46:12 <b_jonas> although there might be something for the legacy japanese encodings, you'll have to ask the ruby folks if they have a regex matcher for that
23:03:46 -!- Koen has quit (Quit: Leaving...).
23:20:39 -!- Sgeo has joined.
23:24:13 -!- FreeFull has quit.
23:25:36 -!- user3456 has quit (Ping timeout: 260 seconds).