#parsers — Public Fediverse posts

Parsers don't have to be complicated

https://bkaradzic.github.io/posts/scanner/

Comments: https://news.ycombinator.com/item?id=49095943

#HackerNews #Parsers #Complicated #Programming #LanguageDesign #SoftwareDevelopment

Parsers don't have to be complicated

https://bkaradzic.github.io/posts/scanner/

Comments: https://news.ycombinator.com/item?id=49095943

#HackerNews #Parsers #Complicated #Programming #LanguageDesign #SoftwareDevelopment

Parsers don't have to be complicated

https://bkaradzic.github.io/posts/scanner/

Comments: https://news.ycombinator.com/item?id=49095943

#HackerNews #Parsers #Complicated #Programming #LanguageDesign #SoftwareDevelopment

Parsers don't have to be complicated

https://bkaradzic.github.io/posts/scanner/

Comments: https://news.ycombinator.com/item?id=49095943

#HackerNews #Parsers #Complicated #Programming #LanguageDesign #SoftwareDevelopment

Parsers don't have to be complicated

https://bkaradzic.github.io/posts/scanner/

Comments: https://news.ycombinator.com/item?id=49095943

#HackerNews #Parsers #Complicated #Programming #LanguageDesign #SoftwareDevelopment

Sigh... I guess I need to ask this now

So #rust programmers, how does one do errors in lossless parsing?

Context

I'm working on the new nu parser for nushell. The current strategy is to have a giant vector of so called NodeId s which in turn refer other indices within that vector, and ultimately build a parse "tree" using those NodeId (variants in the AstNode may contain other metadata too)

Now, we just created a dummy NodeId for errors and pushed them and continued to parse on our way. We want to have error-resilient parsing, so that we can cover more errors at other locations. If something's badly borked, well, we just barf.

So this worked well for us devs, because it kept things simple easy, but this is not how I'd really like to build the parse tree. There are multiple problems.

Right off the bat, we lose all the type information in one big ball of AstNode enum vector. So even though there are some places where you know that an AstNode would be of a particular kind, you simply cannot do anything about it except explicitly match and check (we want to avoid unsafe memory reinterprets).

As an aside, most of the enum is empty, but due to some variants, the entire enum becomes 48 bytes, so we waste a lot of memory on basically nothing.

My solution to this was to use bumpalo to do allocations and store references, and let go of the vector altogether and build an actual parse tree (like, a node with children, which have further children, and so on)

This is basically doing the vector, but not wasting space on the emptiness of the enums, not lose the types at runtime to the enum, and not have to do hacky index-chasing (which effectively act like pointers now). Instead, we use actual references, which we know will be valid till the end of the arena lifetime (three cheers for bumpalo!)

The Problem

As mentioned before, we had NodeId for errors as well, and those had a dummy span. Now, with the existence of a concrete parse tree, we have... no such thing. So we lose out on the ease of creating an error and attaching it wherever we want. In order to do things the earlier way, we have to make everything into an Result<insert_type_here, Error> which is very, very bad, because with that comes the indirect habit of using ? to bubble upwards, which is a problem because we want to find as big of a parsed expression with as small of an error context (we basically want to minimize how much we weren't able to parse, because that's what any good parser should do)

Right now, I don't really have any concrete ideas to attach errors to the nodes in the parse tree. So finally

Questions

• How does one do it? I'm looking for suggestions, although I don't really have anything concrete in my mind
• Would this actually lead to better performance? I expect it to be both faster and cheaper resource-wise. I'd argue yes, but I have no idea since it's a massive rewrite and doesn't even compile yet (:

Code snippets

// NOTE(bumpalo_rewrite): This becomes the root of the AST
// TODO(bumpalo_rewrite): Change to the generic enum that block may contain
#[derive(Debug, Clone)]
pub struct Block<'a> {
    pub span_start: usize,
    pub span_end: usize,
    pub nodes: Vec<BlockEntities<'a>>,
}

