Re: [racket-users] Environment Shuffling and 3D Syntax
Sorry for the delay (I was moving earlier this week). Thank you for taking a crack at the task. One question I have is whether or not the scopes feature is something which I can more or less count on being available in future versions of Racket (I understand that it's from a snapshot and might therefore undergo some changes before it would be released, but I would like to know if at least the functionality should be there). It may be a moot point in light of your syntactic solution, but I was wondering what the list's thoughts were on a partial implementation I came up with before you responded (it has the same no macros issue): I managed to get a runtime solution working using namespaces. Aside from macros, I believe that it implements most every feature the the CL package system does. There is a `*package*` parameter which is used to resolve unknown definitions (using an override of `#%top` which calls `namespace-variable-value` using the current package's namespace). I have attached the (somewhat messy) file for others to look at. What would be more racket-y/a better design approach: a more macro-oriented solution like what I was initially discussing and what Dr. Flatt wrote, or a more runtime-oriented solution like the (slightly messy) attached file (I'm not sure how to handle macros in that case, though...Maybe the list has some ideas :) )? Dr. Felleisen Ryan: thank you for the link to that paper and webpage. The paper gave me the impression that I might be able to get some ideas from scmxlate. When I have a chance, I'll have to take a good look at the program itself. On May 10, 2015, at 19:04, Matthias Felleisen matth...@ccs.neu.edu wrote: 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. The PDF in question references a dead page for the software. The correct url is: http://www.ccs.neu.edu/home/dorai/scmxlate/index.html -- 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. package-rt.rkt Description: Binary data
Re: [racket-users] Environment Shuffling and 3D Syntax
At Fri, 15 May 2015 11:09:25 -0400, Philip Blair wrote: One question I have is whether or not the scopes feature is something which I can more or less count on being available in future versions of Racket That's not yet clear. Although most existing code would be unaffected by the change to a set-of-scopes expander, there are significant compatibility issues. After posting an initial call for feedback on the dev list about a month ago, I've let the question sit while the v6.2 release is being prepared (and while I had other tasks to attend to). I think v6.2 is now far enough along that we could restart the conversation. -- 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.
Re: [racket-users] Environment Shuffling and 3D Syntax
On May 10, 2015, at 19:04, Matthias Felleisen matth...@ccs.neu.edu wrote: 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. The PDF in question references a dead page for the software. The correct url is: http://www.ccs.neu.edu/home/dorai/scmxlate/index.html -- 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.
Re: [racket-users] Environment Shuffling and 3D Syntax
I've fought my way a little up the hill, and enclosed is an implementation that I think works the way you want within a module. See the enclosed in-package.rkt. As you suspected, `make-syntax-introducer` is the piece that you need. In the terminology of the current macro expander, the function produced by `make-syntax-introducer` adds a mark to its argument syntax object. Each package has its own mark, and so a package's definitions are not visible outside the package (where references are missing the necessary mark to access the definition). To use the definitions of one package in another in an expression, `letrec-syntaxes` is wrapped around the expression to map the defined names of the used package to the names that are otherwise hidden by a mark. To make this strategy work, a package's definitions need to be detected, so `in-package` partially expands its body to detect `define-values`, etc. I can see a limitation of this implementation: In a package P that uses package Q, a macro defined in Q cannot expand to a definition in P. That's because the bindings of a used package can only be made available to expressions with the `letrec-syntaxes` wrapper, and that doesn't work for wrapping definitions. (A `splicing-letrec-syntaxes` wrapper doesn't work, because it interacts badly with the partial expansion needed to detect definitions.) As it turns out, we have an experimental variant of the Racket macro expander that can avoid the limitation. In the terminology of that expander, the function produced by `make-syntax-introducer` adds a scope to its argument syntax, and each package corresponds to a scope. Unlike marks, scopes on a syntax object are unordered, and so they can be added freely to access the content of used packages; no `letrec-syntaxes` wrapper is needed. I've included a set-of-scopes variant as in-package-scopes.rkt in case you're interested; you should be able to run it with a snapshot at http://www.cs.utah.edu/~mflatt/tmp/scope-snapshot/ For more information on the set-of-scopes expander, see http://www.cs.utah.edu/~mflatt/scope-sets-4/ At Fri, 8 May 2015 10:56:16 -0400, 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
Re: [racket-users] Environment Shuffling and 3D Syntax
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,
Re: [racket-users] Environment Shuffling and 3D Syntax
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
Re: [racket-users] Environment Shuffling and 3D Syntax
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
[racket-users] Environment Shuffling and 3D Syntax
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.
