mastodon.ie is one of the many independent Mastodon servers you can use to participate in the fediverse.
Irish Mastodon - run from Ireland, we welcome all who respect the community rules and members.

Administered by:

Server stats:

1.5K
active users

#parser

0 posts0 participants0 posts today
jnpn<p><a href="https://tratt.net/laurie/blog/2020/automatic_syntax_error_recovery.html" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">tratt.net/laurie/blog/2020/aut</span><span class="invisible">omatic_syntax_error_recovery.html</span></a></p><p><a href="https://mastodon.social/tags/grammar" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>grammar</span></a> <a href="https://mastodon.social/tags/cfg" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>cfg</span></a> <a href="https://mastodon.social/tags/parser" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>parser</span></a> <a href="https://mastodon.social/tags/error" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>error</span></a></p>
Abhinav 🌏<p>I'm starting a series of blog posts, in which I write a <a href="https://fantastic.earth/tags/bytecode" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>bytecode</span></a> <a href="https://fantastic.earth/tags/compiler" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>compiler</span></a> and a <a href="https://fantastic.earth/tags/virtualMachine" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>virtualMachine</span></a> for arithmetic in <a href="https://fantastic.earth/tags/Haskell" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Haskell</span></a>. We explore the following topics in the series:</p><p>- Parsing arithmetic expressions to ASTs.<br>- Compiling ASTs to bytecode.<br>- Interpreting ASTs.<br>- Efficiently executing bytecode in a VM.<br>- Disassembling bytecode and decompiling opcodes for debugging and testing.<br>- Unit testing and property-based testing for our compiler and VM.<br>- Benchmarking our code to see how the different passes perform.<br>- All the while keeping an eye on performance.</p><p>The first post of the series that focuses on writing the <a href="https://fantastic.earth/tags/parser" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>parser</span></a> is now out: <a href="https://abhinavsarkar.net/posts/arithmetic-bytecode-vm-parser/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">abhinavsarkar.net/posts/arithm</span><span class="invisible">etic-bytecode-vm-parser/</span></a></p><p><a href="https://fantastic.earth/tags/programming" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>programming</span></a> <a href="https://fantastic.earth/tags/Blogging" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Blogging</span></a> <a href="https://fantastic.earth/tags/compilers" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>compilers</span></a> <a href="https://fantastic.earth/tags/programmingLanguages" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>programmingLanguages</span></a></p>

Okay, added a few more features and I'm really liking the results. I added the `-` operator for `dice_groups` which was a bit more tricky than I thought it'd be. I also added the ability to roll a dice group multiple times via a `x`|`*` operator. I removed the requirement that a dice group has to have a damage type associated with it since the only way you can roll something like `1d4-1` is in a dice group since there is a minimum value of 1 associated with it.

The code lives here: codeberg.org/JamesTheBard/dice

#python#lark#parser

Okay, _now_ I'm done. Fixed a few parser errors and implemented a skew option (the `^` value) that will push the average value towards either 1 or the maximum of the dice. I like that once you get the parser up and running that it's easy to add stuff to it. I now am the official owner of a completely overkill dice running program.

For the example below, the skew is `2.0`. The random value is raised to the `1/skew` power before being multiplied by the number of sides of the die. If skew goes up, so do the results. If skew goes down, well, so do the results.

```
$ python main.py "^2 (2d6+2d8+12)[fire]+1d8[piercing]" | jq .
{
"results": {
"fire": 37,
"piercing": 7
}
}
```

Before starting the big work of porting my experimental #LiveCoding #uzulang #godwit 's #parser from #Alex and #Happy to #Parsec, I finally managed to get a snapshot working in #Termux on my phone by making a tarball including the generated #Haskell files on a machine where Alex and Happy were available and transferring it over network.

