From 54d3b54230d7cbbd699f7880e63a6f0bf2ad8cc0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Georges=20Dup=C3=A9ron?= Date: Fri, 23 Sep 2016 02:02:21 +0200 Subject: [PATCH] Added caveat about module boundaries in the documentation and README --- README.md | 20 +++++++++++++++++++ private/no-order.rkt | 5 +++++ .../extensible-parser-specifications.scrbl | 18 +++++++++++++++++ 3 files changed, 43 insertions(+) diff --git a/README.md b/README.md index 2e07848..27a0c5c 100644 --- a/README.md +++ b/README.md @@ -6,6 +6,26 @@ 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. diff --git a/private/no-order.rkt b/private/no-order.rkt index d6636f9..838bc42 100644 --- a/private/no-order.rkt +++ b/private/no-order.rkt @@ -149,6 +149,11 @@ [lift-rest add-to-lift-rest!]) (define alts (expand-all-eh-mixin-expanders #'(~or pat ...))) + ;; TODO: we can probably close the "parameterize" here. + + + + ;; NOTE: this works only because eh-mixin-expanders are NOT pattern ;; expanders. If these are merged later on, then this needs to be ;; adjusted diff --git a/scribblings/extensible-parser-specifications.scrbl b/scribblings/extensible-parser-specifications.scrbl index 091119a..5a37c54 100644 --- a/scribblings/extensible-parser-specifications.scrbl +++ b/scribblings/extensible-parser-specifications.scrbl @@ -11,6 +11,24 @@ @title{extensible-parser-specifications} @author{@author+email["Georges Dupéron" "georges.duperon@gmail.com"]} +Caveat: the mixins defined with @racket[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 @racket[~mixin] (or by directly invoking it) +within the same module. + +The regular and splicing syntax classes defined with +@racket[#:define-syntax-class] and @racket[#: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 @racket[~no-order] and +@racket[~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 @racket[~mixin] are within the same module, +everything else should work without surprises. + @defmodule[extensible-parser-specifications] @include-section{defining-reusable-mixins.scrbl}