1. 17

  2. 3

    Do you plan to move eggex parsing & translation into a separate library, for easy linking from other projects? (Or did you maybe already do that? I tried searching but didn’t seem to be able to find one easily.)

    1. 4

      I would like to, but realistically it won’t happen because I’m working on many other things now. I would probably copy the grammar into yacc to make a reference implementation:


      If anyone wants to do that we should chat about it on Zulip. It’s not a big language – yacc should be able to create a tree easily, and then printing it to ERE or PCRE is a “dumb” single-pass algorithm.

      edit: the other things I’m working on: http://www.oilshell.org/blog/2019/12/09.html#whats-next

      1. 1

        Ok, then if I decide I want it one day, I’ll contact you. Thanks!

        edit: Ah, I wondered why I missed the whats next list; now I see that’s because it is cunningly hidden in plain sight below a long and boring list of contributions ;)

    2. 2

      Do the examples work for y’all? When enter e.g. “pat = / [0-9]+ /” in osh pre10, it just barfs that “[ interactive ]:1: ‘pat’ not found”.

      1. 2

        Oh sorry you have to use bin/oil to do that. In bin/osh it’s var pat = / [0-9]+ /.

        That’s basically because foo = in shell means running a command foo with an argument = !

        I need to document that difference more.

        Also, the two syntax changes I mentioned aren’t in the 0.7.pre10 release – they’ll be in the next one. So if you want the latest you can get the dev build which takes 30 seconds on most machines.


        Thanks for trying it, and let me know if you have more problems!

        1. 1

          Makes sense, now that you tell me. Thanks a lot!

      2. 1

        Hey your site always views tiny on mobile. Might need to add something like this

        <meta name="viewport" content="width=device-width, initial-scale=1">

        I’m unfamiliar with this metalanguage


        1. 1

          Hm I just tried that but it looks funny on my iPhone. Right now I just turn my phone horizontally and it’s readable. It doesn’t work well vertically I agree. If anyone has any other suggestions let me know.

          It is some variant of BNF because of the ::=, but I’ve never seen ... to mean a character range. The wikipedia page mentions [] as an extension but not ... .

          I guess the point is that Eggex should be readable enough for a specification (unlike Perl regex) and unambiguous enough for a computer program to execute (unlike the many variants of BNF).

          Also the wikipedia page uses <subpattern> where as Python’s spec just uses subpattern.

          1. 2
            • The meta tag is a good idea. It is dumb that we all have to insert, essentially, the same boilerplate into every website, but such is the internet.

            • Your body element has the .skinny tag, which has a hard width of 30em. You likely want to specify max-width: 30em, so that element automatically shrinks on narrower viewports (like a portrait phone).

            • Your <pre> blocks are also long. I’ve always struggled with styling long code blocks for mobile clients. There are some simple things you can do: pre { overflow: auto } will turn on scrollbars, and a smaller font helps too. But, I think, nothing beats rewrapping your source code, even though that might be a lot of work.

            (I’m a big fan of your blog. Also, I think we may both know someone in common [Sonke].)

            1. 3

              It is dumb that we all have to insert, essentially, the same boilerplate into every website, but such is the internet.

              It’s basically a shibboleth that means “yes, I understand there are displays narrower than 800 pixels”. It’s kind of a weird thing given that the Web was supposed to be device-independent from the beginning, but there was that awkward early-teen phase where “device independent” meant “this page looks OK at 800×600 and 1024×768”, which will live forever because the #1 rule of browser-maintenance is “don’t break the web”.

              1. 2

                Hm I added those changes here. It does make it bigger by default, at the cost of removing the left margin, which makes it hard to read IMO.


                It seems to be better by default but remove some flexibility. The way it is now I can make it look nice if I zoom the right way.

                I think one solution for the <pre> problem is to prefer a skinnier font? I’m not sure what that would be though.

                1. 1

                  I wish you luck on your responsive CSS journey. Iosevka is my skinny font of choice.