Issue type
- [x] Feature Request
Wut
So, I'm actually pretty into @pjmolina 's typescript plugin from #514. However, at the end, it returns all.
I was hoping that you would help me cheat. I actually just want to write the signature to parse/1 slightly differently, by adding some kind of thing to the peg syntax that says "make this the return type of parse/1," and also by marking the in argument :string if there's an out type. Then, you'd just have to blindly typecast the last return value, et voila.
To a typescript (or flowtype) user, this would have a profound impact on checkability, even though it's fake.
How many cappucinos do I need to mail you in order to make this happen, and to what address would I send them
StoneCypher
All 8 comments
All I actually need is for the function's signature to be written like
function parse(input: string): MyType { ... }
(or whatever)
StoneCypher
on 31 Jan 2018
You can be inspired by this. Beforehand it is necessary to label types of all code blocks, it can be done with annotations. After this preparatory work it is possible to enter information on types in the generator.
Mingun
on 31 Jan 2018
@Mingun - this is interesting, but also very difficult to understand
Your annotation thing seems to be a near-ideal case here - that would allow the annotation of individual parsing rules with types, allowing the return of more than one real type
StoneCypher
on 1 Feb 2018
(The weird moment when I understood @Mingun is Russian too.)
Actually TypeScript won't make development of grammars any easier, because you have to annotate types everywhere, and because its type system is kinda broken. Recently I've made a small experiment on making a PEG.ts, and TypeScript's type checker spew such horrific error messages when I fed it with recursive types, that I couldn't even finish it.
I'd recommend to look rather into Infernu support.
polkovnikov-ph
on 1 Feb 2018
@polkovnikov-ph - yeah, that choice isn't in my hands, and besides, as a 1990s c++ template dev, typescript's error messages do not scare me
StoneCypher
on 1 Feb 2018
anyway, what i need is to be able to add parsers to a typescript system, so, it is of value to me to get typescript annotations out of parse/1
right now i'm doing it with gross master types and casting. i wish i could do better
StoneCypher
on 1 Feb 2018
Hi! Related to this, in the plugin ts-pegjs we have implemented optional output typing for production rules. Issue 11, PR 16
We did it using a table of pairs "rule-name": "return-type" via the returnTypes option.
I am cc you, just in case you decided to optionally add type information on pegjs at the DSL level to anonnate productions directly.
It could be quite useful for TypeScript output, also for Flow, or any other typed JS variant.
pjmolina
on 28 May 2018
People are still asking for this in #597
The new maintainer created and housed a .d.ts, so he's obviously open to typescript
This is a same-day "we have typescript" with no major changes, which can be done in five lines of code plus the replacement es6 module footer. I don't understand why it isn't being done
I have a patch ready against 0.11 but 0.11 isn't being merged, and 0.12 isn't available to work against
StoneCypher
on 3 Feb 2020
Related issues
dmajda
·
20Comments
Coffee2CodeNL
·
13Comments
dmajda
·
15Comments
audinue
·
13Comments
mreinstein
·
12Comments
Most helpful comment
Hi! Related to this, in the plugin
ts-pegjswe have implemented optional output typing for production rules. Issue 11, PR 16We did it using a table of pairs
"rule-name": "return-type"via thereturnTypesoption.I am cc you, just in case you decided to optionally add type information on pegjs at the DSL level to anonnate productions directly.
It could be quite useful for TypeScript output, also for Flow, or any other typed JS variant.