On Wednesday, May 6, 2015 at 11:02:33 PM UTC-4, Matthew Flatt wrote: > I wonder whether whether expanding to `module+` might be a better > direction. A rough expansion of your example might be > > #lang racket/base > (module+ FOO > (provide (all-defined-out)) > (define BAR 2)) > > (module+ FOO > (define BAZ (add1 BAR))) > > (module+ FOO > (add1 BAZ)) > > (module+ QUUX > (require (prefix-in FOO: (submod ".." FOO))) > (add1 FOO:BAZ)) ; => 4 > > (module+ main > (require (submod ".." FOO)) > (require (submod ".." QUUX))) > > where using `module+` lets you splice together pieces of a submodule, > and the final `main` submodule causes the others to be run. > > At Wed, 6 May 2015 16:04:59 -0700 (PDT), Philip Blair wrote: > > Hello, > > > > I am working on a project in which I am trying to implement a Common > > Lisp-style > > package system. A simple example of usage would be as follows: > > > > (in-package FOO > > (define BAR 2)) > > ; ... > > (in-package FOO > > (define BAZ (add1 BAR))) > > ; ... > > (in-package FOO > > (add1 BAZ)) ; => 4 > > ; ... > > (in-package QUUX > > (add1 FOO:BAZ)) ; => 4 > > > > I was able to get something to this effect by doing the following: > > > > 1. Create a namespace during phase 1 for each package > > 2. Wrap the (in-package ...) body in a submodule > > (to remove any local bindings in other parts of the file) > > 3. Wrap the body in the following: > > (require (for-syntax syntax/parse) racket/splicing) > > (parameterize ((current-namespace #,(package-namespace > > resolved-package))) > > (splicing-let-syntax ((#%top (λ(stx) > > (syntax-parse stx > > [(_ . id) #'(namespace-variable-value > > 'id)])))) > > #,@#'body)) > > > > This makes all non-local definitions resolve to the current > > namespace's > > definition. > > > > This works great. I ran into a problem, however, when trying to create a > > provide transformer for the packages. I wrote the transformer and tried to > > test > > it, only to be greeted by this message: > > > > write: cannot marshal value that is embedded in compiled code value > > > > The value in question was one of the namespaces I had created. Some > > searching > > online led me to > > http://stackoverflow.com/questions/17437037/what-is-3d-syntax > > , which, while telling me what the problem with my code was, still leaves > > me > > wondering, is this a bad place for 3D syntax? More or less, I am trying to > > manually link the identifiers in a given environment and export those > > bindings > > as runtime values. Is there another/a better way to do this? While I could > > perhaps shoehorn these namespace bindings into purely phase 0 code, I would > > rather have more preprocessor overhead and less runtime overhead and link > > everything up during phase 1*. If that's a reasonable idea, how might I go > > about pushing these namespace values from phase 1 to phase 0? > > > > *Disclaimer: There's a decent chance that any such "placement" of the > > overhead > > is a figment of my imagination and, in reality, pushing it to phase 0 will > > make > > no difference. > > > > Regards, > > - Philip Blair (belph) > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email > > to racket-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout.
Thank you for the reply. I have a couple of qualms about using `module+`; if they are resolvable, I would love to know. One issue is controlling exposure of namespaces belonging to packages which one has loaded (other than the one that they are currently in). I am trying to be as faithful as possible to the structure of the Lisp package system, in which one can utilize (use-package ...) [which would correspond to a require], (in-package ...), and [trickiest of the bunch] (unuse-package ...). If I am not mistaken, a `module+` form would require a new nested submodule to be defined every time one wants to unuse a package. To further complicate things, this newly created submodule would need to be what is extended in all subsequent contexts of the package. Because of this, I assumed it would be easier to manually manage which namespaces are available for identifier binding during the compilation process. The other (much smaller) issue I have with `module+` is the fact that I would like these packages to be able to span multiple files. I have yet to successfully define and chain together `module+` forms in such a setting (this one might be very simple and I am just doing it wrong :) ). -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
