hoon: in +ape:ag, make zero a plain atom #6373
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the `+ape` parser constructor, we were providing `0` as the parsing result for the zero character. Hoon syntax dictates this is a `@ud` however, resulting in a parsing output type of `?(@ud etc)`. Since `+ape` is commonly used for parsing atoms of various kinds, one might end up with a result of `?(@ud @)`, which would fail to nest directly under, say, `@uv`, requiring parsers to add a casting step. Here, we simply cast the zero result to `@` to make it perfectly generic. This should alleviate the need for a casting step in parsers that need to fit their output into a specific aura. (The output type in the common case (ie, `+hex:ag`, `+viz:ag`) is now `?(@ @)`, which is still somewhat strange, but should have better ergonomics.) Since `@` can be used in any place `@ud` is accepted, this is a non-breaking change.
Fang-
referenced
this pull request
in tloncorp/tlon-apps
Mar 4, 2023
We specifically wanted to be able to send a dm with `;<ship> <message>` so the first thing the parser attempts after matching a mic is exactly this. Because the `%say` command previously only required a `(list inline:chat)`, and we now need to distinguish between a `%say` command that is directed to a channel we're `viewing` and a dm, outside of the current context, we included a `(unit ship)` within the command. So the parser then attempts to match a ship and message (found in the `+dm:parser` arm) and builds a `%say` command with the ship if it does. If it's just a `;<ship>` without a message, `+targ` will take over indicating an `audience` change. If there's no `;<ship>` before the message, the text will be passed to `+message` as before, and an empty unit will be put into the `%say` command indicating `+say` should post the message in the current `audience`. This of course required `$whom` support, so I updated the `+targ` arm to include a `+whom` parser, which uses existing parsers such as `+ship` and `+name`, and a new one (`+club-id`). I commented out a few non-essential arms/gates which I'll return to fix: - `+tarl` was commented out since it currently consumes only a `$flag:chat`. - `+ships` and `+tars` because I haven't adjust them to support `$whom` yet, and they've aren't currently called anywhere. - the url parser in `+content` because I was getting an error
belisarius222
approved these changes
Mar 14, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the
+apeparser constructor, we were providing0as the parsing result for the zero character. Hoon syntax dictates this is a@udhowever, resulting in a parsing output type of?(@ud etc). Since+apeis commonly used for parsing atoms of various kinds, one might end up with a result of?(@ud @), which would fail to nest directly under, say,@uv, requiring parsers to add a casting step.Here, we simply cast the zero result to
@to make it perfectly generic. This should alleviate the need for a casting step in parsers that need to fit their output into a specific aura.(The output type in the common case (ie,
+hex:ag,+viz:ag) is now?(@ @), which is still somewhat strange, but should have better ergonomics.)Since
@can be used in any place@udis accepted, this is a non-breaking change.