Fix errors in the parsing docs

[johnhyde]

Here are corrections to some small errors I found in the parsing docs.

There's another issue I haven't addressed here which I'd like to get feedback on. In an actual edge, q.edg is a unit, meaning all the references in the docs to q.q.q.edg (the remaining tape to be parsed) should actually be q.q.u.q.edg.

So my question is, should I go through and update all the references and dojo outputs in these pages to accurately reflect this u face in the unit, or just leave it as it is (which might be more readable)?

If we're going to update the faces, it should probably be in this PR, I would think.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs-urbit-org	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 1, 2024 1:25pm

[johnhyde]

@tinnus-napbus @sigilante @tamlut-modnys
Tagging you guys specifically for your input, if you have any

[tamlut-modnys]

I'm not the most familiar with the parsing docs. If something is incorrect it would seem that the right move is to fix it. That being said we should definitely get confirmation from ~tinnus or ~lagrev.

Thanks for the PR by the way!

[tinnus-napbus]

a couple of minor changes

[tinnus-napbus]

So my question is, should I go through and update all the references and dojo outputs in these pages to accurately reflect this u face in the unit, or just leave it as it is (which might be more readable)?

If the unit is omitted in explanations or something that should be corrected but I wouldn't worry about dojo outputs. I would assume the dojo examples missing the u face or w/e is cos the actual function forgets to add it. Parsers are wetter than wet and you can't cast them without destroying type information so it can be a bit hit-or-miss with the faces & whatever

[johnhyde]

I would assume the dojo examples missing the u face or w/e is cos the actual function forgets to add it.

I did some digging and discovered that actually the u face is probably always needed, but it's not always shown in dojo. In the case of ++cold, the unit is known to be not null, so the type knows the face is there, and it appears in dojo outputs. In other cases, the unit's nullness is unknown, and the u face won't be displayed until the unit is shown to be not null. I guess technically the u face can't exist on a unit whose type is still a fork of ~ and [~ u=*]... although somehow all the ps and qs under that are still shown.

[johnhyde]

This is a bit off-topic, but it would be cool if the pretty printer could indicate boundaries in the noun where we have to do a type refinement to access the data through faces. Currently it can easily happen that it shows you a noun and it looks like you should be able to access a property with a certain wing, but actually there's a unit in there you need to deal with first, which will also add another limb to your wing.