-
Notifications
You must be signed in to change notification settings - Fork 64
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
Improves Primitive Types #508
Conversation
49c5599
to
eb64e69
Compare
Ah, thanks for pointing that out @msujew ! Rebased on current work to get those changes in. The standard Correct me if I'm wrong here, but based on what I've seen I think actively setting of the value to |
@montymxb I guess the meta data generator for that is too strict. On the other hand, a union with a boolean property is quite weird from a parsing perspective IMO.
I will correct, since you are wrong ;-) The issue is that we don't know whether we will parse the |
Thanks for clarifying that point @msujew . With that in mind, I can focus on the |
Thought about |
@@ -45,10 +45,14 @@ export class DefaultValueConverter implements ValueConverter { | |||
case 'STRING': return convertString(input); | |||
case 'ID': return convertID(input); | |||
case 'REGEXLITERAL': return convertString(input); | |||
case 'BIGINT': return convertBigint(input); | |||
case 'DATE': return convertDate(input); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these two cases are not necessary because they are already handled by the return type below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah they're not critical, I can take them out. If they're desired for some reason, it would be easy to add them in later.
I figured they might be nice for shorter terminals, like terminal BIGINT: INT
instead of writing out terminal BIGINT returns bigint: INT
; based on what we have already for INT
. Since the same can be expressed with the return type, they don't add any expressiveness, just a shorthand equivalent.
This fixes #199 as well, right? |
@spoenemann yep! This PR closes #199 as well 👍 |
Closes #482 and Closes #199, by improving the primitive types present in Langium. In particular, this PR adds the
bigint
built-in type, along with an associated default value converter.In addition:
date
was changed toDate
to match the casing in typescript.bigint
andDate
Date
bigint
andDate
primitivesThere are some key points to note with this PR:
It is not recommended to parse date strings directly via the
Date()
constructor, but I have this in place for now as a proof of concept. I think it may be worth a little bit more work to recognize only ISO 8601 strings, or RFC 2822, a combination of the two, or some other approach that is safer. It could be as simple as deconstructing the date components and using another constructor on theDate
object instead.Booleans are still kind of odd, given that the values are either
true
for a successful parse orundefined
, rather thantrue
andfalse
. In the token builder tests, I noticed a test that builds a grammar that tries to capture a false value incorrectly. Specifically,Which can parse both true and false to produce a value of
true
. If you try to remove false from the regex to only recognize true, you run into the awkward situation of being unable to distinguish between false and a failed parse.Ultimately, my thought is whether I should expand this PR to allow boolean assignments to have the expected true/false values, instead of true/undefined.
Recognizing bigints is a little tricky, and so I've attempted to provide good examples in the tests of how this can be done properly. Lookahead and terminal ordering are both important to disambiguate between ints and bigints. Beyond that, they actually work pretty well!