00:06:47 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=144818&oldid=144774 * Yuroyumachi * (+161)
00:13:32 <int-e> . o O ( lacol knil prefix = 0:80fe::/32 )
00:14:47 <int-e> (based on a report in german that sees a provider reply to DHCPv6 requests from that subnet, in german: https://hilfe.o2online.de/dsl-kabel-glasfaser-router-software-internet-telefonie-34/dsl-ipv6-pd-dhcpv6-eventueller-fehler-seitens-o2-640621 )
00:16:18 <ais523> you can reply to a DHCP request in German?
00:16:38 <int-e> I don't see why not
00:16:46 <ais523> I guess it would be possible to reply to an HTTP request in German (at the expense of the browser not being able to understand the headers), maybe DHCP works the same way
00:17:44 <int-e> I wrote "in german" twice because the second one was an afterthought while editing on an 80 character wide text prompt in irssi
00:18:31 <int-e> it's but one of many dangers on the internet ;)
00:24:52 <int-e> (The best part of that exchange is the person who says that 0:80fe::/6 should be 0:80fe::/16 instead. Counting is hard.)
00:30:59 <int-e> `learn The password of the month is release incident pilot.
00:31:02 <HackEso> Relearned 'password': The password of the month is release incident pilot.
00:45:57 <esolangs> [[User:Yuroyumachi]] N https://esolangs.org/w/index.php?oldid=144819 * Yuroyumachi * (+116) I love you;)
00:46:57 <esolangs> [[User talk:Yuroyumachi]] N https://esolangs.org/w/index.php?oldid=144820 * Yuroyumachi * (+96) Created page with "--~~~~"
01:42:59 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).
02:21:27 <b_jonas> Guest67: also https://esolangs.org/w/api.php with docs at https://www.mediawiki.org/wiki/API:Main_page ; or https://esolangs.org/wiki/Special:Export
03:05:01 -!- op_4 has quit (Remote host closed the connection).
03:05:32 -!- op_4 has joined.
04:21:41 -!- craigo has quit (Quit: Leaving).
04:33:40 -!- Guest60 has joined.
04:40:35 -!- Guest60 has quit (Quit: Client closed).
04:44:18 -!- X-Scale has joined.
04:52:19 <esolangs> [[User talk:/w/wiki/index.php/Talk:index.php/Main page]] https://esolangs.org/w/index.php?diff=144821&oldid=143524 * PrySigneToFry * (+50)
04:55:14 <esolangs> [[Basilisk]] https://esolangs.org/w/index.php?diff=144822&oldid=92844 * PrySigneToFry * (+313)
05:18:51 -!- wWwwW has joined.
05:45:27 <wWwwW> im done with my prototype compiler! korvo
05:51:57 <wWwwW> https://collab.pi7.org/GamePlayCodeLife
05:53:01 <wWwwW> and it doesnt work. wtf it should
06:01:47 <wWwwW> hey do you know why
06:06:01 <korvo> wWwwW: Fun. Looks like a 2D system.
06:17:03 -!- ais523 has quit (Ping timeout: 245 seconds).
06:20:43 <wWwwW> also ais523 made any progress on the L0 idea?
06:34:27 -!- X-Scale has quit (Ping timeout: 256 seconds).
06:37:38 -!- tromp has joined.
06:42:14 <wWwwW> i can get my interpreter to work so i give up
06:48:06 -!- X-Scale has joined.
07:46:28 -!- Lord_of_Life_ has joined.
07:47:48 -!- Lord_of_Life has quit (Ping timeout: 276 seconds).
07:47:49 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
08:07:45 -!- X-Scale has quit (Quit: Client closed).
08:22:34 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
08:24:26 <wWwwW> god i have the best and worst idea for an esolang
08:28:16 <esolangs> [[Sucks]] https://esolangs.org/w/index.php?diff=144823&oldid=144713 * ChuckEsoteric08 * (+21) /* Short form */
08:46:40 <esolangs> [[Talk:Macro]] https://esolangs.org/w/index.php?diff=144824&oldid=140802 * Yayimhere * (+89)
08:57:30 <esolangs> [[User talk:/w/wiki/index.php/Talk:index.php/Main page]] https://esolangs.org/w/index.php?diff=144825&oldid=144821 * Ractangle * (-9)
08:59:29 <esolangs> [[Pycone]] https://esolangs.org/w/index.php?diff=144826&oldid=144817 * Ractangle * (+0) /* Truth-machine */
08:59:44 <esolangs> [[Pycone]] https://esolangs.org/w/index.php?diff=144827&oldid=144826 * Ractangle * (+0) /* Truth-machine */
09:46:18 -!- Noisytoot has quit (Ping timeout: 246 seconds).
09:58:32 <esolangs> [['Python' is not recognized as an internal or external command, operable program or batch file.]] https://esolangs.org/w/index.php?diff=144828&oldid=144177 * Ractangle * (+29) /* CATEGORIES */
10:11:52 <esolangs> [[Pycone]] https://esolangs.org/w/index.php?diff=144829&oldid=144827 * Ractangle * (+0) /* Truth-machine */
11:05:35 <esolangs> [[Talk:'Python' is not recognized as an internal or external command, operable program or batch file.]] https://esolangs.org/w/index.php?diff=144830&oldid=143384 * Ractangle * (+180)
11:28:56 <esolangs> [['Python' is not recognized]] N https://esolangs.org/w/index.php?oldid=144831 * Ractangle * (+437) Created page with "''''Python' is not recognized''' is a variant of [['Python' is not recognized as an internal or external command, operable program or batch file.]] by [[User:Ractangle]] ==Syntax== {{cd|;}} stops the program since the code is a one-liner {{cd|:}} ta
11:41:07 -!- Sgeo has quit (Read error: Connection reset by peer).
11:55:05 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144832&oldid=144831 * Ractangle * (-23) /* Syntax */
11:57:28 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144833&oldid=144832 * Ractangle * (+142) /* Syntax */
11:57:42 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144834&oldid=144833 * Ractangle * (-5) /* Syntax */
11:59:02 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144835&oldid=144834 * Ractangle * (+109) /* Syntax */
12:01:17 <esolangs> [[User:Ractangle]] https://esolangs.org/w/index.php?diff=144836&oldid=144376 * Ractangle * (-327) /* Programm forms */
12:01:56 -!- leah2 has quit (Ping timeout: 255 seconds).
12:02:13 <esolangs> [[User:Ractangle]] https://esolangs.org/w/index.php?diff=144837&oldid=144836 * Ractangle * (-166) /* Esolangs */
12:02:53 -!- leah2 has joined.
12:03:57 <esolangs> [[User:Ractangle]] https://esolangs.org/w/index.php?diff=144838&oldid=144837 * Ractangle * (+3)
12:04:15 <esolangs> [[User:Ractangle]] https://esolangs.org/w/index.php?diff=144839&oldid=144838 * Ractangle * (-1) /* Esolangs */
12:06:13 <esolangs> [[User:Ractangle]] https://esolangs.org/w/index.php?diff=144840&oldid=144839 * Ractangle * (-3)
12:06:45 <esolangs> [[User:Ractangle]] https://esolangs.org/w/index.php?diff=144841&oldid=144840 * Ractangle * (-28) /* Esolangs */
12:07:04 <esolangs> [[None,]] https://esolangs.org/w/index.php?diff=144842&oldid=135864 * Ractangle * (-118)
12:09:52 -!- tromp has joined.
12:10:10 -!- tromp has quit (Read error: Connection reset by peer).
12:16:09 -!- wWwwW has quit (Quit: Client closed).
12:27:56 <esolangs> [[User:ATProtogen/Sandbox]] M https://esolangs.org/w/index.php?diff=144843&oldid=143966 * ATProtogen * (-3540) Blanked the page
13:13:30 <esolangs> [[Joke Page]] M https://esolangs.org/w/index.php?diff=144844&oldid=116188 * None1 * (+42) /* Examples */
13:43:14 -!- X-Scale has joined.
13:47:02 -!- Everything has joined.
13:52:34 -!- leah2 has quit (Ping timeout: 260 seconds).
14:15:32 -!- Noisytoot has joined.
14:26:22 -!- Thelie has joined.
14:35:50 -!- leah2 has joined.
15:17:49 -!- FreeFull has quit.
15:28:09 -!- FreeFull has joined.
15:35:03 -!- X-Scale has quit (Ping timeout: 256 seconds).
15:46:37 -!- lynndotpy has quit (Quit: bye bye).
15:47:13 -!- X-Scale has joined.
15:47:31 -!- lynndotpy has joined.
15:55:13 -!- tromp has joined.
16:04:31 -!- X-Scale has quit (Ping timeout: 256 seconds).
16:04:53 <esolangs> [[FlipFlop]] https://esolangs.org/w/index.php?diff=144845&oldid=144241 * Ractangle * (-257) better implementation
16:05:11 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:06:21 <esolangs> [[FlipFlop]] https://esolangs.org/w/index.php?diff=144846&oldid=144845 * Ractangle * (+6) /* Implementation */
16:10:21 <esolangs> [[FlipFlop]] https://esolangs.org/w/index.php?diff=144847&oldid=144846 * Ractangle * (+55) /* Examples? */
16:13:44 <esolangs> [[+++]] https://esolangs.org/w/index.php?diff=144848&oldid=144352 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+3) /* Calculator */
16:15:12 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144849&oldid=144835 * Ractangle * (+23)
16:17:14 <esolangs> [[Deadfish with gotos and input]] https://esolangs.org/w/index.php?diff=144850&oldid=142071 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+297) /* Programs */
16:20:33 <esolangs> [[Deadfish with gotos and input]] https://esolangs.org/w/index.php?diff=144851&oldid=144850 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (-45) /* Hello, World! */
16:21:32 <esolangs> [[Deadfish with gotos and input]] https://esolangs.org/w/index.php?diff=144852&oldid=144851 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (+0) /* Hello, World! */
16:21:42 <esolangs> [[Deadfish with gotos and input]] https://esolangs.org/w/index.php?diff=144853&oldid=144852 * Fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff * (-1) /* Hello, World! */
16:21:46 -!- wWwwW has joined.
16:22:02 -!- X-Scale has joined.
16:30:21 -!- tromp has joined.
16:53:38 -!- Everything has quit (Ping timeout: 248 seconds).
16:55:30 -!- Everything has joined.
16:59:05 -!- Thelie has quit (Quit: Leaving.).
16:59:59 -!- Thelie has joined.
17:10:49 -!- wWwwW has quit (Ping timeout: 256 seconds).
17:11:30 -!- wWwwW has joined.
17:13:39 <wWwwW> somebody throw a concept at me im so bored i want to make it into an esolang
17:15:47 <korvo> Give Lojban some semantics. Or pick another loglang. Or another englang. Or another auxlang.
17:16:01 <korvo> Warning: it could take more than a day.
17:16:30 <korvo> I've been working on it for like 5yrs and I'm only about 15% done.
17:17:01 <korvo> Meh. I should be done before I die.
17:17:11 <wWwwW> then no thx im like idk lol'
17:17:43 <korvo> Suit yourself. Some folks are even more ambitious; I don't think Knuth will finish his books before he dies.
17:18:34 -!- ais523 has joined.
17:20:32 -!- Noisytoot has quit (Ping timeout: 272 seconds).
17:21:06 <wWwwW> any progress on L0?
17:22:08 <int-e> wWwwW: most of the links on https://esolangs.org/wiki/User:Yayimhere#esolangs represents an opportunity to improve the page, adding an interpreter and working examples. And probably modifications to the languages to make them actually do something. For example, https://esolangs.org/wiki/Leadfish has no way to grow the stack.
17:22:20 <ais523> wWwwW: you mean 0L? no, I was focusing on something else
17:22:44 <ais523> sometimes I have hobbies other than esolangs
17:23:22 <wWwwW> int-e for interpterers im stupid, and mostly rn ik want to make smth
17:41:39 <wWwwW> gimme a concept plz
17:42:34 <ais523> wWwwW: so over the last couple of weeks I have been trying to implement a terminal
17:42:43 <ais523> I don't think terminal control codes are TC but there are some interesting things they can do
17:42:58 <wWwwW> yes and? thats it?
17:43:23 <ais523> it's the sort of thing where I think "so what is the computational power of this?", but it's hard to tell because the standards are hard to read
17:43:33 <ais523> and nobody seems to implement them properly anyway
17:45:16 <ais523> anyway, that's the sort of thing that sometimes inspires an esolang, although it didn't with me
17:45:25 <esolangs> [[JS-CODE]] https://esolangs.org/w/index.php?diff=144854&oldid=136902 * Ractangle * (-5) Removed redirect to [[Waretel BASIC]]
17:45:33 <int-e> wWwwW: but why are you designing programming languages if you can't program :-/
17:45:43 <ais523> I think it did with someone else, there was a serious attempt to use terminal control codes as a portable format for representing word-processed documents, but it didn't catch on
17:45:45 <esolangs> [[User:Ractangle/Sandbox]] https://esolangs.org/w/index.php?diff=144855&oldid=144228 * Ractangle * (+70)
17:45:52 <wWwwW> never get my interpteters to work
17:48:39 <int-e> Start with something simpler? I dunno, do a naive Game of Life implementation. You basically don't need parsing, just loops and arrays.
17:49:05 <wWwwW> its to the level were it makes no sense for it to not work
17:49:14 <int-e> Brainfuck is a nice target for very basic parsing (you need to match brackets)
17:49:28 <esolangs> [[User:Ractangle/Sandbox]] https://esolangs.org/w/index.php?diff=144856&oldid=144855 * Ractangle * (+10) /* Stuff to continue */
17:49:35 <wWwwW> idk how to do parsing and i never like
17:49:37 <wWwwW> it just never works
17:49:54 <int-e> Sorry but if it never works, then you don't know how to do it.
17:50:03 <ais523> int-e: "idk" means "i don't know" I think
17:50:27 <wWwwW> the other code i do does
17:50:31 <wWwwW> but ionterprters never
17:50:52 <int-e> ais523: Ah I did misread. (But I do know what "idk" means, the mistake was elsewhere, probably skipped a word or two.)
17:50:55 <ais523> I actually hate the way that it's so hard to generate basic parsers in most languages, and the ones where it's easy normally steer you into inefficient and broken ways of doing it
17:51:27 <ais523> this should be a solved problem by now (it was almost a solved problem decades ago, but we seem to have been going backwards since?)
17:51:50 <wWwwW> i only know python for now
17:51:59 <ais523> I have great ideas for improving on it, but not the mental energy to act on them
17:52:23 <esolangs> [[User:Ractangle/Sandbox]] https://esolangs.org/w/index.php?diff=144857&oldid=144856 * Ractangle * (+100) /* Stuff to continue */
17:52:27 -!- wWwwW has quit (Quit: Client closed).
17:52:54 <ais523> like, I think a good easy-to-use parser-generator that integrates directly into the languages people use (without needing a separate build tool), and produces efficient and high-quality parsers with good error messages, would be really valuable
17:53:09 <ais523> right now the common wisdom is to write parsers by hand, which is ridiculous given how good computers should be at doing that
17:54:56 <int-e> It seems that people love parser combinators (despite their efficiency problems)... https://github.com/csams/parsr/blob/master/parsr/examples/arith.py
17:55:19 <int-e> (One of several of those for Python; I haven't used it.)
17:55:26 <ais523> parser combinators are bad in two ways: a) inefficiency, b) if you write an ambiguous grammar they don't notice and will just pick a parse arbitrarily
17:55:41 <ais523> meaning that nothing is automatically catching bugs in your parser
17:55:49 <ais523> or, indeed, in the grammar
17:56:11 <ais523> it is very easy to write an ambiguous grammar by mistake
17:56:43 <ais523> and this is important for programming language creators, when designing their language
17:57:11 <ais523> a parser-generator that verifies there are no ambiguities can be used to help debug your language specification, by ensuring you haven't accidentally created a situation where the same byte sequence means two different things
17:57:30 <ais523> (although ideally to make this work, there shouldn't be a separate lexer, in case there are lexing ambiguities like the whole 0.0 thing in Rust)
17:57:47 <ais523> or the a+++b thing in C
17:57:51 <esolangs> [[User:Ractangle/Sandbox]] https://esolangs.org/w/index.php?diff=144858&oldid=144857 * Ractangle * (+179) /* Stuff to continue */
17:59:03 <ais523> or the Type<Type<Param>> thing in C++, which actually came up quite a lot
17:59:26 <ais523> (I think Rust deals with that one by treating >> as a single token but allowing it to close two nesting levels of generics)
18:00:17 <korvo> Wait, what formalism are people thinking when they say "parser combinators"? I've seen a few. I'm guessing that this is recursive-descent combinators?
18:00:35 <ais523> korvo: normally it's backtracking combinators
18:00:51 <esolangs> [[Special:Log/newusers]] create * Malbolge is NOT enough hard!! * New user account
18:00:54 <korvo> ais523: Sure, those are definitely not efficient.
18:01:27 <ais523> which end up equivalent to recursive-descent if you apply them to an LL grammar, but typically people who use combinators don't care about the various types of grammar
18:02:25 <korvo> Meh. I care plenty about the grammar! But I care even more about getting the parser implemented. And usually there's at least one grammar, the grammar of grammars, which requires a bootstrapping parser.
18:02:32 <ais523> the problem, of course, is that this means that backtracking parser combinators have wildly varying performance characteristics based on something that isn't obvious from the source code, and in many simple cases they do end up fast
18:03:02 <korvo> Like, by the time people start caring about combinators, they've usually seen the bigger problem: writing an informal grammar is easy, but writing a formal grammar that can be mechanically turned into a parser is a PITA.
18:03:07 <ais523> korvo: well, the thing about the bootstrapping parser is that it's always the same, so it can easily be shipped as a library, maybe part of a language's standard library
18:03:23 <korvo> ais523: Yes, but that doesn't solve *my* problems as a language implementor.
18:03:52 <korvo> Like, yes, for everybody else, here is a library I've provided. But what library does Pagliacci use?
18:04:01 <ais523> I've actually started writing such a bootstrapping parser over the past couple of weeks, so that when I have the mental bandwidth to work on my parser-generator I will have a way to bootstrap it
18:04:48 <ais523> (I'm using POSIX yacc for the bootstrapping)
18:04:54 <korvo> I remember seeing ANTLR for the first time and realizing that there are dozens, if not hundreds of us, throwing our heads against this problem and coming back with nothing except RSI.
18:05:37 <ais523> only one person has to do this once – maybe it'll be me when I'm in a better mental state, and then all the language implementors can just use that solution
18:06:10 <ais523> yacc got close, its main issue is that the way it does precedence is overly tied to its own internals
18:06:38 <ais523> also it has no convenient way to do lists, and needs a separate lexer
18:06:46 <korvo> Well, the one person was Ian Piumerta and the one system was OMeta.
18:07:49 <ais523> I still prefer it over things like ANTLR because of the computational complexity (yacc, and Bison on LR grammars, are linear-time; Bison on arbitrary grammars is O(n²) for unambiguous inputs and O(n³) for ambiguous inputs, which I think are the best known computational classes)
18:08:31 <korvo> Sure. So is e.g. Marpa, which claims to merely be a fixed version of Earley's work.
18:08:44 <ais523> hmm, does ANTLR detect ambiguous grammars? (obviously it's uncomputable to determine whether a grammar is ambiguous, but an ambiguity detector with false positives is fine in practice)
18:09:09 <ais523> I've been collecting weird grammars, mostly written myself, as parser generator tests
18:09:34 <ais523> the grammars which are hard to check for ambiguity are very unnatural and don't look like the sort of thing anyone would write in a language spec
18:11:00 <korvo> When Allen Short wrote Parsley (for Python), we realized that Parsley could be extended to tree transformations and wrote about half of SML in it before we realized what had happened. The library Parsimonious, built on Parsley's internals, doesn't have any of that at all.
18:11:13 <ais523> I think it may always be the case that a grammar with uncomputable ambiguity checking always has some substring of input tokens that can be interpreted as opening/closing a different number of nesting levels (or in a different direction) depending on the context
18:11:16 <korvo> Which makes me wonder whether something like Prolog-style grammars were actually a decent option.
18:12:20 <ais523> well, there are good reasons to generate parsers in an inherently linear-time language (like a linear-bounded automaton, but for time rather than memory)
18:12:36 <ais523> I don't think it's possible to implement ML or Prolog in something like that
18:12:45 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:13:47 <ais523> like, to me the problem is not "how do I get a working parser" but "how do I compile this parser description into something that runs in linear time"
18:14:37 <ais523> and that requires trying to find a powerful linear-time language to compile into; something like LR(1) is too restrictive in practice
18:14:53 <ais523> but it's possible to do, say, LR(*) (i.e. LR with regex lookahead) in linear time, which was fun to work out
18:15:11 <korvo> Ah. I put combinators over LPEG for that. LPEG started life as a Lua PEG runtime but morphed into a bytecode VM, and there's a nice homomorphism from parser combinators to LPEG bytecode.
18:15:48 <korvo> It's easy to show that LPEG bytecode can't jump too far backwards, and from there to show that the machine only eats each input character at most once.
18:15:59 -!- X-Scale has quit (Ping timeout: 256 seconds).
18:16:07 <ais523> (you compile the regex into a state machine that takes the input in reverse order, run over the input backwards to annotate each input token/byte with the appropriate regex state, then use the token/state pairs as LR(1) tokens)
18:16:38 <ais523> I don't like PEG because it is too easy to write a grammar that doesn't mean what you thought it would mean or what it looks like it would mean
18:17:35 <korvo> BTW when using compiler frameworks this usually isn't an open question. To write parsers in RPython, I'm basically obligated to use RPLY, an RPython version of Baezley's PLY library. And if my grammar is nasty, like recently with Nix, then I get to write my own Earley setup.
18:18:02 <korvo> PEG's just CFG but all choices are ordered. If it's not clear how to order each choice, then the original CFG might not be unambiguous.
18:18:31 <ais523> well, "A / B" in a PEG means "either an A, or a B that does not start with an A"
18:19:53 <ais523> so a grammar like «S: X | Y; X: 'd' | 'd' 'e' 'f'; Y: 'd' 'e' | 'd' 'e' 'f' 'g'» can't be translated to a PEG because there is a valid X that starts with a Y and a valid Y that starts with an X
18:20:31 <ais523> also, most popular PEG parsing algorithms are linear-time but with horrible constant factors
18:20:41 <korvo> And you're not a fan of `S1: X / Y; S2: Y / X; S: S1 / S2` I guess?
18:20:59 <korvo> Which is usually expressed via PEG's "unlimited" lookahead, but same idea.
18:21:15 <ais523> I didn't realise you could do that, and am now trying to figure out the implications
18:21:54 <korvo> PEG just insists that you not be allowed to provisionally accept an input. Either it's acceptable now, and we know which production it matches, or it's not acceptable now and we know that no production matches.
18:22:20 <korvo> It's just Earley without the bookkeeping and non-determinism.
18:22:48 <ais523> actually I don't think that even works: a Y that starts with an X is not an S1, and although it is an S2, it starts with an S1 and thus it is not acceptable for S
18:23:14 <ais523> so this just collapses down to be equivalent to S: X / Y
18:26:38 <korvo> Assuming X and Y have no lookaheads, yeah.
18:28:56 <ais523> so yes, I'm not a fan of it because it doesn't do what it looks like it's meant to do, or indeed anything useful at all :-D
18:28:58 -!- Noisytoot has joined.
18:29:40 <korvo> Anyway, I think that Marpa's author isn't great at writing docs, but he does seem to have correctly cracked the issue of Earley parsers not always performing well on unambiguous grammars, and maybe the correct answer is to implement Marpa for popular languages.
18:30:31 <korvo> Also CYK is asymptotically what's desired, although its runtime constants are terrible since it can't predict in advance how much space will be needed.
18:31:04 <ais523> Bison uses GLR, which is asymptotically as good as Earley
18:31:18 <ais523> (and runs in O(n) time when the grammar happens to be LR(1))
18:33:45 <ais523> oh, that reminds me: I found a really nice formalism of parser-generator output, as repeated regex replacement (the operation that Perl calls s/regex/string/, where the string is a fixed string, although it runs on terminal/nonterminal mixes rather than character strings) – you express the parser as a set of mutually-exclusive regexes
18:34:39 <ais523> err, not quite s/regex/string/, the regex can match before and after the replaced portion
18:34:45 <ais523> so it's more like /regex/; $1 = string
18:35:01 <ais523> (I'm not sure if you can do that in Perl but you probably can, it's that sort of language)
18:35:26 <ais523> `perl-e $_ = "abcdef"; /b(cd)e/; $1 = "g"; print
18:35:29 <HackEso> Modification of a read-only value attempted at -e line 1.
18:36:32 <ais523> with most styles of parser it is possible to define a value for each terminal and non-terminal – if you state that replacements must reduce the total value of the string, that proves the parser runs in linear time
18:37:21 <ais523> and it is normally possible to do that except with nonterminals that match the empty string, those have to be given zero value, but if you make a rule that two copies of the same zero-value nonterminal can't appear without something with positive value in between, that also proves the parser runs in linear time
18:37:34 <ais523> err, negative value, not zero
18:38:18 <esolangs> [[Special:Log/newusers]] create * Impossible Esolang Creator * New user account
18:47:44 <esolangs> [['Python' is not recognized as an internal or external command, operable program or batch file.]] M https://esolangs.org/w/index.php?diff=144859&oldid=144828 * PythonshellDebugwindow * (+77) See also, categories
18:49:30 <esolangs> [['Python' is not recognized]] M https://esolangs.org/w/index.php?diff=144860&oldid=144849 * PythonshellDebugwindow * (+106) Categories
19:01:55 -!- tromp has joined.
19:12:13 <ais523> oh neat, I found a terminal control code that's implemented consistently by every terminal I tested, but in a way that contradicts the relevant standard
19:12:26 <ais523> (the standard looked wrong when I read it – seems all the terminals agree)
19:13:24 <ais523> it is ESC [ number @, which moves the remainder of the line number positions to the right/forwards – the terminals and standard agree on that, but the standard also moves the cursor to the start of the line for some reason (even though that isn't useful), whereas the terminals leave it alone
19:18:15 -!- craigo has joined.
19:23:39 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144861&oldid=144860 * Ractangle * (+50) /* Syntax */
19:23:58 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144862&oldid=144861 * Ractangle * (+26) /* Syntax */
19:27:43 <esolangs> [['Python' is not recognized as an internal or external command, operable program or batch file.]] https://esolangs.org/w/index.php?diff=144863&oldid=144859 * Ractangle * (+121) /* narcissist */
19:28:14 <esolangs> [['Python' is not recognized as an internal or external command, operable program or batch file.]] https://esolangs.org/w/index.php?diff=144864&oldid=144863 * Ractangle * (+47) /* Computational class */
19:29:07 <esolangs> [['Python' is not recognized as an internal or external command, operable program or batch file.]] https://esolangs.org/w/index.php?diff=144865&oldid=144864 * Ractangle * (+16) /* Computational class */
19:35:01 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144866&oldid=144862 * Ractangle * (-35) /* Syntax */
19:45:23 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144867&oldid=144866 * Ractangle * (+54) /* Syntax */
19:47:45 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144868&oldid=144867 * Ractangle * (+47) /* Examples */
19:48:46 <esolangs> [['Python' is not recognized]] https://esolangs.org/w/index.php?diff=144869&oldid=144868 * Ractangle * (+109) /* Unfinished Truth-machine */
19:52:51 <esolangs> [[Special:Log/upload]] upload * Ractangle * uploaded "[[File:The only screenshot of the JS-CODE thing.jpg]]"
19:54:07 <esolangs> [[JS-CODE]] https://esolangs.org/w/index.php?diff=144871&oldid=144854 * Ractangle * (+191)
19:54:26 <esolangs> [[JS-CODE]] https://esolangs.org/w/index.php?diff=144872&oldid=144871 * Ractangle * (+14) /* Syntax */
20:22:23 -!- Thelie has quit (Quit: Leaving.).
20:25:34 <esolangs> [[JS-CODE]] https://esolangs.org/w/index.php?diff=144873&oldid=144872 * Ractangle * (+72) /* Syntax */
20:25:47 <esolangs> [[JS-CODE]] https://esolangs.org/w/index.php?diff=144874&oldid=144873 * Ractangle * (+11) /* Syntax */
20:28:35 -!- Sgeo has joined.
20:34:21 <b_jonas> and sometimes you know the grammar has some ambiguities, and you want to specify how those few are resolved, and prove that there are no other ambiguities, and prove that a specific way of writing the parse that you decided isn't allowed in an ambiguous case can be rewritten with some simple workaround which parses correctly. it gets complicated.
20:35:53 <esolangs> [[JS-CODE]] https://esolangs.org/w/index.php?diff=144875&oldid=144874 * Ractangle * (+182)
20:37:31 <b_jonas> ais523: in perl, s/before\Kbetween(?=after)/replacement/ replaces just the middle part
20:38:43 <b_jonas> alternately you can use captures like s/(before)between(after)/${1}replacement$2/
20:40:20 <esolangs> [[User:Ractangle]] https://esolangs.org/w/index.php?diff=144876&oldid=144841 * Ractangle * (+38)
20:42:12 <esolangs> [[Xuki]] https://esolangs.org/w/index.php?diff=144877&oldid=144586 * Ractangle * (+24) /* Syntax */
20:42:26 <esolangs> [[Xuki]] https://esolangs.org/w/index.php?diff=144878&oldid=144877 * Ractangle * (+17) /* Syntax */
20:42:30 <b_jonas> though IME writing anything using repeated replacements like this correctly can be tricky
20:42:40 <esolangs> [[Xuki]] https://esolangs.org/w/index.php?diff=144879&oldid=144878 * Ractangle * (+0) /* A+B Problem */
20:43:33 <esolangs> [[Xuki]] https://esolangs.org/w/index.php?diff=144880&oldid=144879 * Ractangle * (+5) /* A+B Problem */
20:44:09 <esolangs> [[Xuki]] https://esolangs.org/w/index.php?diff=144881&oldid=144880 * Ractangle * (+34) /* Syntax */
20:45:09 <b_jonas> it's the same problem as with parsers, the match will be ambiguous and will not replace what you wanted to replace
20:45:32 <ais523> b_jonas: I'm not intending it as something to write by hand, but as a computational model
20:45:58 <esolangs> [[Fortuludmium]] https://esolangs.org/w/index.php?diff=144882&oldid=142620 * Ractangle * (-173)
20:46:45 <ais523> in particular, it models both LR(1) and LL(*) correctly (because they in effect use a finite state automaton to determine the point where the replacement ends or starts respectively, and you can compile that into a regex)
20:47:20 <ais523> and there's a linear-time implementation which basically gives you a generic linear-time parser backend that isn't tied to particular linear-time algorithms
20:47:52 <b_jonas> right. the one piece of good news is that IIRC 64-bit perl supports characters with codes up to 2**63 in character strings, so you can encode your terminals and perl regexes will treat them as single characters.
20:48:55 <b_jonas> of course you might have to make sure that they don't occur in your input
20:48:58 <ais523> why do you need 64 bits for that? a) there's plenty of room between 0x10FFFF and 0xFFFFFFFF, b) there are private-use planes that you could use for nonterminals if you don't need them for something else
20:49:40 <esolangs> [[*python]] https://esolangs.org/w/index.php?diff=144883&oldid=144395 * Ractangle * (+6) /* Errors */
20:50:34 <b_jonas> also it doesn't really help with regexps that they're single characters, so you only really need a few characters that don't occur in your input
20:51:42 <b_jonas> your parser generator may care about exactly how many symbols it looks ahead; perl regexps don't
20:52:00 <ais523> well my backend model doesn't care either
20:53:01 <esolangs> [[*python]] https://esolangs.org/w/index.php?diff=144884&oldid=144883 * Ractangle * (+34) /* Truth-machine */
20:57:06 <b_jonas> the brand of the light bulbs above me is "Trixline", so I almost have trilimes above me
21:05:16 <zzo38> Depending on the input format, you might be able to use all codes greater than 0xFF (or maybe 0x7E) too, if the input handling supports that
21:06:43 <esolangs> [[C-like language]] https://esolangs.org/w/index.php?diff=144885&oldid=144396 * Ractangle * (+2) /* Hello, world! */
21:06:52 <zzo38> (That is, if it deals with individual bytes. It is probably usually more useful for a regular expression to deal with individual bytes instead of UTF-8 if you do not need to handle non-ASCII characters in matching; that will also then work with other character sets than Unicode too, without needing to do any conversion.)
21:07:21 <zzo38> (If your input is UTF-16 or UTF-32, or another multibyte code, then the higher character codes are more useful for directly representing character codes.)
21:08:08 <zzo38> (Furthermore, what if you do not have a 64-bit computer?)
21:10:06 <esolangs> [[: ]] https://esolangs.org/w/index.php?diff=144886&oldid=142919 * Ractangle * (+84) /* Syntax */
21:10:26 <esolangs> [[: ]] https://esolangs.org/w/index.php?diff=144887&oldid=144886 * Ractangle * (+6) /* A+B Problem */
21:11:33 <esolangs> [[MarkupL]] https://esolangs.org/w/index.php?diff=144888&oldid=144160 * Ractangle * (-6) /* MarkupL add-ons */
21:11:52 -!- Everything has quit (Ping timeout: 252 seconds).
21:12:25 -!- Everything has joined.
21:13:12 <zzo38> I thought the character codes were limited to 32-bits, but now you say it can use 63-bits. I think that would waste more memory but also can be useful for reasons you describe and for other reasons (e.g. in case anyone actually uses 63-bit character codes, but that seems unlikely to me)
21:20:59 <ais523> a Perl string acts like an array of integers that represent character codes, but is internally stored using one of two compression schemes, one which works only when all the integers are small, and the other of which has a strong resemblance to UTF-8
21:21:32 <ais523> but, the details of the compression are supposed to be entirely invisible to the programmer (there are a few historical-reasons bugs that can expose them and a couple of APIs to expose them intentionally_
21:21:52 <zzo38> O, then it won't waste memory, but it will make the execution more complicated so might be less efficient for time even if the space is efficient.
21:28:30 -!- Thelie has joined.
21:41:25 <b_jonas> ais523: also I still find the idea of no separate lexer stage strange, because separate lexing rules is how I find natural to think of languages. the lexer is there because I don't want a keyboard as huge as the number of possible tokens, so I type all by the most frequent tokens as multiple characters. yes, C++'s special lexer exceptions where >> and <: are sometimes not matched leftmost-longest as a
21:41:31 <b_jonas> token is an argument, but it's not strong enough to discard the whole idea of a lexer.
21:42:36 <b_jonas> also you usually want to attach a pointer to many of those nonterminals to store a parse tree or some other intermediate compiled representation, so just a bunch of s/// substitution rules could be hard to use.
21:47:36 -!- sprocket has joined.
21:47:53 -!- sprock has quit (Ping timeout: 245 seconds).
21:58:10 <ais523> b_jonas: I've been having a lot of fun figuring out how to optimise out the intermediate representation, or at least change it to something more efficient
21:59:13 <ais523> my current plan is to parse into reverse-Polish, then parse the resulting reverse-Polish string again backwards (which is LL(1)), which should be much faster than building a parse tree in applications that don't need one
22:00:09 <ais523> and the reason I don't like the idea of a separate lexer is that often lexing is context-dependent (to the extent that POSIX yacc has to precisely define the parser's evaluation order to let it interact with the lexer correctly, which in turn makes a lot of interesting optimisations impossible)
22:01:00 <ais523> given that a lexer can easily be expressed in the format typically used for parsers, it makes so much more sense for the parser and lexer to be in the same source file and same automaton – that way you get lexer context-dependence for free, and can check for ambiguities across lexer and parser together
22:02:16 <ais523> fwiw, I think it makes sense for both lexers *and parsers* to have a way to explicitly allow/ban particular things in the right context
22:02:24 <ais523> e.g. to say "an identifier cannot be followed by a letter"
22:02:39 <ais523> as a way to precisely describe disambiguation rules
22:04:55 <korvo> Maybe *this* is what tagless-final encoding is for. The parse tree only exists as an intermediate type which is reliably optimized out of the resulting call graph.
22:05:44 <korvo> I know catern has used this. They're also fairly opinionated, so it's worth being skeptical. Ditto with Oleg, who I think is the origin of the name "tagless-final".
22:07:02 <korvo> On lexers: they can increase the effective power of a parser, right? e.g. Python lexers emit INDENT and DEDENT tokens, letting a PEG parse an otherwise-context-sensitive grammar.
22:08:33 <ais523> korvo: only by increasing the effective power of a lexer
22:08:59 <ais523> finite-state machines can't do indent/dedent either, so if you are extending a lexer to be able to do that, you could alternatively extend a parser to be able to do that
22:09:27 <ais523> which might be important if the indent/dedent behaviour was different in two different places in the same input (imagine a parser for mixed Python and Haskell)
22:15:17 -!- X-Scale has joined.
22:16:11 <korvo> ais523: Oh, good point. I guess "power" is an overloaded word. Like, Python can be lexed in linear time (because every token piece is recognized by a regex), so it doesn't raise the practical time complexity of an amortized-linear PEG parser.
22:16:33 <korvo> Maybe the Chomsky hierarchy is not that useful?
22:16:49 <ais523> 2 and 3 seem to be the only practically useful parts
22:17:34 <ais523> because they put restrictions on things that are often possible to comply with and give you nice properties that can be exploited to, say, write linear-time parsers
22:17:38 <korvo> CFGs do feel like some sort of natural ceiling. And I guess we should be glad that recognition is in P, cubic even!
22:19:59 <ais523> in practice recognition is quadratic, it only becomes cubic if you the input exposes an ambiguity in the grammar, at which point you could reasonably reject it (thus, the cubic case is only useful when using dynamic precedence resolution rules)
22:20:36 <korvo> ...Maybe it's because of applicative trees. Concrete parses for CFGs always yield a well-behaved rooted tree. For CSGs I don't know what we get; like trees with a per-forest context? And eventually when we get to TMs we have traces of machine actions.
22:24:09 <b_jonas> "if the indent/dedent behaviour was different in two different places in the same input" => it kind of is, newlines are ignores in string literals, blank lines after a backslash continuation marker, and most interestingly inside parenthesis of any kind, so you have to recognize balanced parenthesis
22:25:00 <ais523> b_jonas: ooh, so Python's lexer has to do paren matching, which is the standard example of something that belongs in a parser and not a lexer
22:25:59 <int-e> the CFG can ignore indent/dedent inside of expressions
22:26:04 <korvo> Yep, Python descendants are required to not just measure indent depth but also keep a bracket/paren stack. And modern Python also includes E-style quasiliterals, which require the lexer to keep a QL piece stack.
22:26:18 <int-e> But I don't know what Python *does*.
22:26:37 <korvo> I haven't looked at ECMAScript's specification in a while. I wonder how they added "template literals", their E-style QLs.
22:26:43 <zzo38> Some programs will do some of the things together for various reasons, and for some programs, the result of the parser could control the working of lexer as well as other way around
22:26:55 <int-e> sorry, that doesn't work, it indeed has to be done by the lexer
22:27:13 <zzo38> What is "E-style quasiliterals"?
22:27:43 <int-e> hiding context-sensitive stuff in lexer + postprocessing after parsing is standard anyway
22:28:06 <int-e> The most egregious example is dealing with identifiers and scope.
22:28:08 <b_jonas> ais523: you can imagine it as four or fivr stages instead of just a lexer and parser: first you lex most tokens including find the end of single-line or multi-line literals and single-line comments, then you match parenthesis (of all kind), then you find the newlines that matter and mark ident and dedent tokens, then you do the rest
22:28:11 <ais523> Rust lets you do things like let a = 4; let b = 5; println!("a = {a} and b = {b}");
22:28:38 <ais523> but I know how it does that, identifier ! ( … ) runs arbitrary code on what's inside the parentheses, which has a rule that the parentheses have to match and not many other rules
22:28:54 <korvo> E-style is an extension of what Perl had; you can do `this kind of $variable interpolation`, but also `pattern-match @piece by @piece with backtracking` and e`def embed { any.legal($ast) }` as a splice.
22:28:55 <ais523> and that code returns a parse tree that gets inserted at that point in the source
22:29:46 <ais523> int-e: I agree that identifiers/scope is effectively a major part of parsing that parser formalisms gloss over
22:29:54 <ais523> and have been wondering about how to fit it directly into a parsing automaton
22:31:26 <zzo38> In PostScript, a {} block is a single token that can contain other tokens. The // prefix makes that the value of the token is whatever the following name refers to at the time of being tokenized, rather than the value of the token being the name itself (which it is if the // prefix is omitted).
22:31:48 <int-e> attribute grammars try to do that kind of things, right?
22:32:40 <int-e> (AIUI they *embrace* the CFG approximation but try to incorporate post-processing inside the grammar in a formal way.)
22:33:07 <korvo> ais523: In LPEG I found myself wanting a GENSYM bytecode. I also needed to gensym when doing miniKanren and couldn't find a way to do it.
22:35:41 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:37:05 <b_jonas> ais523: also python parsing runs into the problem where a variable or tuple constructor call can appear syntactically either in an expression/rvalue or a pattern/lvalue, they mean different things in the two syntactical contexts, and you pretty much have to do the whole parsing blindly before you can determine which occurrances are in pattern/lvalue context.
22:38:39 <b_jonas> also there's a third context, patterns for case statements, which you *can* recognize in advance, but they're somewhat similar to ordinary patterns/lvalues, so you have to figure out how not to duplicate the shared part of syntax and semantics
22:39:21 <ais523> b_jonas: what does the right-context look like, to make the same left-context into either an expression or pattern?
22:39:40 <ais523> …I have suddenly realised why Rust says "if let" and not just "if"
22:40:01 <ais523> it's to let whatever comes after "let" unambiguously parse as a pattern
22:41:53 <korvo> Yep, same with E "def", ECMAScript "let" and "const", Monte "object". Not Python "class" though; they just required INDENT first!
22:42:21 <b_jonas> ais523: there's like ten different productions for lvalue context. assignment statement `lvalue = rvalue`, for loop head `for lvalue in rvalue`, with statement head, expect clause head, after `for` in an array/iterator/dictionary display eg. `[rvalue for lvalue in rvalue]`, and probably more that I forget
22:42:38 <b_jonas> and of course inside a tuple or array in lvalue context too
22:43:51 <b_jonas> I've seen this same problem when making one of geo or scan by the way
22:44:30 <ais523> this reminded me of something else: I realised recently that assignment operations are "backwards" and should place the variable being assigned to on the right, so that the statement reads in order
22:44:53 <ais523> «e = a.b().c().d()» makes you jump back to the start of the statement after reaching the end
22:45:33 <ais523> (I realised a bit less recently that pointer dereference should be postfix, for the same reason – it is in Pascal, but prefix in C for some reason, which is why it needs a separate -> syntax)
22:45:36 <int-e> ais523: Rust also does the C thing where `a = b` is an expression.
22:45:56 <ais523> int-e: sure, but that isn't mutually exclusive with pattern matches
22:46:19 <ais523> there's no reason why (x, y) = (1, 2) couldn't assign to two different variables and return the same tuple that was matched against
22:46:27 <int-e> well the semantics of if a = false and if let a = false are quite different
22:47:15 <ais523> the former cares about the boolean value assigned to a, the latter about whether the assignment was possible
23:06:04 <b_jonas> ais523: in rust that doesn't really work because it would have to copy x and y which isn't always possible
23:06:31 <ais523> no, it'd have to copy the tuple
23:06:34 <ais523> which can be done if it's Copy
23:06:52 <b_jonas> yes, and copying the tuple has to copy its members
23:07:14 <ais523> but x and y aren't the members, 1 and 2 are
23:07:33 <ais523> most languages with chained assignments return the value being assigned, not the variable being assigned to (Perl is weird in that respect)
23:07:43 <b_jonas> right, 1 and 2 are of copiable types
23:08:05 <ais523> I feel like we're agreeing with each other?
23:08:14 <b_jonas> also is it true that BASIC dialects differ in what `LET X = Y = 0` means?
23:08:45 <ais523> it wouldn't surprise me, but OTOH I'd expect it to be a parse error in many of them
23:13:10 -!- Everything has quit (Quit: leaving).
23:25:49 <Soni> has anyone done something like this? https://discuss.kotlinlang.org/t/an-alternative-to-checked-exceptions-that-actually-works-for-catching-bugs/23079
23:26:34 <int-e> I'd /expect/ it to compare Y and 0 and assign X a value based on that.
23:33:52 <korvo> Soni: Have you seen Elm or its offspring, like Derw or Roc? They propose to take one of Standard ML's memes seriously: well-typed programs *cannot* go wrong.
23:35:14 <korvo> I wouldn't recommend *using* Elm, due to serious implementation issues, but it's good food for thought.
23:35:42 <Soni> maybe if it had global typestate
23:36:02 <korvo> Like, what kinds of faults can be caught anyway? What does it mean to have an unexpected fault coming through your call frame?
23:37:20 <Soni> do you know about global typestate?
23:37:39 <korvo> My language Cammy is pursuing the same meme from a different angle, via OCaml's tradition. But I gave up on exceptions entirely; a Cammy expression *cannot* go wrong, and type failures can only happen at the very beginning and end of the program, when the caller makes a mistake.
23:40:32 <korvo> I don't know that exact phrase. Searching gives me this paper: https://arxiv.org/abs/2107.13101 I know the typestate pattern; I'm more interested in structural approaches, but it seems alright for a nominal approach.
23:42:02 <korvo> At that point, though, I'd argue that the language should add algebraic laws instead of putting more work into the typechecker. It'd be a better investment that covers the same theorem-proving territory.
23:43:12 <Soni> global typestate is an approach to solving signal safety
23:43:38 <Soni> we would like to see global typestate in rust, and deprecation/removal of existing rust globals
23:44:46 <Soni> that paper appears to be about global analysis of typestate, so... slightly different issue
23:46:01 -!- amby has joined.
23:48:54 <Soni> (is "deprecating globals" esoteric enough for #esolangs ?)
23:56:36 <zzo38> I would think that in BASIC, "LET X = Y = 0" would set X to -1 if the value of Y is zero or 0 if nonzero, although different implementations might do differently
23:57:24 <zzo38> A program that I had partially written and am continuing to do, is converting a custom ASCII-text-based format that I had made up into DER format, and the parsing in that program has its own way of working; e.g. the tokenizer only reads the beginning of a string and the rest of the string literal is parsed by the function that encodes it.
23:57:39 <zzo38> Which escape codes are allowed in a string literal depends on its type, and there are other stuff as well
23:59:07 <korvo> Soni: Signal safety is definitely esoteric. Have you considered not doing signals instead?
23:59:48 <Soni> korvo: but where's the fun in that :D