undefined | Better HN

0 pointskortex4y ago0 comments

> Haha, "Those symbols need not be text", you say, right after quoting a definition that says they need to be "a string or text"!

Ha yeah nice catch, that's why I added that in there. In this case the dictionary is slightly wrong.

> The defining aspect of parsing, that makes it difficult and an interesting thing to study, is that you're starting with a list and ending with a tree.

Ah, I didn't know that! Great bit to learn.

In that case, I will say that the "increase a data structure's rules" is a bit ambiguous.

I think my statement is still correct in that "a symbol could be a data structure," right? Like you could take a list of dicts and emit a tree of dicts.

But wait, a list is a kind of tree, or rather, there is a parse tree of recursive head/tail branches. So I think you could still argue List->NotEmptyList is a Parse because NEL requires a nonzero "head" and zero or one NEL as "tail."

0 comments

justinpombrio4y ago

> I think my statement is still correct in that "a symbol could be a data structure," right? Like you could take a list of dicts and emit a tree of dicts.

Yeah I guess. Text combinator libraries like Haskell's Parsec and Rust's Nom are typically parametric over the type of "characters". Realistically I don't think I've ever seen anyone use one of those libraries for an input that wasn't text-like, though; do you have a use case in mind?

> But wait, a list is a kind of tree, or rather, there is a parse tree of recursive head/tail branches.

Yes, so you can run into parsing problems when working with trees, if you work really hard at it. But if you do the correct action is "reconsider your life choices" and not "use parsing theory".

j / k navigate · click thread line to collapse