www

Unnamed repository; edit this file 'description' to name the repository.
Log | Files | Refs | README

README.md (2808B)

      1 [![Build Status,](https://img.shields.io/travis/jsmaniac/extensible-parser-specifications/main.svg)](https://travis-ci.org/jsmaniac/extensible-parser-specifications)
      2 [![Coverage Status,](https://img.shields.io/codecov/c/github/jsmaniac/extensible-parser-specifications/main.svg)](https://codecov.io/gh/jsmaniac/extensible-parser-specifications)
      3 [![Build Stats,](https://img.shields.io/badge/build-stats-blue.svg)](http://jsmaniac.github.io/travis-stats/#jsmaniac/extensible-parser-specifications)
      4 [![Online Documentation,](https://img.shields.io/badge/docs-online-blue.svg)](http://docs.racket-lang.org/extensible-parser-specifications/)
      5 [![Unmaintained as of 2017 because syntax-parse is ill-fitted for this use,](https://img.shields.io/badge/maintained-no%20as%20of%202017%20%28syntax--parse%20is%20ill--fitted%20for%20this%20use%29-red.svg)](https://github.com/jsmaniac/extensible-parser-specifications/issues)
      6 [![License: CC0 v1.0.](https://img.shields.io/badge/license-CC0-blue.svg)](https://creativecommons.org/publicdomain/zero/1.0/)
      7 
      8 extensible-parser-specifications
      9 ================================
     10 
     11 
     12 Caveat: the mixins defined with `define-eh-alternative-mixin` cannot be
     13 provided and used in a separate module. Unfortunately, I cannot think of an
     14 acceptable fix for this problem, as solving this would require extracting
     15 parts of the mixin while preserving the bindings of some identifiers, but
     16 altering the bindings of others. This means that for the foreseeable future,
     17 once a mixin is defined, can only be used via `~mixin` (or by directly
     18 invoking it) within the same module.
     19 
     20 The regular and splicing syntax classes defined with `#:define-syntax-class`
     21 and `#:define-splicing-syntax-class` will work fine across module boundaries,
     22 however. Manually defined syntax classes, splicing syntax classes or
     23 ellipsis-head syntax classes will also work fine across module boundaries,
     24 even if they contain uses of `~no-order` and `~seq-no-order`, and even if
     25 those special forms contain uses of mixins defined within the same module. In
     26 other words, as long as a definition of a mixin and all its uses via `~mixin`
     27 are within the same module, everything else should work without surprises.
     28 
     29 ----------
     30 
     31 Like https://github.com/AlexKnauth/seq-no-order, but provides global
     32 constraints.  AlexKnauth's implementation allows dotted "rest" pattern which
     33 this implementation does not support.
     34 
     35 This package is unstable, and its API may change at any moment. Once it is
     36 stable enough, it may be merged into [Alex Knauth's
     37 implementation](https://github.com/AlexKnauth/seq-no-order).
     38 
     39 The following pattern expanders (and mixin expanders, see the docs) for `syntax/parse` are defined:
     40 * ~seq-no-order
     41 * ~no-order
     42 * ~post-check
     43 * ~post-fail
     44 * ~nop
     45 * ~optional/else
     46 * ~global-or
     47 * ~global-and
     48 * ~global-counter
     49