Skip to content
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

Go parser #54

Closed
zkat opened this issue Dec 26, 2020 · 9 comments
Closed

Go parser #54

zkat opened this issue Dec 26, 2020 · 9 comments
Labels
good first issue Good for newcomers help wanted Extra attention is needed implementations

Comments

@zkat
Copy link
Member

zkat commented Dec 26, 2020

We should have a nice golang parser for kdl. Hopefully we can also add it to the org!

@zkat zkat added help wanted Extra attention is needed good first issue Good for newcomers implementations labels Dec 26, 2020
@gcapizzi
Copy link

giving a go (heh) at this using https://github.com/alecthomas/participle, not sure I'll get anywhere, wish me luck! 😅

@zkat
Copy link
Member Author

zkat commented Dec 27, 2020

Good luck!

@gcapizzi
Copy link

Alright, I'm a bit stuck.

participle is quite rigid in terms of the ASTs that it can generate. In particular, it maps variants as structs with multiple fields, only one of which has a value. For example, to allow interleaved values and properties as arguments, we would have to add an Argument struct with Value and a Property fields. Same for the Value type.

It would be a lot nicer to have separate Values and Properties lists (just like in the Rust parser), but I don't think there's a good way to do this in participle 😞

I could try to handwrite a lexer and a parser, but I've never done it and I'm not sure I'd get to the bottom of it 😅
Alternatively, we could parse with participle and then convert the AST into the one we like. This would mean three passes though (lexing + parsing + "fixing" the AST).

I was also thinking that a tags-based solutions would be pretty nice (that's what the json package does for example). I don't think that would save us from building a more traditional AST-producing parser though (the json package has one, which produces map[string]interface{}s).

Thoughts?

@zkat
Copy link
Member Author

zkat commented Dec 29, 2020

I have never done Go so I don't really know what the best thing would be.

I will say, though, that I don't think parsing speed is that important as an initial goal, so "fixing" the AST seems ok to me?

@danderson
Copy link
Contributor

I just came across KDL, and as it happens it's exactly what I needed for a Go project of mine, for which I was in the middle of writing a parser for a custom language. I'm going to retool that to parse KDL instead.

I can't promise I'll get anywhere, so please don't view this as me planting a flag or anything, just broadcasting in case anyone else is interested in collaborating.

@binhonglee
Copy link

I got started working on this like yesterday so it only works on really small selection of cases. I've never worked on a parser before either, open to suggestions / PR etc.

https://github.com/binhonglee/kdl-go

@zhengpd
Copy link

zhengpd commented May 14, 2023

Both https://github.com/binhonglee/kdlgo and https://github.com/danderson/go-kdl are inactive since 2021. Are they abandoned?

@danderson
Copy link
Contributor

In my case, yes, sorry. I lost my use-case for KDL, and the time to build the library. My vague memory is that I had a pretty solid lexer, but no parser yet.

@Frixuu
Copy link

Frixuu commented Aug 26, 2023

No unmarshalling/marshalling yet, but I have somewhat of a working parser at https://github.com/Frixuu/KDLGo. Like above, I'm just putting it out there etc. etc. 😉

@zkat zkat closed this as completed Nov 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed implementations
Projects
None yet
Development

No branches or pull requests

6 participants