Could not parse float: ParseFloatError { kind: Invalid } on loading MeTTa file

[Adam-Vandervorst]

https://github.com/Adam-Vandervorst/metta-examples/blob/main/aunt-kg/simple_conversion.metta on the adameve.metta import fails with Could not parse float: ParseFloatError { kind: Invalid }

Do you have any suggestions for debugging? A line number or "failed on string X" would help a lot.

[vsbogd]

Only way I can suggest at the moment is printing tokens and src_range before calling grounded atom constructor here https://github.com/trueagi-io/hyperon-experimental/blob/f22e747c214a8a507ed5350040335b43c84efe39/lib/src/metta/text.rs#L192 and look at the last printed entry.

[luketpeterson]

Another drop in the "damage done by regex" ocean. https://xkcd.com/1171/

There are several layers of issues here:

There is the fact that no user input should be able to make the parser panic. So there needs to be an error pathway for the tokenizer string-to-atom code to throw a non-fatal parse error, with a span reference in the source code.

But the reason this was panicking is because it was trying to convert "36:14" into a float. And it was doing that because the regex was "[-+]?\d+.\d+"

I think the intent was two groups of one or more digits separated by a '.' Unfortunately an unescaped '.' matches any character, and in this case ':'

[luketpeterson]

Partial fix implemented https://github.com/trueagi-io/hyperon-experimental/pull/636

Tomorrow I'll get the soft errors from Tokenizer functions to flow to the parser gracefully.

[luketpeterson]

The rest of the fix is implement in https://github.com/trueagi-io/hyperon-experimental/pull/637

You can test it from the repl (until we add bigints)

> !(println! 4358908530958340958430958309583409583409)
 - byte range = (11..51) | Could not parse integer: '4358908530958340958430958309583409583409', number too large to fit in target type

[luketpeterson]

I'd like to plug this into the repl's syntax highlighting, but I think I'll punt on that for now.

The reason is that there is actually two passes. The first pass which interacts with the repl's syntax highlighting is going from text to syntax nodes. And the second pass is going from the syntax tree to atoms. But that second pass is run by the repl after you hit enter, not with every keystroke. And this error originates in the second pass.

So in the interest of priorities, I'll punt on immediate feedback in the repl for now.

[luketpeterson]

Closing this issue as the problems are addressed & merged. Can open another one for further improvements or if more problems are found.