IRC channel logs

<stikonas>ok, with this change https://github.com/stikonas/mes-m2/tree/riscv64 mes-m2 builds on riscv64 but does not run yet (segfaults). But that is expected as I've not adjusted crt1.M1 yet

<stikonas>(and change is not upstreamable yet as it breaks other arches)

<pabs3>a Prolog written in Rust https://github.com/mthom/scryer-prolog https://news.ycombinator.com/item?id=28966133

<oriansj>well I guess that is one way to get riscv support for mes-m2

<stikonas[m]>Well, patches can be cleaned up, I just didn't have any spare time yet

<stikonas[m]>This was just a quick attempt to see how much porting is necessary

<oriansj>well it was only the syscalls, everything else should be relatively portable

<markjenkinssksp>My project based on Nystrom's Crafting Interpreters is still inching along https://github.com/markjenkins/lox_compiler_scheme

<markjenkinssksp>I now have 39 tests that apply to my compiler and bytecode_interpreter (arguably that's 78)

<markjenkinssksp>I'm testing against M2-Planet and gcc on aarch64, amd64 and x86, so that's 234 variations the bytecode interpreter is being put through.

<markjenkinssksp>But I just discovered gcc on x86 breaks one of those 234 variations https://github.com/markjenkins/lox_compiler_scheme/issues/1

<theruran>markjenkinssksp: so you rolled your own PEG?

<muurkha>cool!

<markjenkinssksp>had to figure out that PEG is https://en.wikipedia.org/wiki/Parsing_expression_grammar

<markjenkinssksp>I can't really be said to be rolling my own in that I'm following https://craftinginterpreters.com/ very closely, just with scheme for my compiler and M2-Planet for my bytecode interpreter

<markjenkinssksp>Nystrom does describe his approach as hand-written parser vs generated

<markjenkinssksp>Prior to his recent book, he covered his approach to parsing more briefly here http://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-expression-parsing-made-easy/

<muurkha>yeah, pratt parsers are not the same as PEGs

<muurkha>I feel like PEGs are a lot simpler than Pratt parsers for most things, but they're a lot less efficient, and bog-standard PEGs can't handle left-recursive grammars, so if your PEG parser generator doesn't support Warth's left-recursion hack, you have to learn to refactor your grammar to eliminate left-recursion

<muurkha>infix grammars and grammars with postfix operators tend to have a lot of left-recursion

<markjenkinssksp>indeed, from what I can see on the wikipedia article about PEG it's a formal thing, whereas the Pratt approach Nystrom spends part III of his book on is an informal approach that he claims is quite common

<muurkha>I think Pratt would take exception to both of those claims about Pratt parsers :)

<markjenkinssksp>first discussion in Crafting Interpreters is chapter 17 https://craftinginterpreters.com/compiling-expressions.html

<muurkha>operator-precedence parsers are widely used, and so are top-down parsers (PEGs are also top-down, for example), but most operator-precedence parsers are bottom-up

<muurkha>and most top-down parsers are either LL or recursive-descent

<muurkha>PEG parsers, like Pratt parsers, LL parsers, and LALR parsers, have a linear-time performance guarantee, but PEG parsers can also require linear *space*, which can be a real problem

<muurkha>and their constant factors are enormously higher

<markjenkinssksp>In fairness, I guess I may have overstated what the sidebar says about commonness, Nystrom says "But in production compilers, where hand-rolled parsers are common, you’d be surprised how many people know it."

<muurkha> https://github.com/darius/parson/blob/master/eg_linear_equations.py is a good example of a PEG, I think

<markjenkinssksp>that's all for now, thanks muurkha

<muurkha>in this case it parses a system of linear equations

IRC channel logs

2021-10-23.log