Re: [racket-users] Scribble: para without indentation for LaTeX/PDF output
(Sorry for the long delay!) I think that defining a paragraph style for Latex is the right answer to avoid indentation. In case you haven't yet done that, here's a hack: use `(elem #:style "noindent")` as the first element of of the paragraph. That works because it generates `\noindent` in the output. To get the section number to use for an exercise number, generate a `delayed-element` and in the resolver callback use `part-collected-info` to extract the number assigned to the enclosing part. At Thu, 23 Apr 2015 03:57:21 -0700 (PDT), Alexey Cherkaev wrote: > Hi, > > I am trying to create something similar to LaTeX's \newtheorem command. Very > simple implementation (still incomplete) for an "Exercise" block: > > #lang racket > (require scribble/manual) > > (provide exercise) > > (define exercise-counter 0) > > (define (exercise cont) > (set! exercise-counter (add1 exercise-counter)) > (para >(bold "Exercise ") >(bold (number->string exercise-counter)) >(bold ". ") >cont)) > > The problem I have when I generate PDF is that the paragraph with "Exercise" > is > indented as a normal paragraph. Is it possible to suppress it directly from > Scribble or do I need to go and define a paragraph style for LaTeX backend? > > Some extra questions: > > - Maybe I am doing something that someone has already done. Are there, by any > chance, implementations of extended set of LaTeX commands? > - Is there a better way to implement a counter? Ideally, I would want to > reset > the counter when section number changes. I would also like to prepend this > counter with the section counter. > > Cheers, Alexey > > -- > 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.
Re: [racket-users] Fully-expanding a define form in its definition context
The problem that you're hitting is that the `#%module-begin` form of `racket` forces partial expansion of the module body to detect definitions before it proceeds to expand expressions. That's why `define-values` complains about a full expansion in context; it's not supposed to be fully expanded, but instead recognized intact by the `module` expander. The only way to cooperate with that expander is to similarly stop expansion at definition forms. For example, if you mainly want to analyze expressions, your expanding macro would need to pass a non-empty stop list to `local-expand`, recognize `define-values` forms that come back from local expansion, and wrap the right-hand side with another macro that can finish forcing expansion and analyze the resulting expression. If the analysis mainly needs to look at expressions but also have information about definitions, then the partial-expanding macro could expand to the definition plus a `define-syntax` so that information about the definition can be found in the expression-analysis pass. If your analysis needs to see the whole module body --- all definitions and expressions together at once --- then you could replace `#%module-begin` to take full control over the way the module body is expanded. That's easier in some ways, but it's some work to support all the definition-and-use patterns that the usual `#%module-begin` allows. At Mon, 4 May 2015 12:01:23 -0400, Scott Moore wrote: > Hi, > > I'm trying to write a macro that fully-expands define forms with the goal > of doing some static checking (and thus want the code in racket core so > that I know what I'm looking at). Ideally, this macro would work in any > context where a define form works. Unfortunately, I'm having a great deal > of difficulty using local-expand to get what I want. I've tried a few > approaches---the code and simple examples are below. > > Local expanding as a 'top-level' definition was closest to working because > it both fully-expands the definition and inserts binding into the enclosing > definition context. Unfortunately, it seems to fail to bind the identifier > correctly in the body of its own define. > > I tried expanding in the 'syntax-local-context', but this causes > define-values to complain that it isn't in a definition context (even > though syntax-local-context is a module context, which I thought was a > definition context). > > Creating a new definition context makes the expansion work, but the binding > goes into the newly created context, which isn't what I want. It also > doesn't fully expand the definition. (If I remove define-values from the > stop list, it tries to fully-expand but dies complaining that define-values > is not in a definition context). > > I think I'm probably misreading the documentation. Can anyone suggest a > correct solution? > > Thanks, > Scott > > #lang racket > > (require (for-syntax syntax/parse > syntax/parse/lib/function-header)) > > (define-for-syntax (definition-local-context-expand stx) > (local-expand stx (syntax-local-context) '())) > > (define-syntax (define-expand-top-level stx) > (syntax-parse stx > #:literals (define-expand-top-level) > [(define-expand-top-level header:function-header body ...+) > (local-expand #'(define header body ...) 'top-level '())])) > > (define-syntax (define-expand-local-context stx) > (syntax-parse stx > #:literals (define-expand-local-context) > [(define-expand-local-context header:function-header body ...+) > (local-expand #'(define header body ...) (syntax-local-context) '())])) > > (define-syntax (define-expand-new-context stx) > (syntax-parse stx > #:literals (define-expand-new-context) > [(define-expand-new-context header:function-header body ...+) > (let* ([def-ctx (syntax-local-make-definition-context)] > [ctx (if (list? (syntax-local-context)) > (cons (gensym) (syntax-local-context)) > (list (gensym)))] > [expd (local-expand #'(define header body ...) ctx (list > #'define-values) def-ctx)]) >(define ids (syntax-parse expd [(def (id) _) (list #'id)])) >(syntax-local-bind-syntaxes ids #f def-ctx) >(internal-definition-context-seal def-ctx) >expd)])) > > ; Works as expected > (define-expand-top-level (foo n) > (+ n 1)) > > (foo 5) > > ; Fails to bind fib in the body of the define > #;(define-expand-top-level (fib n) > (if (<= n 1) > 1 > (+ (fib (- n 1)) (fib (- n 2) > ; fib: unbound identifier in module in: fib > > ; Attempt to use the local-context (which should be a definition context?) > #;(define-expand-local-context (fib n) > (if (<= n 1) > 1 > (+ (fib (- n 1)) (fib (- n 2) > ; define-values: not in a definition context in: > ; (define-values (fib) (lambda (n) (if (<= n 1) 1 (+ (fib (- n 1)) (fib (- > n 2)) > > ; Creating new definition context makes the expand work but does
Re: [racket-users] Re: web-server http-digest-auth: nonce has \r\n
That sounds good. Although I haven't used it in awhile, I recall needing to slice that off more often than keeping it. On May 7, 2015 2:22 PM, "Tim Brown" wrote: > I wonder if base64-encode should rather be patched with a #:last-newline? > (Default #t) argument. > > Tim > > On 7 May 2015 17:37:18 BST, Tim Brown wrote: > >Folks, > > > >I've just tried to use web-server/http-digest-auth, and > >it seems that make-digest-auth-header generates an invalid header > >(or at least one that upsets Firefox). > > > >The definition of make-digest-auth-header(*) uses base64-encode > >to generate the nonce. base64-encode is documented as: > > > >> the result always ends with a newline-bstr unless the input is > >> empty. > > > >So the result is generated as: > > > >(header > > #"WWW-Authenticate" > > #"Digest realm=\"Vyke!\", qop=\"auth\", > >nonce=\"MTQzMTAxNDc3NiBlNjFmMDY2NzgyYjcyNmFjMmIzY2RkNWQxOTU3NzIzNQ==\r\n\" > > > >opaque=\"opaque\"") > > > >Notice the CRLF in nonce... which causes the header to be truncated > >(and > >therefore invalidated) by my browser. I don't know if it's actually > >upsetting my call to response; but in any case it's a problem. > > > >I'm also not sure if there should also be a comma between the nonce and > >opaque. > > > >I've put together a patch for your perusal. > >"tim-brown-patch-1" raised for racket/web-server. > > > >Regards, > > > >Tim > > > >(*) in pkgs/web-server-lib/web-server/http/digest-auth.rkt l.11 > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > -- > 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.
Re: [racket-users] scribble namespace landgrab & embedded package documentation
I have no problem with these names --- the `scribble` exports are
unlikely to ever collide, since we rarely resort to capital letters ---
but I can't help thinking that the language of the metadata should
specified explicitly.
Concretely, instead of
#lang racket/base
maybe the file should start
#lang mcfly racket/base
... or some suitable word if `mcfly` isn't it ... to indicate that
";;;" is being treated in a particular way. The `mcfly` name both
specifies the special parsing of comments and the initial/default
language of those comments, so that either of those are free to evolve
in the future through a different name.
At Mon, 04 May 2015 19:39:19 -0400, Neil Van Dyke wrote:
> For purposes of embedding docs for a package in its Racket source
> file(s), anyone care whether I landgrab some names in the Scribble
> namespace (for package metadata)?
>
> I'm thinking the names will generally one-word generic terms, but with
> capitalization.
>
> Example package source file with said metadata:
>
> BEGIN
>
> #lang racket/base
> ;;; @Package{duckling}
> ;;; @Version{0.1}
> ;;; @Subtitle{Small-Footprint Web Server in Racket}
> ;;; @Author{Neil Van Dyke}
> ;;; @Author{Alyssa P. Hacker}
> ;;; @License{LGPLv3}
> ;;; @Legal{Copyright 2015 Neil Van Dyke. This program is Free Software;
> ;;; you can redistribute it and/or modify it under the terms of the
> ;;; GNU Lesser General Public License as published by the Free
> ;;; Software Foundation; either version 3 of the License, or (at your
> ;;; option) any later version. This program is distributed in the
> ;;; hope that it will be useful, but without any warranty; without
> ;;; even the implied warranty of merchantability or fitness for a
> ;;; particular purpose. See http://www.gnu.org/licenses/ for details.
> ;;; For other licenses and consulting, please contact the author.}
>
> (require (for-syntax racket/base))
>
> ;;; @section{Introduction}
>
> [CODE INTERSPERSED WITH THREE-SEMICOLON SCRIBBLE GOES HERE]
>
> ;;; @History{
> ;;;
> ;;; @Release["0.1" "2014-12-31"]{
> ;;; Initial release.}
> ;;; }
>
> END
>
> Rationale:
>
> * I'm thinking of using the Racket reader for metadata, instead of some
> special-cased text kludge for the metadata, for simplicity/elegance of
> implementation.
>
> * I'm using three-semicolon comments instead of McFly's `doc` forms, to
> simplify evaluation, and to make visually distinguishing between doc and
> code easier without special editor support.
>
> * I've moved the metadata from `info.rkt` back into source file, to make
> only one file you have to edit per package (the redundant bits of
> `info.rkt`, like package name and description, can be updated
> automatically using "http://www.neilvandyke.org/racket-progedit/";).
> Also, when packages were forked under McFly, the legal notice in
> `mcfly-legal` variable in `info.rkt` tended to get lost, and lawyers
> like you to put the notice on the actual file anyway (rather than my old
> ";; See file info.rkt for legal info." kludge comment at the tops of key
> files).
>
> Incidentally, if you paste that example code into Emacs with Quack, you
> should see remnants of 13-year-old support for my earlier embedded
> Texinfo format: http://postimg.org/image/wuwy376od/
> (Though I preferred the look of comments when they were light blue, like
> in DrScheme v103, instead of the modern yellow-snow. :)
>
> Neil V.
>
> --
> 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.
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 controlli
[racket-users] Re: web-server http-digest-auth: nonce has \r\n
I wonder if base64-encode should rather be patched with a #:last-newline? (Default #t) argument. Tim On 7 May 2015 17:37:18 BST, Tim Brown wrote: >Folks, > >I've just tried to use web-server/http-digest-auth, and >it seems that make-digest-auth-header generates an invalid header >(or at least one that upsets Firefox). > >The definition of make-digest-auth-header(*) uses base64-encode >to generate the nonce. base64-encode is documented as: > >> the result always ends with a newline-bstr unless the input is >> empty. > >So the result is generated as: > >(header > #"WWW-Authenticate" > #"Digest realm=\"Vyke!\", qop=\"auth\", >nonce=\"MTQzMTAxNDc3NiBlNjFmMDY2NzgyYjcyNmFjMmIzY2RkNWQxOTU3NzIzNQ==\r\n\" > >opaque=\"opaque\"") > >Notice the CRLF in nonce... which causes the header to be truncated >(and >therefore invalidated) by my browser. I don't know if it's actually >upsetting my call to response; but in any case it's a problem. > >I'm also not sure if there should also be a comma between the nonce and >opaque. > >I've put together a patch for your perusal. >"tim-brown-patch-1" raised for racket/web-server. > >Regards, > >Tim > >(*) in pkgs/web-server-lib/web-server/http/digest-auth.rkt l.11 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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] performance with freeze from 2htdp/image on very complex images
I played around with this for a while, but I've not been able to figure out a change that makes a positive impact. One experiment that seemed useful: I put a printf of the result of current-process-milliseconds right by the code that calls draw-line in your code and in 2htdp/image (which is in the mrlib/core library, the cond clause for line-segment? on line 984). In your code, the printf happens, on average, every .10 millisecond and in 2thdp/image it happens every .63 milliseconds, which is exactly the same ratio I see for the drawing vs the freezing. I tried to change your code to use a dc-path, the way that the 2htdp/image code does, and that gave a 50% slowdown (from 12 to 18 seconds), which isn't close to the factor of 6 between the two programs. I also just disabled the actual drawing (commenting out the line that does the draw-path call) in 2thdp/image and this gave a factor of three improvement. So it is something other than the actual drawing that's going on here. There is a contract nearby that gets checked alot, but removing it has no impact. I wondered if the fact that the 2htdp/image library is building a giant data structure and then traversing it once might cause a slowdown at a lower layer (just because it touchs a lot of different parts of the memory) but I don't know how to do a measurement that could answer that question. I guess you could use "pin" or "cachegrind" but I didn't try that. (I think cachegrind doesn't work with Racket and pin is very much non-trivial to set up.) There might be a way to instrument the GC to get some of that information back, but that also sounds non-trivial. I tried just freezing img1 three times in a row, but that didn't make much difference, so probably that's not it. Otherwise, I'm out of ideas. Robby On Tue, May 5, 2015 at 2:55 PM, Alexander D. Knauth wrote: > > On May 5, 2015, at 10:06 AM, Robby Findler > wrote: > > One of the issues is that the racket/draw version is not doing the > cropping that the 2htdp/image version is doing. Changing the > "scene+line" call in utils.rkt to "add-line" cuts the freeze time in > half for me (using size 242 instead of 728 in the time.rkt file). I > didn't check to see if lines go outside the shape, but if they do, you > might consider just using some arithmetic comparisons there in > util.rkt instead. > > > At first, I was using add-line, but then switched to scene+line because at > first the lines were sometimes going outside the shape, and when that > happened on the left (or the top), it would effectively shift the whole > image to the right, but it would still draw the next line too far left, > shifting the rest of the image even more right, and I ended up with an image > with a little bit of what I wanted on the far right, and a little bit of > what I wanted on the far left, and in between a trail of tiny lines oriented > in weird directions. > > I had kind of assumed that scene+line might be faster because it could be > “translated” into just adding a line to a bitmap, while I thought add-line > would be slightly more expensive because it had to adjust the bounding box > when it went outside the image, but I guess I was wrong. > > So thanks for the suggestion! > > With that change, then I see the time for freezing being the same as > the time for the racket/draw version to draw. > > > That’s not what I see for size 728: > (time (snowflake/inner-fractal 728)) : cpu time: 14822 real time: 14847 > gc time: 2327 > (time (freeze img1)) : cpu time: 197506 real time: > 197911 gc time: 102407 > (time (snowflake/inner-fractal/draw 728)) : cpu time: 23638 real time: 23646 > gc time: 5495 > Where before it was: > (time (snowflake/inner-fractal 728)) : cpu time: 14775 real time: 14874 > gc time: 2304 > (time (freeze img1)) : cpu time: 377110 real time: > 377867 gc time: 198343 > (time (snowflake/inner-fractal/draw 728)) : cpu time: 24257 real time: 24267 > gc time: 5852 > > So it did significantly reduce the time for freezing it, but it’s still > about 8 times slower than using racket/draw. > > Alex Knauth > > -- 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] writing a dual typed / untyped library
> On May 6, 2015, at 7:16 PM, Matthew Butterick wrote: > > A few notes about what I learned when converting my `sugar` library to a dual > Typed Racket / Racket library (in part because of performance considerations). > > http://unitscale.com/mb/technique/dual-typed-untyped-library.html > > (Factual corrections welcome.) Excellent post. Nice high-level description, and suitable for forwarding to an upper-level undergraduate class. Many thanks. John Clements -- 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.
[racket-users] web-server http-digest-auth: nonce has \r\n
Folks, I've just tried to use web-server/http-digest-auth, and it seems that make-digest-auth-header generates an invalid header (or at least one that upsets Firefox). The definition of make-digest-auth-header(*) uses base64-encode to generate the nonce. base64-encode is documented as: the result always ends with a newline-bstr unless the input is empty. So the result is generated as: (header #"WWW-Authenticate" #"Digest realm=\"Vyke!\", qop=\"auth\", nonce=\"MTQzMTAxNDc3NiBlNjFmMDY2NzgyYjcyNmFjMmIzY2RkNWQxOTU3NzIzNQ==\r\n\" opaque=\"opaque\"") Notice the CRLF in nonce... which causes the header to be truncated (and therefore invalidated) by my browser. I don't know if it's actually upsetting my call to response; but in any case it's a problem. I'm also not sure if there should also be a comma between the nonce and opaque. I've put together a patch for your perusal. "tim-brown-patch-1" raised for racket/web-server. Regards, Tim (*) in pkgs/web-server-lib/web-server/http/digest-auth.rkt l.11 -- Tim Brown CEng MBCS City Computing Limited · www.cityc.co.uk City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB T:+44 20 8770 2110 · F:+44 20 8770 2130 City Computing Limited registered in London No:1767817. Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE VAT No: GB 918 4680 96 -- 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 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" grou
[racket-users] (fifth RacketCon) Registration is Now Open
Registration [1] for (fifth RacketCon) [2] is now open! (fifth RacketCon) will be held on September 27th in St. Louis. Like last year, we are pleased to be co-located with Strange Loop[3]. RacketCon is a yearly event where members of the Racket community get together, featuring talks and demos about the things you do with Racket. We still have room on the schedule for speakers. If you've built something cool with Racket, we'd love to hear about it! See you in St. Louis! Vincent [1] https://www.eventbrite.com/e/racketcon-2015-tickets-16825218682 [2] http://con.racket-lang.org/ [3] https://thestrangeloop.com/ -- 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.