This isn't ideal as I can't edit the parser on my phone (no Alex/Happy there; at least not recent enough versions, old ones got via cjacker's Hugs 2019 improvement), so I still want to switch to Parsec which is not so horribly #GHC -only (Parsec has a version that works with #MicroHs and probably #Hugs #HaskellHugs too).

I put the snapshot at
mathr.co.uk/web/godwit.html#Do and meanwhile updated the bootstrap script as patching MicroHs isn't necessary any more.

mathr.co.ukGodwit :: mathrExperimental pattern live-coding system inspired by Tidal.

Any #TOML nerds? Would you say this is valid TOML? (I'm building a parser.)

```
inline = { array = [ 1,
2 ] }
```

The spec says "No newlines are allowed between the curly braces unless they are valid within a value."

This includes multi-line strings, but do you interpret it to permit newlines in an array? The array itself is technically a single value inside which newlines are valid. It is obviously not "in the spirit" of inline tables but the ABNF grammar allows it.

QapGen: Создаём мощные парсеры на C++

QapDSLv2 — это язык который транслируется в обычный C++ код. Он позволяет удобно и компактно задавать грамматики/правила разбора кода программ, значительно упрощая разработку компиляторов/анализаторов/трансляторов. QapGen — это генератор дерева_лексеров /парсеров описанных на QapDSLv2. Сама грамматика QapDSLv2 описана на QapDSLv2 на 100%. Поэтому QapGen как основной читатель этой грамматики сам генерирует часть своего кода(весь парсер QapDSLv2). Основные фишки QapDSLv2 + QapGen — это: 1) Отсутствие этапа токенизации — дерево лексеров разбивает входной поток на лексемы и сохраняет их в строго типизированных древовидных С++ структурах пропуская этап токенизации. 2) Генерация оптимизированного кода полиморфных лексеров . 3) Полное сохранение всех лексем(даже разделители сохраняются, такие как пробелы/переходы на новую строку и комментарии) в результирующем дереве. 4) Возможность сохранить как оригинальное дерево , так и модифицированное обратно в код/текст без потери разделителей/комментариев . 5) Автоматическая генерация кода посетителей (это такой паттерн проектирования). А теперь пример самой сочной части(рекурсивно самоописывающийся код): struct t_target_struct:i_target_item{ struct t_keyword{ string kw=any_str_from_vec(split("struct,class",",")); " "? // optional separator }; struct t_body_semicolon:i_struct_impl{";"}; struct t_body_impl:i_struct_impl{ "{" // жрём скобочку vector<TAutoPtr<i_target_item>> nested?; // рекурсия! " "? vector<TAutoPtr<i_struct_field>> arr?; // парсим поля " "? TAutoPtr<t_cpp_code> c?; // остальной С++ код " "? "}" }; struct t_parent{ string a_or_c=any_str_from_vec(split("=>,:",",")); " "? t_name name; }; //точка входа в парсер: TAutoPtr<t_keyword> kw?; //парсим struct/class t_name name; //парсим имя " "? TAutoPtr<t_parent> parent?; " "? TAutoPtr<i_struct_impl> body; };

habr.com/ru/articles/925420/

#parser #parsergenerator #lexers #c++ #tree #ast #gamedev #dsl #compiler

ХабрQapGen: Создаём мощные парсеры на C++QapDSLv2 — это язык который транслируется в обычный C++ код. Он позволяет удобно и компактно задавать грамматики/правила разбора, значительно упрощая разработку компиляторов и анализаторов. QapGen —...

I finally got around to wrapping up and publishing a first version of my #Rust crate ts-typed-ast. It's a crate inspired by Rowan that automatically generates a typed AST from a tree-sitter grammar. You can find it here: crates.io/crates/ts-typed-ast

It works similarly to Rowan and Swift's libsyntax. tree-sitter provides the green nodes, while this crate generates the red nodes.

I've used it a few times already, to prototype various toy programming languages. You write a grammar in tree-sitter, and then either evaluate the ts-typed-ast tree directly, or convert it to some other IR.

Using tree-sitter as the parser generator for a toy project is pretty nice. You get a powerful, declarative way to create a parser, and at the same time you benefit from the whole tree-sitter ecosystem. Things like incremental parsing, syntax highlighting, structural editing, and formatting with Topiary.

Main downside is that tree-sitter does not (yet) offer good error reporting and recovery, so when parsing fails it's often in dramatic, unhelpful ways. Not a big issue for experimenting, which is what this crate is for. Production-ready languages probably need bespoke parsers anyway.

crates.iocrates.io: Rust Package Registry

To the #Rust #rustlang community: I once started to write a #compiler / #parser with #nom #crate. However I had some struggles with it of how to provide **multiple** errors with line+column indicators for a parsed context.
Now I read a tiny bit about #syn and #chumsky 👀
Are they the right crates for me? Are there others?
I do not parse rust-code, but a completely custom language (similar to pugjs)

(Boost for reach 🙏)