https://github.com/suzannesoy/extensible-parser-specifications
Like https://github.com/AlexKnauth/seq-no-order, but provides global constraints. AlexKnauth's implementation allows dotted "rest" pattern which we do not support.
https://github.com/suzannesoy/extensible-parser-specifications
racket-library
Last synced: 3 months ago
JSON representation
Like https://github.com/AlexKnauth/seq-no-order, but provides global constraints. AlexKnauth's implementation allows dotted "rest" pattern which we do not support.
- Host: GitHub
- URL: https://github.com/suzannesoy/extensible-parser-specifications
- Owner: SuzanneSoy
- License: cc0-1.0
- Created: 2016-08-26T22:08:13.000Z (almost 10 years ago)
- Default Branch: main
- Last Pushed: 2021-04-04T15:33:43.000Z (about 5 years ago)
- Last Synced: 2025-03-19T00:02:31.345Z (over 1 year ago)
- Topics: racket-library
- Language: Racket
- Homepage: http://docs.racket-lang.org/extensible-parser-specifications/
- Size: 83 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- License: LICENSE-more.md
Awesome Lists containing this project
README
[](https://travis-ci.org/jsmaniac/extensible-parser-specifications)
[](https://codecov.io/gh/jsmaniac/extensible-parser-specifications)
[](http://jsmaniac.github.io/travis-stats/#jsmaniac/extensible-parser-specifications)
[](http://docs.racket-lang.org/extensible-parser-specifications/)
[](https://github.com/jsmaniac/extensible-parser-specifications/issues)
[](https://creativecommons.org/publicdomain/zero/1.0/)
extensible-parser-specifications
================================
Caveat: the mixins defined with `define-eh-alternative-mixin` cannot be
provided and used in a separate module. Unfortunately, I cannot think of an
acceptable fix for this problem, as solving this would require extracting
parts of the mixin while preserving the bindings of some identifiers, but
altering the bindings of others. This means that for the foreseeable future,
once a mixin is defined, can only be used via `~mixin` (or by directly
invoking it) within the same module.
The regular and splicing syntax classes defined with `#:define-syntax-class`
and `#:define-splicing-syntax-class` will work fine across module boundaries,
however. Manually defined syntax classes, splicing syntax classes or
ellipsis-head syntax classes will also work fine across module boundaries,
even if they contain uses of `~no-order` and `~seq-no-order`, and even if
those special forms contain uses of mixins defined within the same module. In
other words, as long as a definition of a mixin and all its uses via `~mixin`
are within the same module, everything else should work without surprises.
----------
Like https://github.com/AlexKnauth/seq-no-order, but provides global
constraints. AlexKnauth's implementation allows dotted "rest" pattern which
this implementation does not support.
This package is unstable, and its API may change at any moment. Once it is
stable enough, it may be merged into [Alex Knauth's
implementation](https://github.com/AlexKnauth/seq-no-order).
The following pattern expanders (and mixin expanders, see the docs) for `syntax/parse` are defined:
* ~seq-no-order
* ~no-order
* ~post-check
* ~post-fail
* ~nop
* ~optional/else
* ~global-or
* ~global-and
* ~global-counter