{"id":18894921,"url":"https://github.com/magicstack/parsing","last_synced_at":"2025-04-06T04:15:15.033Z","repository":{"id":5963002,"uuid":"7184381","full_name":"MagicStack/parsing","owner":"MagicStack","description":"A pure-Python module that implements an LR(1) parser generator, as well as CFSM and GLR parser drivers.","archived":false,"fork":false,"pushed_at":"2024-09-03T21:33:58.000Z","size":145,"stargazers_count":50,"open_issues_count":2,"forks_count":7,"subscribers_count":7,"default_branch":"main","last_synced_at":"2025-03-30T03:05:42.573Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/MagicStack.png","metadata":{"files":{"readme":"README.rst","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2012-12-15T21:52:04.000Z","updated_at":"2024-12-03T15:32:25.000Z","dependencies_parsed_at":"2023-11-24T19:23:28.390Z","dependency_job_id":"5023c6c1-2201-43bb-8f28-fdf4546ce594","html_url":"https://github.com/MagicStack/parsing","commit_stats":null,"previous_names":[],"tags_count":8,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MagicStack%2Fparsing","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MagicStack%2Fparsing/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MagicStack%2Fparsing/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/MagicStack%2Fparsing/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/MagicStack","download_url":"https://codeload.github.com/MagicStack/parsing/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247430963,"owners_count":20937875,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-08T08:25:32.321Z","updated_at":"2025-04-06T04:15:15.010Z","avatar_url":"https://github.com/MagicStack.png","language":"Python","readme":"Parsing\n=======\n\nThe ``parsing`` module implements an LR(1) parser generator, as well as the\nruntime support for using a generated parser, via the Lr and Glr parser\ndrivers.  There is no special parser generator input file format, but the\nparser generator still needs to know what classes/methods correspond to\nvarious aspects of the parser.  This information is specified via\ndocstrings, which the parser generator introspects in order to generate a\nparser.  Only one parser specification can be embedded in each module, but\nit is possible to share modules between parser specifications so that, for\nexample, the same token definitions can be used by multiple parser\nspecifications.\n\nThe parsing tables are LR(1), but they are generated using a fast algorithm\nthat avoids creating duplicate states that result when using the generic\nLR(1) algorithm.  Creation time and table size are on par with the LALR(1)\nalgorithm.  However, LALR(1) can create reduce/reduce conflicts that don't\nexist in a true LR(1) parser.  For more information on the algorithm, see::\n\n    A Practical General Method for Constructing LR(k) Parsers\n    David Pager\n    Acta Informatica 7, 249-268 (1977)\n\nParsing table generation requires non-trivial amounts of time for large\ngrammars, however it is still quite fast.  Internal pickling support makes\nit possible to cache the most recent version of the parsing table on disk,\nand use the table if the current parser specification is still compatible\nwith the one that was used to generate the pickled parsing table.  Since\nthe compatibility checking is quite fast, even for large grammars, this\nremoves the need to use the standard code generation method that is used\nby most parser generators.\n\nParser specifications are encapsulated by the ``Spec`` class.  Parser\ninstances use ``Spec`` instances, but are themselves based on separate\nclasses.  This allows multiple parser instances to exist simultaneously,\nwithout requiring multiple copies of the parsing tables.  There are two\nseparate parser driver classes:\n\nLr:\n    Standard Characteristic Finite State Machine (CFSM) driver, based on\n    unambiguous LR(1) parsing tables.  This driver is faster than the Glr\n    driver, but it cannot deal with all parsing tables that the Glr\n    driver can.\n\nGlr:\n    Generalized LR driver, capable of tracking multiple parse trees\n    simultaneously, if the %split precedence is used to mark ambiguous\n    actions.  This driver is closely based on Elkhound's design, which\n    is described in a technical report::\n\n        Elkhound: A Fast, Practical GLR Parser Generator\n        Scott McPeak\n        Report No. UCB/CSD-2-1214 (December 2002)\n        http://www.cs.berkeley.edu/~smcpeak/elkhound/\n\nParser generator directives are embedded in docstrings, and must begin with\na '%' character, followed immediately by one of several keywords:\n\n    Precedence:\n        ``%fail`` ``%nonassoc`` ``%left`` ``%right`` ``%split``\n\n    Token:\n        ``%token``\n\n    Non-terminal:\n        ``%start`` ``%nonterm``\n\n    Production:\n        ``%reduce``\n\nAll of these directives are associated with classes except for %reduce.\n%reduce is associated with methods within non-terminal classes.  The Parsing\nmodule provides base classes from which precedences, tokens, and\nnon-terminals must be derived.  This is not as restrictive as it sounds,\nsince there is nothing preventing, for example, a master Token class that\nsubclasses Parsing.Token, which all of the actual token types then subclass.\nAlso, nothing prevents using multiple inheritance.\n\nFolowing are the base classes to be subclassed by parser specifications:\n\n  * Precedence\n  * Token\n  * Nonterm\n\nThe Parsing module implements the following exception classes:\n\n  * SpecError - when there is a problem with the grammar specification\n  * ParsingException - any problem that occurs during parsing\n  * UnexpectedToken - when the input sequence contains a token that is\n    not allowed by the grammar (including end-of-input)\n\nIn order to maintain compatibility with legacy code, the Parsing module\ndefines the following aliases. New code should use the exceptions above\nthat do not shadow Python's builtin exceptions.\n\n   * Exception - superclass for all exceptions that can be raised\n   * SyntaxError - alias for UnexpectedToken\n\nAdditionally, trying to set private attributes may raise:\n  * AttributeError\n\nAuthor: Jason Evans jasone@canonware.com\n\nGithub repo: http://github.com/MagicStack/parsing\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmagicstack%2Fparsing","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmagicstack%2Fparsing","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmagicstack%2Fparsing/lists"}