Probably off-topic: you might be interested in http://repository.readscheme.org/ftp/papers/sw2003/Scmxlate.pdf
Start with the title and then the summary at the end. Dorai has used this package to make his programs available in Schemes and Common Lisps. -- Matthias On May 8, 2015, at 10:56 AM, Philip Blair wrote: > 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 <mfl...@cs.utah.edu> 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 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. > > > -- > 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. -- 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.
