A store is like a parameter, except stores are independent of each
other, unlike parameters which are bundled together into a single
parameterization. This was observable in cases like the
example-action-after-suspension code checked in here, where dataflow
invoked a script, which parameterized current-dataflow-subject-id.
This captured *too much* of things like the pending-patch and
pending-actions. Subsequent `schedule-action!` calls' effects were
then lost.
Adding `#'module+` explicitly to the stop-list for local-expand stops
the infinite recursion (problem 1 in the issue description). The code
goes on to treat it like `#'module` and `#'module+`, namely as a
non-action-producing form.
Problem 2 in the issue description is interesting. I haven't done
anything in particular to address the production of unbounded `X` ->
`(begin X)` expansions, but it seems not currently to be a problem;
and, weirdly (?), submodules in a `#lang syndicate` or `#lang
syndicate/actor` module do not seem to inherit the `#%module-begin` of
their container! That is, `(module+ main)`, `(module+ test)` etc. all
seem to have a `racket/base` `#%module-begin`, though I've not looked
very far into this.
Most peculiar on this front is that if the `#,@(reverse final-forms)`
precedes the `(module+ syndicate-main ...)`, and the module being
processed includes, say, a `(module+ main)`, then for some reason the
resulting `main` submodule *is* treated as having a `syndicate/lang`
`#%module-begin` (thus causing problems as suggested in the issue
description)! I *really* don't understand why that might be, and
haven't spent very much time investigating after I noticed that so
long as the `main`-required `syndicate-main` submodule preceded all
other submodule declarations, things seemed to work out.
This whole approach is still a bit dicey: for example, the following
will erroneously treat `(foo quux)` as an expression yielding actions,
rather than a struct declaration:
#lang syndicate
(define-syntax-rule (foo x) (struct x ()))
(foo quux)
Make #lang syndicate module-begin gather boot actions into a
syndicate-main submodule, and for each such module, add a main
submodule that calls run-ground with the syndicate-main boot actions.
This lets us write syndicate *libraries* that comprise both
data-structures, functions, and Syndicate services.
Tony Garnock-Jones