That's good to know about namespaces being intended to be for runtime reflection.
I understand what you mean when you say "bindings and lexical context," but in what specific way do you mean in the context of this issue? I also feel that I should mention that I am having difficulty wrapping my brain around is the utility of a couple of the functions listed in the documentation at http://docs.racket-lang.org/reference/stxtrans.html ; specifically, I am unsure what exactly internal definition contexts and syntax introducers are useful for. Lastly, as far as what I am attempting to implement, I am dabbling with trying to get at least a somewhat functional CL compatibility layer (I'm calling it `#lang clacket`) written. Since Lisp has s-expressions, I figured that there was no need to build a parser from scratch, but instead that I could bridge the gap between the two languages using syntax transformers. Things are going fairly well; I am just having issues getting this packages/identifier-binding issue sorted out. So, to specifically address your final paragraph, it looks like an uphill battle :) Any ideas? On Thu, May 7, 2015 at 2:33 PM, Matthew Flatt <[email protected]> wrote: > I agree that those sound goals sound like a poor fit for `module+`. > It's possible that `racket/package` provides something closer to the > namespace-management tools that you need. > > Generally, I think you'll find more success by manipulating bindings > and lexical context (in the sense of `datum->syntax`) instead of trying > to use namespaces. Racket namespaces are intended more for run-time > reflection; they're too dynamic for most code-organization tasks. > > I'm struggling to give more specific advice. If you need Common Lisp > namespaces, I think that a close variant can be implemented in Racket, > but it looks like an uphill battle. (Common Lisp is better at being > Common Lisp; Racket is just better. :) Unless you're trying to run CL > code with minimal modification, I'd encourage you to talk about your > implementation goals, and maybe the list can offer ideas toward a > suitable, Rackety abstraction. > > At Thu, 7 May 2015 07:29:48 -0700 (PDT), Philip Blair wrote: > > 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 [email protected]. > > > > 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 [email protected]. > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
