I am currently playing with the happy parser generator.
Other parser generators can give nice messages like "unexpected endline, expected 'then'".
With happy I just get the current Tokens and the position of the error.
Can you give me an example of how to get error messages like above?
There is a Happy feature that I have authored for this purpose.
See my blog post: Toward better GHC syntax errors
It was merged in this pull request RFC: On parse error - show the next possible tokens.
Generally, from what I've heard, if you want nice parser errors, use Parsec instead of Happy.
Related
I am learning how to develop Skills with Alexa. I followed a Lynda course to build the My Calculator skill, however ran into a problem where the numbers and results are not returned. I double checked my code, and tried it on Echoism.io, and same problem.
Per the attached, the numbers are recorded in the JSON input, however are not returned in the speechText or displayText?
What is the missing piece of code? Thanks.
Node.js code
Alexa console JSON Input
Welcome Roy! Couple things. In the future just put your code right here on the page so that it becomes searchable and we can see the exact characters you are using.
By looking at the images it looks like to me the following might be your use of template literals. Super common mistake.
So to use template literals you need use the back tick (`) instead of the single quote (')
It looks like it is that you currently have
speechText = 'The result of ${firstNumber} plus ${secondNumber} is ${result}';
and what you want is
speechText = `The result of ${firstNumber} plus ${secondNumber} is ${result}`;
Here is another good resources:
How to interpolate variables in strings in JavaScript, without concatenation?
I am new to ANTLR4. I followed the installation instruction on github and ran the example successfully. So installation appears to be OK. Next I downloaded a grammer file I wish to use, ran antlr4 on it, and compiled the resultant files with javac. Then I tried an example like this:
C:> grun GrammerName tokens examplefile
This runs for a couple of seconds and returns, but there is no response. Ive tried using -tree and -ps but I get nothing with either. If I supply a bad filename, then I get a stream of file-not-found error messages, so it is doing something... but if I supply a random data file, I also get no response. Which suggests to me that my example file is not being seen as a valid example of the grammer in question. But why do I not get an error message?
In essence, my question is how do I get TestRig to supply some feedback about the example file I've supplied?
I've tried reading the manual pages on the antlr.org site but there's too much terminology I'm not familiar with yet.
If you supply tokens as the name of the start rule, that tells grun to not invoke the parser at all and only run the tokenizer. This is generally only useful in combination with the -tokens flag, which prints the tokens. Otherwise the only output you see would be possible tokenization errors.
The options -tree, -ps or -gui display the result of the parser. So if the parser isn't executed, they do nothing at all.
If you want to see the parse tree, you should replace tokens with the name of the rule that you want to use. If you want to see the list of generated tokens, you should add the -tokens flag.
Which suggests to me that my example file is not being seen as a valid example of the grammer in question.
It's the opposite actually. If grun detects errors, it will print them to the console. So if there is no output, grun did not detect any errors (however when using tokens, it will only look for lexical errors, not syntactical ones). When calling grun with valid input and without flags such as -tree or -tokens, the expected result would be that there's no output.
I need to get the pieces of text out of text)). Very simple example actually, but gives me quite some pain.
Here is the sample text, it is an email template:
{!Account.Name}
Hi hi there {!Account.Id + 'cool'}.
Very interesting stuff - {!Contact.Description}
Now we get {!Contact.Description + Contact.Email__c}
So I need all the occurances of text like Account.Name, but only those which are within opening "{!" and closing "}" tags.
What is the simplest/starting approach to do it? Note that in case of the last line, I need to get the two occurances, Contact.Description and Contact.Email__c.
Thanks a lot for any help!
I would just do a plain text search for {...} blocks and parse their content with a simple expression parser. Don't try to come up with a parser that gets all the text and must be prepared to deal with any rubbish that can come in outside of the blocks (which could ultimatively lead to security problems).
I would like to change the behavior of menhir's output in follwoing way:
I want it to look up all grammatical alternatives if it finds any, and put them in a list and get me back this ambigouus interpretation. It shall not reduce conflicts, just store them.
In the source code of menhir, it seems to me, that I have to look in "Engine.ml". The resultant syntactically determined token comes in a variant type item "Accepted v" as a state of a checkpoint of the grammatical automaton. This content is found by a function "accept env prod" before, that is part of a bundle of recursive functions, that change the states.
Do you have a tip, how I could change these functions to put all the possible results in the list here and proceed as if nothing happened? Or do you think, that this wont work anyway?
Thanks.
What you are looking for is a GLR parser generator (G is for generalized). Menhir is not such tool, and I doubt you could modify it easily to do what you want.
However, there is another tool that does exactly what you want: dypgen.
I've tried RTM, but: given an ICU UErrorCode, how can I obtain the corresponding error message string? I.e., ICU's equivalent of strerror(3).
const char *u_errorName(UErrorCode code) is the C version of ErrorCode::errorName - but there isn't an "error message" that is anything more than the enum name. That's a great idea, though- I'd recommend to file a bug. Or, consider contributing the code and data? Ideally it would be a localized message…