Add a simple example without Langium#59
Conversation
JohannesMeierSE
left a comment
There was a problem hiding this comment.
Thank you @Lotes for this nice application example without Langium!
A general remark: Since this example is for demonstration, I suggest to add more comments:
- Add a
README.mdwhich describes the purpose and the interesting parts of this application of Typir. - Document the features/concepts of your DSL (at the moment you need to look into the implementation
- Give readers a hint, how they can experiment with your DSL, e.g. point them to your test cases.
- Add one or two sentences as comments into each of the five
src/*.tsfiles to describe their purpose. That will help people who never wrote a parser themselves to get the ideas of the files.
Ideas for more validations:
VAR X = 2 * "hello";should fail- Introduce an AssignmentStatement and check asignability of left- and right-hand side
If you plan to add a generator, maybe these ideas are helpful:
- Keep it as simple as possible, I like the slim design of the current state of your example!
- Make the implicit conversions (number as string) in the generated code explicit, since here the type system is very helpful (the assignability service returns the conversion path now!)
JohannesMeierSE
left a comment
There was a problem hiding this comment.
Thanks a lot @Lotes for your example! The additional comments, diagrams and test cases are really helpful!
|
|
||
| typir.validation.Collector.addValidationRule((node) => { | ||
| if(isAssignment(node)) { | ||
| const left = typir.Inference.inferType(node.variable); |
There was a problem hiding this comment.
You could write this shorter in this way:
return typir.validation.Constraints.ensureNodeIsAssignable(node.value, node.variable, (actual, expected) => <ValidationMessageDetails>{
languageNode: node, severity: 'error', message: `'${actual.name}' is not assignable to '${expected.name}'.`,
});But it is also interesting to the see the implementation behind 🙂
| @@ -0,0 +1,141 @@ | |||
| /****************************************************************************** | |||
There was a problem hiding this comment.
An idea: For the examples OX and LOX, we use the prefixes ox- and lox- for the typescript files. Does it makes sense to have a similar prefix (maybe expr- or expressions-) for your expressions examples as well?
9f2257f to
5c952df
Compare
|
@insafuhrmann As discussed, I updated this PR according my own comments above. Could you review the update therefore? |
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
Signed-off-by: Markus Rudolph <markus.rudolph@typefox.io>
5c952df to
d84f7da
Compare
insafuhrmann
left a comment
There was a problem hiding this comment.
Thanks for the additions and adjustments @JohannesMeierSE! They look good and helpful to me.
I think this is ready to be merged now.
Thanks @Lotes for the contribution of this great new example!
I wrote a simple handwritten expression parser.
It has:
print 123;var index = 123;print index+1;+,-,*,/and%+and-It worked good so far, even the desired validations I get for free :-) .
Currently there is not much, that can go wrong. Only operators that are not overloaded like
string * stringcause troubles.Maybe one of you has more ideas, what to add on top for testing or for language features.
For sure I can add parentheses expressions or assignments in order to make the language "round & sound".
In the end I just wanted to have something framework-agnostic and I think this was proven.