Add StringLiteral.parse(), NumberLiteral.parse()

[stasm]

Fix #243. The PR is based on #242.

@Pike, how does this look to you? I'll add tests for both process methods later today.

[Pike]

I think this is OK broadly, but there's a couple of details that I'd like to get changed.

For one, I think having an AbstractLiteral base class would help a lot. I tried to understand {value} in StringLiteral, and it didn't make sense, until I figured that it probably does that because it's a base class to what NumberLiteral.process returns. I'd move the comment from StringLiteral here, which also helps to give NumberLiteral a proper comment.

Then I've been pondering more on cook -> process -> ..., and wondered about parsed_value(). What do you think? process can be sooo many things ;-)

And lastly, I'd prefer more symmetry between the impls in StringLiteral vs NumberLiteral. One is inline in the AST node, the other has half the impl in a module. I'd be totally fine with just both being inline, but also if both are external. But that module should only expose parse_string_value and parse_number_value, and not helper data like KNOWN_ESCAPES, IMHO.

[stasm]

Thanks for the review, it was very helpful. I've updated the PR to address your feedback. I'm still to write tests.

I considered a number of naming options for the processing method. I like your parsed_value suggestion, but in the end, I'm not sure if it works well with the return value which is an object. I think I'd like to keep it that way because it makes it easy to add more infromation about the literal in the future, if needed. NumberLiteral already uses it to return precision next to the value.

For this reason, I went for Literal.parse(). After all, for numbers, it parses both the value and the precision. I realize that parse might be loaded in the context of a reference parser. I'm still open to other suggestions. Here are a few other ideas: extract, evaluate, interpret, derive, read.

[Pike]

parse is fine, extract would also work for me. Less fond of the other options.

[Pike]

Can you give me a hint on why NumberLiteral.run does something in tests? I can't find that ad-hoc.

[stasm]

I apologize for not providing more context. My connectivity was poor last night. Is your question specifically about NumberLiteral.run, or about StringLiteral.run too? Each production in grammar.mjs is a highly-specialized parser. The tests take advantage of that and use run to parse some input, get a Result, and then fold it using a success function and an error function (similar to how Promise.then works).

[Pike]

Ah, OK, thanks.

It's been a couple of ages since I looked at the actual parser impls, thanks for the recap.