Newest at the top
| 2024-11-08 18:45:35 +0100 | <EvanR> | *parsing made easy* xD |
| 2024-11-08 18:43:01 +0100 | <mauke> | (I hope at least some of this made some sense) |
| 2024-11-08 18:42:59 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-11-08 18:42:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-11-08 18:41:21 +0100 | <mauke> | (two expr3 at the start because after seeing "+", expr3 calls itself) |
| 2024-11-08 18:41:06 +0100 | <mauke> | for the final "2", we basically do the same thing again: expr3 -> expr3 -> expr2 -> expr1 -> expr0 -> term |
| 2024-11-08 18:40:19 +0100 | <mauke> | which only succeeds at the top level, with expr3 -> op "+", because the next symbol is a "+" |
| 2024-11-08 18:40:12 +0100 | acidjnk | (~acidjnk@p200300d6e7283f5628026389afde3b8f.dip0.t-ipconnect.de) acidjnk |
| 2024-11-08 18:39:52 +0100 | <mauke> | so when 'between' consumes ")", we return back up the expr hierarchy and try all the possible operators on the way up |
| 2024-11-08 18:39:08 +0100 | <mauke> | after "3": expr3 -> expr2 -> expr1 -> expr0 -> between |
| 2024-11-08 18:38:07 +0100 | <mauke> | btw, call stack at the point where we consume "3": expr3 -> expr2 -> expr1 -> expr0 -> between -> expr3 -> expr3 -> expr2 -> expr1 -> expr0 -> term |
| 2024-11-08 18:38:05 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-08 18:37:42 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2024-11-08 18:37:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-08 18:36:48 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Max SendQ exceeded) |
| 2024-11-08 18:36:47 +0100 | <mauke> | which does consume ")" |
| 2024-11-08 18:36:34 +0100 | <mauke> | on the way back up, no operator parser succeeds in consuming ")", so expr3 returns back into 'between' |
| 2024-11-08 18:36:13 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2024-11-08 18:35:47 +0100 | <mauke> | which adds another round of expr3 -> expr2 -> expr1 -> expr0 -> term, where we consume 3 |
| 2024-11-08 18:35:34 +0100 | briandaed | (~root@185.234.210.211) |
| 2024-11-08 18:35:20 +0100 | <mauke> | then expr3 calls itself (because for simplicity, all of my operators are right associative) |
| 2024-11-08 18:34:42 +0100 | <mauke> | then we return all the way back up the hierarchy, trying all operators in turn (and failing), until we arrive at expr3 again and op "+" succeeds |
| 2024-11-08 18:34:01 +0100 | <EvanR> | so basically, try "(" term ")" last |
| 2024-11-08 18:34:00 +0100 | <mauke> | which presumably successfully consumes 4 |
| 2024-11-08 18:33:53 +0100 | <mauke> | the inner instance of expr3 climbs down the hierarchy again, but this time there is no "(" to be consumed, so expr0 tries term |
| 2024-11-08 18:33:11 +0100 | <mauke> | then we try expr3 again. (current call stack: expr3 -> expr2 -> expr1 -> expr0 -> between -> expr3) |
| 2024-11-08 18:32:26 +0100 | <mauke> | then we immediately climb down the hierarchy to expr0, which consumes the leading "(" |
| 2024-11-08 18:31:27 +0100 | <mauke> | we start in expr3 (the top level) |
| 2024-11-08 18:31:07 +0100 | <mauke> | no, that would work fine |
| 2024-11-08 18:30:53 +0100 | <haskellbridge> | <sm> You are worthy opponent, parser combinators, but they shall return ✊ |
| 2024-11-08 18:30:37 +0100 | <haskellbridge> | <magic_rb> wouldnt that mean you cant have "(4 + 3) + 2"? |
| 2024-11-08 18:30:08 +0100 | <mauke> | the traditional way to do rec-descent infix expressions is to have a hierarchy of expression parsers. like expr3 = do { expr2; op "+"; expr3 }; expr2 = do { expr1; op "*"; expr 2 }; expr1 = do { expr0; op "**"; expr1 } expr0 = between "(" ")" expr3 <|> term |
| 2024-11-08 18:30:05 +0100 | <haskellbridge> | <magic_rb> i think im done for now 😂, thanks again |
| 2024-11-08 18:29:49 +0100 | <haskellbridge> | <magic_rb> tom asked me what bound tighter and my brains response was "uh, && before || yes" |
| 2024-11-08 18:29:37 +0100 | <haskellbridge> | <sm> 👍 |
| 2024-11-08 18:29:15 +0100 | <haskellbridge> | <magic_rb> will do, after i figure out how to actually use that :) and read it :) |
| 2024-11-08 18:28:56 +0100 | <haskellbridge> | <sm> :) |
| 2024-11-08 18:28:48 +0100 | <haskellbridge> | <sm> hello, I am once again urging you to insert dbg or at least trace calls in every parse step so you can see operationally what is happening, it’s very difficult to mentally debug parser combinators |
| 2024-11-08 18:28:43 +0100 | <EvanR> | without chaining different operators |
| 2024-11-08 18:28:30 +0100 | <EvanR> | I confused myself by try to dumb down the language xD |
| 2024-11-08 18:28:14 +0100 | <haskellbridge> | <magic_rb> thanks everyone for trying to help me :) |
| 2024-11-08 18:27:53 +0100 | <haskellbridge> | <magic_rb> tomsmeding: uh, ive no clue, ive confused myself beyond reason. Ill pick this up later, i gotta run anyway |
| 2024-11-08 18:27:50 +0100 | <EvanR> | so those two kinds of expression correspond with 2 parsers |
| 2024-11-08 18:26:59 +0100 | <EvanR> | the classic way is to divide the term language into primary expression and operator expression, and (...) is a primary not an operator |
| 2024-11-08 18:26:54 +0100 | <tomsmeding> | magic_rb: is it `==` and `->` are at the same level, they go before `&&`, and `&&` goes before `||`? |
| 2024-11-08 18:26:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-11-08 18:26:15 +0100 | <haskellbridge> | <magic_rb> mauke: if i cared about what works only i wouldnt be writing haskell :) |
| 2024-11-08 18:26:02 +0100 | <haskellbridge> | <magic_rb> (and i think id like to know how to do it myself, because im completely lost right now) |
| 2024-11-08 18:25:54 +0100 | <mauke> | works, though |
| 2024-11-08 18:25:48 +0100 | <EvanR> | but I see that might be wrong because you can do term || term || term || term |