-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support "integer" category to bind to Long
instead of Integer
#153
Comments
I've been able to so far to have a workaround after running bnfc by:
This is a workaround and not sure if it is at all maintainable. |
I think your trying to make the change in the wrong place. Seems to me if Pdecl. Decl ::= Type Vdef; TInt. Basetype ::= "int" ; Then When you write your Expressions, Just don't insert Integer in the I tried to download your abs.cf file to look at it but the link didn't work. Kent On Thu, Aug 20, 2015 at 9:02 AM, Behrooz Nobakht notifications@github.com
|
Thanks for looking into this. The ABS.cf can be found at https://github.com/CrispOSS/jabsc/blob/master/src/main/resources/abs.cf I am quite at beginner level with BNFC and the BNF grammar that it supports. I will try to better understand your explanation and apply it in our context. |
@nobeh , I believe I bumped sometimes in your same problem. BNFC translates its built-in Integer token type as a java.lang.Integer object in Java, and this is a problem if the parsed token is actually larger than 32 bits.
but this will come at a price:
2) Even if you manage to have an Integer-free grammar, you are bound to manually convert the text of the token to a long, as BNFC gives you back the character that matched the token without further processing. The "further processing" in the case of the built-in token Your workaround is probably the best strategy if you cannot get rid of using the Integer built-in token in your grammar. Otherwise, define your own token and use it instead of Integer, but you will have convert it whenever you need the numeric value of the string matching the token. |
From the point of view of how to address this issue in the next releases of BNFC, I believe the only reasonable solution is to convert the Double and Integer tokens in, respectively, java.math.BigDecimal and java.math.BigInteger; this removes point 1) and mitigates somehow 2) since the APIs of such classes allow to convert the numeric value to the fixed width primitive types. |
I implemented the solution above in the bigInteger branch of my fork. |
@gapag Thanks for the explanations and the patch for this. I am starting to better understand BNFC side of the problem here and see the challenge. As a Java programmer, I just want to suggest generally avoid translating to As you said and would be my conclusion as well, if BNFC is used for Java as a target, this assumption is fair that there should be enough Java knowledge to work around or use the primitive translation scheme. It's not worth to trade performance off in many cases for just being able to use >32b integers. |
@nobeh |
I just created an issue at jflex-de/jflex#191 as I initially thought I am wrongly using the tool chain.
I tried to
and then I tried to tweak a bit the generated
Yylex
as:$ sed -i -e 's/new Integer(yytext())/new Long(yytext())/g' src/main/java/bnfc/abs/Yylex
before continuing with JFlex and CUP runtime. However it seems that the above is not enough and all the "integer" category are used as
java.lang.Integer
.In my language when I have
Now I get a
ClassCastException
based on the change I did toYylex
:Is there a way I can use
bnfc
to bind "integer" category tojava.lang.Long
in Java mode?Thanks.
The text was updated successfully, but these errors were encountered: