For the current status look at branch 'majestic': https://github.com/GrammaticalFramework/gf-core/tree/majestic/src/runtime/c The subfolder 'doc' contains documentation for the decisions that I made so far. My ambition is that the doc folder would develop into a living book documenting the internals. Hopefully, it will help new developers to jump in later. What works so far: - the C runtime can read the abstract syntax of a .pgf and build an .ngf file from it. The .ngf is the actual database. Some of the abstract syntax functions in the API are implemented as well. - the old Haskell runtime is gone, the folder runtime/haskell contains the new Haskell binding. There are two top-level modules PGF and PGF2. PGF tries to emulate the API of the old Haskell runtime, while PGF2 should be compatible with the API of the C runtime. Everything that already works in the C library has also a binding in the Haskell runtime. There is also a testsuite that I use to test the Haskell binding together with the actual runtime. - most of the code in the Python binding is commented out. It compiles, but the only thing that you can do there is to load a grammar. I only needed that in order to test that it is possible to load the runtime dynamically. - the code for the compiler comes from the branch 'c-runtime'. In that branch the compiler runs on top of the C runtime instead of the Haskell one. In the new branch the compiler doesn't compile yet since not everything in the runtime is implemented yet. Part of the compiler must be updated anyway, since if we want dynamically changing grammars, the grammar building API would have to change anyway. Current milestones: - Finish the rest of the readonly API for the abstract syntax - Add API that can add/remove abstract functions and categories - Implement proper transactions - Modify the compiler to make it possible to compile grammars with only abstract syntax - Modify the compiler to produce an extended version PMCFG which would not blow up in size so easily - Load the new PMCFG in the runtime - Continue with the different API functions for the concrete syntax. Perhaps linearization should be the first to start with. If you want to join the effort then we should schedule a meeting and decide how to proceed.

…

On Mon, 9 Aug 2021 at 11:05, John J. Camilleri ***@***.***> wrote: @krangelov <https://github.com/krangelov> has mentioned at the summer school his ideas on completely reimagining the PGF format as a database. @anka-213 <https://github.com/anka-213> has expressed his interest in contributing, and I ***@***.*** <https://github.com/johnjcamilleri>) also think I could be of use here. I'm creating this issue to be the home of that discussion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#130>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYFSZHT3E245XBNRLP5A2TT36K4HANCNFSM5BZSYMKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

"Majestic" PGF runtime #130

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions