Example nanorust parser does not work. about chumsky HOT 13 CLOSED

Also, I am curious about writing semantic analyzer with Chumsky. Is it feasible?

I will be writing an analyzer for SQL for my bachelor’s thesis using Chumsky for the parser, so I sure hope so ;)

from chumsky.

Also, I am curious about writing semantic analyzer with Chumsky. Is it feasible?

from chumsky.

Hi, thank you for this excellent crate chumsky.

I was trying the nanorust parser but to my disappointment, I was unable to compile it right away. extra and Rich identifiers were missing and I couldn't find them in chunsky or ariadne.

Thank you.

The example runs with the 1.0.0-alpha.4 version, so make sure that in your Cargo.toml that you aren’t using 0.9.2

from chumsky.

I was trying the nanorust parser but to my disappointment, I was unable to compile it right away.

You'll need to do cargo run --example nano_rust --features label -- examples/sample.nrs

from chumsky.

I was trying the nanorust parser but to my disappointment, I was unable to compile it right away.

You'll need to do cargo run --example nano_rust --features label -- examples/sample.nrs

Thank you for your reply. But it still gives me the error that it cannot find extra; https://github.com/zesterer/chumsky/blob/main/examples/nano_rust.rs#L48.

from chumsky.

Hi, thank you for this excellent crate chumsky.
I was trying the nanorust parser but to my disappointment, I was unable to compile it right away. extra and Rich identifiers were missing and I couldn't find them in chunsky or ariadne.
Thank you.

The example runs with the 1.0.0-alpha.4 version, so make sure that in your Cargo.toml that you aren’t using 0.9.2

Yeah, I am using 0.9.2 whereas the example using --features label which is something in 1.0.0-alpha.4 version, I guess I should point to git in my Cargo.toml.

from chumsky.

Yes, or you can just use chumsky = 1.0.0-alpha.4 in your [dependencies] section. 1.0 is a complete rewrite of the crate, with many improvements and breaking changes, so you should not expect code to work between it and 0.9.

from chumsky.

Yes, or you can just use chumsky = 1.0.0-alpha.4 in your [dependencies] section. 1.0 is a complete rewrite of the crate, with many improvements and breaking changes, so you should not expect code to work between it and 0.9.

Cool, love it @zesterer. Thanks for your awesome and prompt response!

Do you write blogs? Because I would love to learn more on your journey that led you to writing this awesome crate.

Do you have any advice on semantic analyzer? Because for any language (interpreted or compiled), I guess the hardest part is the semantic analyzer.

from chumsky.

Do you write blogs? Because I would love to learn more on your journey that led you to writing this awesome crate.

Chumsky is mostly just a regular parser combinator library, albeit with some fancy stuff going on to support zero-copy parsing and good error generation. If you search around for information about parser combinators you'll likely find some good resources.

Do you have any advice on semantic analyzer? Because for any language (interpreted or compiled), I guess the hardest part is the semantic analyzer.

That depends on the semantics you want to analyse! Checking types is the most common thing to want. Is there anything more you're looking for?

from chumsky.

Do you write blogs? Because I would love to learn more on your journey that led you to writing this awesome crate.

Chumsky is mostly just a regular parser combinator library, albeit with some fancy stuff going on to support zero-copy parsing and good error generation. If you search around for information about parser combinators you'll likely find some good resources.

Do you have any advice on semantic analyzer? Because for any language (interpreted or compiled), I guess the hardest part is the semantic analyzer.

That depends on the semantics you want to analyse! Checking types is the most common thing to want. Is there anything more you're looking for?

Yes, I would say type checking is definitely the most important aspect of semantic analyzer.

I am trying to build a scripting language to automate some cryptocurrency trading. So it can be like

let addr: H160 = "0xSTMT"

Where H160 stands for 160 bits value, i.e. 20 bytes, in hex representation it will be 40 hex characters long after the 0x prefix.

Hoping these can be inbuilt fundamental types that the type checker can enforce. Any suggestions on how I can kickstart this?

Eventually, the interpreter will have to serialize it and broadcast the bytes value to the network.

from chumsky.

You'll first want to come up with a design for the type-checker. A simple C-like type-checker is relatively easy to implement: it's just a matter of recursing over the AST, deriving a type for each term, and checking it against its use. More complex cases can involve type inference and might require more advanced approaches, such as Hindley-Milner and bidirectional typechecking.

from chumsky.

You'll first want to come up with a design for the type-checker. A simple C-like type-checker is relatively easy to implement: it's just a matter of recursing over the AST, deriving a type for each term, and checking it against its use. More complex cases can involve type inference and might require more advanced approaches, such as Hindley-Milner and bidirectional typechecking.

Thank you for your response and I will heed your advice diligently.

On https://github.com/zesterer/chumsky/blob/main/examples/nano_rust.rs#L587, what exactly is (src.len()..src.len() doing?

I think this is exactly one of the downsides of traits, when the type information is lost and all we know is the input requires a type that implements Input trait, it is sometimes very difficult to know what the trait requires and what types actually implement it.

from chumsky.

This is where rustdoc is helpful - take a look at https://docs.rs/chumsky/1.0.0-alpha.4/chumsky/input/trait.Input.html, the documentation describes the concepts, and at the bottom of the page it lists types that implement it.

As for the original question, src.len()..src.len() is creating a range of length zero, representing the end-of-input span, used when a parser needs a span but consumes no input.

from chumsky.