// TODO(bumpalo_rewrite): Fill with all the possible BlockEntities
// NOTE(bumpalo_rewrite): See Parser::block() for the entity types
#[derive(Debug, Clone)]
pub enum BlockEntities<'a> {
    Def(&'a Def<'a>),
    Let(&'a Let<'a>),
    While(&'a While<'a>),
    For(&'a For<'a>),
    Loop(&'a Loop<'a>),
    Return(&'a Return<'a>),
    Continue(&'a Continue),
    Break(&'a Break),
    Alias(&'a Alias),
    Extern(&'a Extern),
    PipelineOrExprOrAssign(PipelineOrExprOrAssign<'a>),
    Statement(PipelineOrExprOrAssign<'a>),
}

This is kind of what it is like right now. The function that parses a block:

            else if self.is_keyword(b"while") {
                match self.while_statement(arena) {
                    Some(while_) => {
                        code_body.push(BlockEntities::While(while_));
                    }
                    None => {}
                };
            }

has cases like these, where the error context is lost (ignore using Option instead of Result, I'm prototyping null

So really, how do I preserve the error contexts?

Git Repo

Here. You'd want to mostly look through the diff between this commit and the previous one in src/parser.rs

Any help is appreciated because I'm close to losing my mind lol XD

#programming #parsing #rust #errortolerance #compilers #parsers

Sigh... I guess I need to ask this now

So #rust programmers, how does one do errors in lossless parsing?

Context

I'm working on the new nu parser for nushell. The current strategy is to have a giant vector of so called NodeId s which in turn refer other indices within that vector, and ultimately build a parse "tree" using those NodeId (variants in the AstNode may contain other metadata too)

Now, we just created a dummy NodeId for errors and pushed them and continued to parse on our way. We want to have error-resilient parsing, so that we can cover more errors at other locations. If something's badly borked, well, we just barf.

So this worked well for us devs, because it kept things simple easy, but this is not how I'd really like to build the parse tree. There are multiple problems.

Right off the bat, we lose all the type information in one big ball of AstNode enum vector. So even though there are some places where you know that an AstNode would be of a particular kind, you simply cannot do anything about it except explicitly match and check (we want to avoid unsafe memory reinterprets).

As an aside, most of the enum is empty, but due to some variants, the entire enum becomes 48 bytes, so we waste a lot of memory on basically nothing.

My solution to this was to use bumpalo to do allocations and store references, and let go of the vector altogether and build an actual parse tree (like, a node with children, which have further children, and so on)

This is basically doing the vector, but not wasting space on the emptiness of the enums, not lose the types at runtime to the enum, and not have to do hacky index-chasing (which effectively act like pointers now). Instead, we use actual references, which we know will be valid till the end of the arena lifetime (three cheers for bumpalo!)

The Problem

As mentioned before, we had NodeId for errors as well, and those had a dummy span. Now, with the existence of a concrete parse tree, we have... no such thing. So we lose out on the ease of creating an error and attaching it wherever we want. In order to do things the earlier way, we have to make everything into an Result<insert_type_here, Error> which is very, very bad, because with that comes the indirect habit of using ? to bubble upwards, which is a problem because we want to find as big of a parsed expression with as small of an error context (we basically want to minimize how much we weren't able to parse, because that's what any good parser should do)

Right now, I don't really have any concrete ideas to attach errors to the nodes in the parse tree. So finally

Questions

• How does one do it? I'm looking for suggestions, although I don't really have anything concrete in my mind
• Would this actually lead to better performance? I expect it to be both faster and cheaper resource-wise. I'd argue yes, but I have no idea since it's a massive rewrite and doesn't even compile yet (:

Code snippets

// NOTE(bumpalo_rewrite): This becomes the root of the AST
// TODO(bumpalo_rewrite): Change to the generic enum that block may contain
#[derive(Debug, Clone)]
pub struct Block<'a> {
    pub span_start: usize,
    pub span_end: usize,
    pub nodes: Vec<BlockEntities<'a>>,
}

// TODO(bumpalo_rewrite): Fill with all the possible BlockEntities
// NOTE(bumpalo_rewrite): See Parser::block() for the entity types
#[derive(Debug, Clone)]
pub enum BlockEntities<'a> {
    Def(&'a Def<'a>),
    Let(&'a Let<'a>),
    While(&'a While<'a>),
    For(&'a For<'a>),
    Loop(&'a Loop<'a>),
    Return(&'a Return<'a>),
    Continue(&'a Continue),
    Break(&'a Break),
    Alias(&'a Alias),
    Extern(&'a Extern),
    PipelineOrExprOrAssign(PipelineOrExprOrAssign<'a>),
    Statement(PipelineOrExprOrAssign<'a>),
}

This is kind of what it is like right now. The function that parses a block:

            else if self.is_keyword(b"while") {
                match self.while_statement(arena) {
                    Some(while_) => {
                        code_body.push(BlockEntities::While(while_));
                    }
                    None => {}
                };
            }

has cases like these, where the error context is lost (ignore using Option instead of Result, I'm prototyping null

So really, how do I preserve the error contexts?

Git Repo

Here. You'd want to mostly look through the diff between this commit and the previous one in src/parser.rs

Any help is appreciated because I'm close to losing my mind lol XD

#programming #parsing #rust #errortolerance #compilers #parsers

Sigh... I guess I need to ask this now

So #rust programmers, how does one do errors in lossless parsing?

Context

I'm working on the new nu parser for nushell. The current strategy is to have a giant vector of so called NodeId s which in turn refer other indices within that vector, and ultimately build a parse "tree" using those NodeId (variants in the AstNode may contain other metadata too)

Now, we just created a dummy NodeId for errors and pushed them and continued to parse on our way. We want to have error-resilient parsing, so that we can cover more errors at other locations. If something's badly borked, well, we just barf.

So this worked well for us devs, because it kept things simple easy, but this is not how I'd really like to build the parse tree. There are multiple problems.

Right off the bat, we lose all the type information in one big ball of AstNode enum vector. So even though there are some places where you know that an AstNode would be of a particular kind, you simply cannot do anything about it except explicitly match and check (we want to avoid unsafe memory reinterprets).

As an aside, most of the enum is empty, but due to some variants, the entire enum becomes 48 bytes, so we waste a lot of memory on basically nothing.

My solution to this was to use bumpalo to do allocations and store references, and let go of the vector altogether and build an actual parse tree (like, a node with children, which have further children, and so on)

This is basically doing the vector, but not wasting space on the emptiness of the enums, not lose the types at runtime to the enum, and not have to do hacky index-chasing (which effectively act like pointers now). Instead, we use actual references, which we know will be valid till the end of the arena lifetime (three cheers for bumpalo!)

The Problem

As mentioned before, we had NodeId for errors as well, and those had a dummy span. Now, with the existence of a concrete parse tree, we have... no such thing. So we lose out on the ease of creating an error and attaching it wherever we want. In order to do things the earlier way, we have to make everything into an Result<insert_type_here, Error> which is very, very bad, because with that comes the indirect habit of using ? to bubble upwards, which is a problem because we want to find as big of a parsed expression with as small of an error context (we basically want to minimize how much we weren't able to parse, because that's what any good parser should do)

Right now, I don't really have any concrete ideas to attach errors to the nodes in the parse tree. So finally

Questions

• How does one do it? I'm looking for suggestions, although I don't really have anything concrete in my mind
• Would this actually lead to better performance? I expect it to be both faster and cheaper resource-wise. I'd argue yes, but I have no idea since it's a massive rewrite and doesn't even compile yet (:

Code snippets

// NOTE(bumpalo_rewrite): This becomes the root of the AST
// TODO(bumpalo_rewrite): Change to the generic enum that block may contain
#[derive(Debug, Clone)]
pub struct Block<'a> {
    pub span_start: usize,
    pub span_end: usize,
    pub nodes: Vec<BlockEntities<'a>>,
}

// TODO(bumpalo_rewrite): Fill with all the possible BlockEntities
// NOTE(bumpalo_rewrite): See Parser::block() for the entity types
#[derive(Debug, Clone)]
pub enum BlockEntities<'a> {
    Def(&'a Def<'a>),
    Let(&'a Let<'a>),
    While(&'a While<'a>),
    For(&'a For<'a>),
    Loop(&'a Loop<'a>),
    Return(&'a Return<'a>),
    Continue(&'a Continue),
    Break(&'a Break),
    Alias(&'a Alias),
    Extern(&'a Extern),
    PipelineOrExprOrAssign(PipelineOrExprOrAssign<'a>),
    Statement(PipelineOrExprOrAssign<'a>),
}

This is kind of what it is like right now. The function that parses a block:

            else if self.is_keyword(b"while") {
                match self.while_statement(arena) {
                    Some(while_) => {
                        code_body.push(BlockEntities::While(while_));
                    }
                    None => {}
                };
            }

has cases like these, where the error context is lost (ignore using Option instead of Result, I'm prototyping null

So really, how do I preserve the error contexts?

Git Repo

Here. You'd want to mostly look through the diff between this commit and the previous one in src/parser.rs

Any help is appreciated because I'm close to losing my mind lol XD

#programming #parsing #rust #errortolerance #compilers #parsers

Sigh... I guess I need to ask this now

So #rust programmers, how does one do errors in lossless parsing?

Context

I'm working on the new nu parser for nushell. The current strategy is to have a giant vector of so called NodeId s which in turn refer other indices within that vector, and ultimately build a parse "tree" using those NodeId (variants in the AstNode may contain other metadata too)

Now, we just created a dummy NodeId for errors and pushed them and continued to parse on our way. We want to have error-resilient parsing, so that we can cover more errors at other locations. If something's badly borked, well, we just barf.

So this worked well for us devs, because it kept things simple easy, but this is not how I'd really like to build the parse tree. There are multiple problems.

Right off the bat, we lose all the type information in one big ball of AstNode enum vector. So even though there are some places where you know that an AstNode would be of a particular kind, you simply cannot do anything about it except explicitly match and check (we want to avoid unsafe memory reinterprets).

As an aside, most of the enum is empty, but due to some variants, the entire enum becomes 48 bytes, so we waste a lot of memory on basically nothing.

My solution to this was to use bumpalo to do allocations and store references, and let go of the vector altogether and build an actual parse tree (like, a node with children, which have further children, and so on)

This is basically doing the vector, but not wasting space on the emptiness of the enums, not lose the types at runtime to the enum, and not have to do hacky index-chasing (which effectively act like pointers now). Instead, we use actual references, which we know will be valid till the end of the arena lifetime (three cheers for bumpalo!)

The Problem

As mentioned before, we had NodeId for errors as well, and those had a dummy span. Now, with the existence of a concrete parse tree, we have... no such thing. So we lose out on the ease of creating an error and attaching it wherever we want. In order to do things the earlier way, we have to make everything into an Result<insert_type_here, Error> which is very, very bad, because with that comes the indirect habit of using ? to bubble upwards, which is a problem because we want to find as big of a parsed expression with as small of an error context (we basically want to minimize how much we weren't able to parse, because that's what any good parser should do)

Right now, I don't really have any concrete ideas to attach errors to the nodes in the parse tree. So finally

Questions

• How does one do it? I'm looking for suggestions, although I don't really have anything concrete in my mind
• Would this actually lead to better performance? I expect it to be both faster and cheaper resource-wise. I'd argue yes, but I have no idea since it's a massive rewrite and doesn't even compile yet (:

Code snippets

// NOTE(bumpalo_rewrite): This becomes the root of the AST
// TODO(bumpalo_rewrite): Change to the generic enum that block may contain
#[derive(Debug, Clone)]
pub struct Block<'a> {
    pub span_start: usize,
    pub span_end: usize,
    pub nodes: Vec<BlockEntities<'a>>,
}

// TODO(bumpalo_rewrite): Fill with all the possible BlockEntities
// NOTE(bumpalo_rewrite): See Parser::block() for the entity types
#[derive(Debug, Clone)]
pub enum BlockEntities<'a> {
    Def(&'a Def<'a>),
    Let(&'a Let<'a>),
    While(&'a While<'a>),
    For(&'a For<'a>),
    Loop(&'a Loop<'a>),
    Return(&'a Return<'a>),
    Continue(&'a Continue),
    Break(&'a Break),
    Alias(&'a Alias),
    Extern(&'a Extern),
    PipelineOrExprOrAssign(PipelineOrExprOrAssign<'a>),
    Statement(PipelineOrExprOrAssign<'a>),
}

This is kind of what it is like right now. The function that parses a block:

            else if self.is_keyword(b"while") {
                match self.while_statement(arena) {
                    Some(while_) => {
                        code_body.push(BlockEntities::While(while_));
                    }
                    None => {}
                };
            }

has cases like these, where the error context is lost (ignore using Option instead of Result, I'm prototyping null

So really, how do I preserve the error contexts?

Git Repo

Here. You'd want to mostly look through the diff between this commit and the previous one in src/parser.rs

Any help is appreciated because I'm close to losing my mind lol XD

#programming #parsing #rust #errortolerance #compilers #parsers

Babby's first recursive descent parser. At least I think this is one?

https://git.ahlcode.fi/nicd/kielet/src/branch/trunk/src/kielet/plurals

#Gettext #Parsers #FunctionalProgramming #Gleam

Babby's first recursive descent parser. At least I think this is one?

https://git.ahlcode.fi/nicd/kielet/src/branch/trunk/src/kielet/plurals

#Gettext #Parsers #FunctionalProgramming #Gleam

Babby's first recursive descent parser. At least I think this is one?

https://git.ahlcode.fi/nicd/kielet/src/branch/trunk/src/kielet/plurals

#Gettext #Parsers #FunctionalProgramming #Gleam

Babby's first recursive descent parser. At least I think this is one?

https://git.ahlcode.fi/nicd/kielet/src/branch/trunk/src/kielet/plurals

#Gettext #Parsers #FunctionalProgramming #Gleam

Babby's first recursive descent parser. At least I think this is one?

https://git.ahlcode.fi/nicd/kielet/src/branch/trunk/src/kielet/plurals

#Gettext #Parsers #FunctionalProgramming #Gleam

David Nolen on Parsing With Derivatives (2016)

https://www.youtube.com/watch?v=FKiEsJiTMtI

#derivatives #programminglanguages #parsers

David Nolen on Parsing With Derivatives (2016)

https://www.youtube.com/watch?v=FKiEsJiTMtI

#derivatives #programminglanguages #parsers

David Nolen on Parsing With Derivatives (2016)

https://www.youtube.com/watch?v=FKiEsJiTMtI

#derivatives #programminglanguages #parsers

David Nolen on Parsing With Derivatives (2016)

https://www.youtube.com/watch?v=FKiEsJiTMtI

#derivatives #programminglanguages #parsers

David Nolen on Parsing With Derivatives (2016)

https://www.youtube.com/watch?v=FKiEsJiTMtI

#derivatives #programminglanguages #parsers

New instance, new #introduction, right?

Hi there! I'm Vito! 30-something self-taught computer #engineer ✨
I currently live in São Paulo, Brazil, with plans to move to Italy some time in the future. Maybe.

I have a reeeally deep interest in #parsers, #interpreters & #compilers, but I'm also using my free time to build computers from scratch based on architectures from the 70's, 80's, and 90's, and some other projects, sometimes around #retrocomputing.

I'm usually using Macs (#Mac Studio Ultra/M4 #MacBook Pro <3) I also have a large #ESXi host hosting a lot of VMs and a "bare-metal" K8s cluster, but I've been a long-time user of #BSD and #Linux! <3

If I follow you, I will end up interacting with your toots in some way! Either boosting, replying, or favouriting them! Please do let me know in case any of that makes you uncomfortable!

Also feel free to let me know in case I missed a CW, Alt, or said something wrong or technically incorrect!

I think that's about it! Thanks for reading! Have a nice day! 🌻 :floofHeart:

New instance, new #introduction, right?

Hi there! I'm Vito! 30-something self-taught computer #engineer ✨
I currently live in São Paulo, Brazil, with plans to move to Italy some time in the future. Maybe.

I have a reeeally deep interest in #parsers, #interpreters & #compilers, but I'm also using my free time to build computers from scratch based on architectures from the 70's, 80's, and 90's, and some other projects, sometimes around #retrocomputing.

I'm usually using Macs (#Mac Studio Ultra/M4 #MacBook Pro <3) I also have a large #ESXi host hosting a lot of VMs and a "bare-metal" K8s cluster, but I've been a long-time user of #BSD and #Linux! <3

If I follow you, I will end up interacting with your toots in some way! Either boosting, replying, or favouriting them! Please do let me know in case any of that makes you uncomfortable!

Also feel free to let me know in case I missed a CW, Alt, or said something wrong or technically incorrect!

I think that's about it! Thanks for reading! Have a nice day! 🌻 :floofHeart:

New instance, new #introduction, right?

Hi there! I'm Vito! 30-something self-taught computer #engineer ✨
I currently live in São Paulo, Brazil, with plans to move to Italy some time in the future. Maybe.

I have a reeeally deep interest in #parsers, #interpreters & #compilers, but I'm also using my free time to build computers from scratch based on architectures from the 70's, 80's, and 90's, and some other projects, sometimes around #retrocomputing.

I'm usually using Macs (#Mac Studio Ultra/M4 #MacBook Pro <3) I also have a large #ESXi host hosting a lot of VMs and a "bare-metal" K8s cluster, but I've been a long-time user of #BSD and #Linux! <3

If I follow you, I will end up interacting with your toots in some way! Either boosting, replying, or favouriting them! Please do let me know in case any of that makes you uncomfortable!

Also feel free to let me know in case I missed a CW, Alt, or said something wrong or technically incorrect!

I think that's about it! Thanks for reading! Have a nice day! 🌻 :floofHeart:

New instance, new #introduction, right?

Hi there! I'm Vito! 30-something self-taught computer #engineer ✨
I currently live in São Paulo, Brazil, with plans to move to Italy some time in the future. Maybe.

I have a reeeally deep interest in #parsers, #interpreters & #compilers, but I'm also using my free time to build computers from scratch based on architectures from the 70's, 80's, and 90's, and some other projects, sometimes around #retrocomputing.

I'm usually using Macs (#Mac Studio Ultra/M4 #MacBook Pro <3) I also have a large #ESXi host hosting a lot of VMs and a "bare-metal" K8s cluster, but I've been a long-time user of #BSD and #Linux! <3

If I follow you, I will end up interacting with your toots in some way! Either boosting, replying, or favouriting them! Please do let me know in case any of that makes you uncomfortable!

Also feel free to let me know in case I missed a CW, Alt, or said something wrong or technically incorrect!

I think that's about it! Thanks for reading! Have a nice day! 🌻 :floofHeart:

New instance, new #introduction, right?

Hi there! I'm Vito! 30-something self-taught computer #engineer ✨
I currently live in São Paulo, Brazil, with plans to move to Italy some time in the future. Maybe.

I have a reeeally deep interest in #parsers, #interpreters & #compilers, but I'm also using my free time to build computers from scratch based on architectures from the 70's, 80's, and 90's, and some other projects, sometimes around #retrocomputing.

I'm usually using Macs (#Mac Studio Ultra/M4 #MacBook Pro <3) I also have a large #ESXi host hosting a lot of VMs and a "bare-metal" K8s cluster, but I've been a long-time user of #BSD and #Linux! <3

If I follow you, I will end up interacting with your toots in some way! Either boosting, replying, or favouriting them! Please do let me know in case any of that makes you uncomfortable!

Also feel free to let me know in case I missed a CW, Alt, or said something wrong or technically incorrect!

I think that's about it! Thanks for reading! Have a nice day! 🌻 :floofHeart:

Finally released a new YAMD parser, which unlocked nice errors in Bar https://barhamon.com/post/Bar%200.2.0.html.

I had this idea after reading https://craftinginterpreters.com (the best technical book I have read, highly recommend).

#parsers #markdown #ssg

Finally released a new YAMD parser, which unlocked nice errors in Bar https://barhamon.com/post/Bar%200.2.0.html.

I had this idea after reading https://craftinginterpreters.com (the best technical book I have read, highly recommend).

#parsers #markdown #ssg

Finally released a new YAMD parser, which unlocked nice errors in Bar https://barhamon.com/post/Bar%200.2.0.html.

I had this idea after reading https://craftinginterpreters.com (the best technical book I have read, highly recommend).

#parsers #markdown #ssg

Finally released a new YAMD parser, which unlocked nice errors in Bar https://barhamon.com/post/Bar%200.2.0.html.

I had this idea after reading https://craftinginterpreters.com (the best technical book I have read, highly recommend).

#parsers #markdown #ssg

Lattelua — когда Lua уже мало

Если вы хоть раз встраивали Lua в свой проект — будь то игровой движок, высоконагруженный веб-сервер на OpenResty или конфигуратор сложного сетевого оборудования — вы знаете, за что мы его любим:) А любим мы его — за компактность, быстроту, встраиваемость и предсказуемость. Не любим — за аскетичный синтаксис, отсутствие привычных конструкций и постоянное «изобретение велосипеда». Эта статья — обзор диалекта Lattelua : зачем он нужен, чем отличается от других диалектов, и почему его особенно удобно использовать в уже существующих проектах, где Lua — встраиваемый язык. Погнали

https://habr.com/ru/articles/1011614/

#Lua #moonscript #AST #parsers

Lattelua — когда Lua уже мало

Если вы хоть раз встраивали Lua в свой проект — будь то игровой движок, высоконагруженный веб-сервер на OpenResty или конфигуратор сложного сетевого оборудования — вы знаете, за что мы его любим:) А любим мы его — за компактность, быстроту, встраиваемость и предсказуемость. Не любим — за аскетичный синтаксис, отсутствие привычных конструкций и постоянное «изобретение велосипеда». Эта статья — обзор диалекта Lattelua : зачем он нужен, чем отличается от других диалектов, и почему его особенно удобно использовать в уже существующих проектах, где Lua — встраиваемый язык. Погнали

https://habr.com/ru/articles/1011614/

#Lua #moonscript #AST #parsers

Lattelua — когда Lua уже мало

Если вы хоть раз встраивали Lua в свой проект — будь то игровой движок, высоконагруженный веб-сервер на OpenResty или конфигуратор сложного сетевого оборудования — вы знаете, за что мы его любим:) А любим мы его — за компактность, быстроту, встраиваемость и предсказуемость. Не любим — за аскетичный синтаксис, отсутствие привычных конструкций и постоянное «изобретение велосипеда». Эта статья — обзор диалекта Lattelua : зачем он нужен, чем отличается от других диалектов, и почему его особенно удобно использовать в уже существующих проектах, где Lua — встраиваемый язык. Погнали

https://habr.com/ru/articles/1011614/

#Lua #moonscript #AST #parsers

“Explainer: Tree-sitter Vs. LSP”, Ashton Wiersdorf (https://lambdaland.org/posts/2026-01-21_tree-sitter_vs_lsp/).

Via HN: https://news.ycombinator.com/item?id=46719899

On Lobsters: https://lobste.rs/s/qhickw/explainer_tree_sitter_vs_lsp

#LSP #TreeSitter #LanguageServerProtocol #Editors #SyntaxHighlighting #Parsers #Parsing

“Explainer: Tree-sitter Vs. LSP”, Ashton Wiersdorf (https://lambdaland.org/posts/2026-01-21_tree-sitter_vs_lsp/).

Via HN: https://news.ycombinator.com/item?id=46719899

On Lobsters: https://lobste.rs/s/qhickw/explainer_tree_sitter_vs_lsp

#LSP #TreeSitter #LanguageServerProtocol #Editors #SyntaxHighlighting #Parsers #Parsing

“Explainer: Tree-sitter Vs. LSP”, Ashton Wiersdorf (https://lambdaland.org/posts/2026-01-21_tree-sitter_vs_lsp/).

Via HN: https://news.ycombinator.com/item?id=46719899

On Lobsters: https://lobste.rs/s/qhickw/explainer_tree_sitter_vs_lsp

#LSP #TreeSitter #LanguageServerProtocol #Editors #SyntaxHighlighting #Parsers #Parsing

“Explainer: Tree-sitter Vs. LSP”, Ashton Wiersdorf (https://lambdaland.org/posts/2026-01-21_tree-sitter_vs_lsp/).

Via HN: https://news.ycombinator.com/item?id=46719899

On Lobsters: https://lobste.rs/s/qhickw/explainer_tree_sitter_vs_lsp

#LSP #TreeSitter #LanguageServerProtocol #Editors #SyntaxHighlighting #Parsers #Parsing

Daedalus: Safer Document #Parsing

#parsers

https://dl.acm.org/doi/10.1145/3656410

Daedalus: Safer Document #Parsing

#parsers

https://dl.acm.org/doi/10.1145/3656410

Daedalus: Safer Document #Parsing

#parsers

https://dl.acm.org/doi/10.1145/3656410

Daedalus: Safer Document #Parsing

#parsers

https://dl.acm.org/doi/10.1145/3656410

Daedalus: Safer Document #Parsing

#parsers

https://dl.acm.org/doi/10.1145/3656410

How SQL Parsers Work

https://nishchith.com/sql-parsers/

#HackerNews #SQL #Parsers #SQL #Programming #Tech #Explained #Data #Parsing #Database

How SQL Parsers Work

https://nishchith.com/sql-parsers/

#HackerNews #SQL #Parsers #SQL #Programming #Tech #Explained #Data #Parsing #Database

How SQL Parsers Work

https://nishchith.com/sql-parsers/

#HackerNews #SQL #Parsers #SQL #Programming #Tech #Explained #Data #Parsing #Database

How SQL Parsers Work

https://nishchith.com/sql-parsers/

#HackerNews #SQL #Parsers #SQL #Programming #Tech #Explained #Data #Parsing #Database

How SQL Parsers Work

https://nishchith.com/sql-parsers/

#HackerNews #SQL #Parsers #SQL #Programming #Tech #Explained #Data #Parsing #Database

Why #Lexing and #Parsing Should Be Separate

"Summary: Do the easy thing with the fast algorithm, and the hard thing with the slow algorithm. Lexing and parsing are different things."

#parsers

https://github.com/oils-for-unix/oils/wiki/Why-Lexing-and-Parsing-Should-Be-Separate

Why #Lexing and #Parsing Should Be Separate

"Summary: Do the easy thing with the fast algorithm, and the hard thing with the slow algorithm. Lexing and parsing are different things."

#parsers

https://github.com/oils-for-unix/oils/wiki/Why-Lexing-and-Parsing-Should-Be-Separate

Why #Lexing and #Parsing Should Be Separate

"Summary: Do the easy thing with the fast algorithm, and the hard thing with the slow algorithm. Lexing and parsing are different things."

#parsers

https://github.com/oils-for-unix/oils/wiki/Why-Lexing-and-Parsing-Should-Be-Separate

Why #Lexing and #Parsing Should Be Separate

"Summary: Do the easy thing with the fast algorithm, and the hard thing with the slow algorithm. Lexing and parsing are different things."

#parsers

https://github.com/oils-for-unix/oils/wiki/Why-Lexing-and-Parsing-Should-Be-Separate

Why #Lexing and #Parsing Should Be Separate

"Summary: Do the easy thing with the fast algorithm, and the hard thing with the slow algorithm. Lexing and parsing are different things."

#parsers

https://github.com/oils-for-unix/oils/wiki/Why-Lexing-and-Parsing-Should-Be-Separate

"We propose to re-think data management system parser design to create modern, extensible #parsers, which allow a dynamic configuration of the accepted syntax at run-time, for example to allow syntax extensions, new statements, or to add entirely new query languages."

#duckdb

https://duckdb.org/2024/11/22/runtime-extensible-parsers

"We propose to re-think data management system parser design to create modern, extensible #parsers, which allow a dynamic configuration of the accepted syntax at run-time, for example to allow syntax extensions, new statements, or to add entirely new query languages."

#duckdb

https://duckdb.org/2024/11/22/runtime-extensible-parsers

"We propose to re-think data management system parser design to create modern, extensible #parsers, which allow a dynamic configuration of the accepted syntax at run-time, for example to allow syntax extensions, new statements, or to add entirely new query languages."

#duckdb

https://duckdb.org/2024/11/22/runtime-extensible-parsers

"We propose to re-think data management system parser design to create modern, extensible #parsers, which allow a dynamic configuration of the accepted syntax at run-time, for example to allow syntax extensions, new statements, or to add entirely new query languages."

#duckdb

https://duckdb.org/2024/11/22/runtime-extensible-parsers

"We propose to re-think data management system parser design to create modern, extensible #parsers, which allow a dynamic configuration of the accepted syntax at run-time, for example to allow syntax extensions, new statements, or to add entirely new query languages."

#duckdb

https://duckdb.org/2024/11/22/runtime-extensible-parsers

"Parsing SQL queries provide superpowers for monitoring data health. This post elaborates on how to get started with parsing SQL for data observability."

#opensource #sql #parsers #computerscience

https://tokern.io/blog/open-source-sql-parsers/