[racket-users] large hash/dc errors (was: Contracts for (partially) specifying dictionary key -> value-predicates)
> Ben: if you have an example of the bad hash/dc error message I'd be > interested to see it. > > Robby Here's the kind of message that turned me off: ``` ctc.rkt:34:0: broke its own contract promised: (hash/dc (k (or/c (quote a) (quote b) (quote c))) (v (k) (config-value/c k)) #:immutable #t #:kind (quote flat)) produced: '#hash((a . 1) (b . #t) (c . #)) in: (hash/dc (k (or/c 'a 'b 'c)) (v (k) (config-value/c k)) #:immutable #t #:kind 'flat) contract from: + blaming: + (assuming the contract is correct) ``` It prints the whole hash and contract, leaving me to figure out the two key parts: (1) what piece of the hash failed, and (2) what the contract expected for that piece. Now that I think of it ->* is bad in the same way --- especially for `plot` functions. Here's the code that made that error message. The #;(lambda ) comment is the contract that I ended up using instead of hash/dc (it still doesn't explain bad values well). ``` #lang racket/base (require racket/contract) (provide config/c) (define config-key/c (or/c 'a 'b 'c)) (define (config-value/c k) (case k ((a) string?) ((b) boolean?) ((c) void?))) (define config/c #;(lambda (h) (for ((k (in-list (list 'a 'b 'c (unless (hash-has-key? h k) (raise-arguments-error 'config/c "missing key" "key" k "hash" h)) (define v (hash-ref h k)) (unless ((config-value/c k) v) (raise-arguments-error 'config/c "bad value for key" "key" k "value" v "hash" h)) (void))) (hash/dc [k config-key/c] [v (k) (config-value/c k)] #:immutable #true #:kind 'flat)) (contract config/c (hash 'a 1 'b #true 'c (void)) '+ '-) ``` -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFUu9R61khGypp61r6A4i%2BrO8C7O%3D4TLy23KdF9aOpeeSy_4UQ%40mail.gmail.com.
[racket-users] hash-filter: PR or not PR
Hi, I am currently using hash tables a lot, so inevitably I end up writing general functions. I wrote the following `hash-filter`: ``` (define (hash-filter ht #:predicate [predicate #f] #:predicate/key [predicate/key (if predicate (λ (_ v) (predicate v)) (error 'hash-filter))]) (for/fold ([filtered-pairs (hash-clear ht)]) ([(k v) (in-hash ht)]) (if (predicate/key k v) (hash-set filtered-pairs k v) filtered-pairs))) ``` Before I submit a pull request to the Racket repository, I would like to know whether adding this function to `racket/hash` is a good idea, or whether I should create a separate package with extra functions for hash tables. - Sergiu -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/3c2618ed-8940-4234-9014-e65081eb961fn%40googlegroups.com.
Re: [racket-users] [racket users] Pollen tag question
> On Oct 30, 2020, at 1:46 PM, Kevin Forchione wrote:
>
> Thanks, Matthew! Understanding dawns. So the padding of lines is relative to
> the “{“ and not from the beginning of the editor line as I was assuming. How
> very clever. That makes alignment much easier than I’d thought!
>
> Is this mentioned anywhere in the pollen tutorials? I must have missed it.
Yes:
"The Pollen language is a variant of Racket’s own text-processing language,
called Scribble. Thus, most things that can be done with Scribble syntax can
also be done with Pollen syntax. For the sake of clarity & brevity, I’ve only
shown you the highlights here. But if you want the full story, see @ Syntax in
the Scribble documentation."
https://docs.racket-lang.org/pollen/pollen-command-syntax.html?q=pollen#%28part._.Further_reading%29
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/D63442C4-6339-420A-903D-1547BD013E19%40mbtype.com.
[racket-users] Racket CPU Graphics Engine - Time to Share
Hello fellow Racketeers, during the spring and summer I worked on a side project to test what can be done in pure Racket when it comes to raster graphics rendering. You can imagine it like demo or game programming before the advent of GPUs. It turned out that quite a lot can be achieved and it also turned out that Racket performs really well when it comes to some hard number crunching. And what else is computer graphics than just a number crunching? As I consider this experiment basically completed, I release the source code[1] to the public under the usual dual Apache/MIT license. A short (25s) video in action can be seen on the project "website"[2]. For those wondering about the tut25 naming - the project started as an attempt to rewrite all Denthor's VGA Trainers published between 1994 and 1996. There were 21 tutorials, I added four. I am publishing only the final result - the 25th "tutorial". If I have some spare time in the future, I'll write a series of articles about the journey from drawing the first pixel in the window to full 3D triangle rasterizer with alpha blending, perspective-correct texturing, z-buffering and Goraud shading. And for those wondering "why?" - there are actually more answers: 1) Why not? 2) Projects like this stress-test Racket implementation and therefore help its development (more on that below). 3) I want more people to start using futures for improving performance without sacrificing code readability. 3b) Also I don't want to hear from the people in the core team "Oh, you are probably the only one seriously using futures" ;-) To inspire more people to start seemingly crazy projects like this, here is a list of things that are now better in current Racket version as a side-effect of this project (and yes, Matthew wrote all the patches): * futures versus GC in BC - no more crashes[3] * futures and the write barrier in BC - no more freezes[4] * fsemaphores - no longer can go negative (actually the bug was elsewhere)[5] * safe and unsafe fl->fx unification[6] * internal stack overflow fixed[7] * box CAS operation troubles with futures[8] The code comes however with a big red warning: some parts are as ugly as they can get. On the other hand, there are some nice language features that I consider worth investigating further. Mainly: * using syntax macros to create procedure templates and then with another layer of syntax macros instantiate those for specific task. See for example the define/provide-draw-proc-variants and template-clear in rcge/drawing.rkt. Yes, they are unhygienic - but just very slightly... * context nesting using parameters (although I personally dislike the need to wrap everything in so many parameterize layers) - see any of rcge/*-run.rkt files for example. * using syntax macros to provide hints to the compiler. The best example of this is the matrix multiplication in rcge/algebra.rkt - define-mat4*mat4!/let. Yes, definitely not the best practice in general, but combined with unboxed flonums on CS, it improved the performance by an order of magnitude compared to simple loop. * define-futurized (rcge/futures.rkt) - in an ideal world, a generalized version of a macro like this should be able to parallelize computation-heavy algorithms with little to no effort for the programmer. Things NOT to do: blit-to-cairo-data*-u16vector-hack - rcge/blit.rkt is not for the weak. But I like the fact, that it is possible to interact between different layers of the program, compiler and JIT. Thank you for reading this far and if you have any questions, I'll be more than happy to answer those. Cheers, Dominik [1] https://joe.cz/rcge/ [2] https://gitlab.com/racketeer/rcge-tut25 [3] https://github.com/racket/racket/issues/3145 [4] https://github.com/racket/racket/commit/fae20b4b8904bfcfba9808f56744950b049b6afd [5] https://github.com/racket/racket/commit/1117392cb5524a2ce150384d405fb2a81ef47daa [6] https://github.com/racket/racket/commit/42cb80bc70e1fb97dabd1e0a2dff5d93257b1f40 [7] https://github.com/racket/racket/commit/265c9eaa57661a045feed85e1db45029aa9de7e2 [8] https://github.com/racket/racket/commit/0af11de62b2eaa1f4f0977794a4dc9dcacabd945 -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/a46338ba-51e1-e3f4-dba2-99d319b0b503%40trustica.cz.
Re: [racket-users] [racket users] Pollen tag question
> On Oct 30, 2020, at 12:25 PM, Matthew Butterick wrote:
>
> Spaces at the beginning of body lines do not appear in the resulting
> S-expressions, but the column of each line is noticed, and all-space
> indentation strings are added so the result has the same indentation … If the
> first string came from the opening { line, it is not prepended with an
> indentation”
Thanks, Matthew! Understanding dawns. So the padding of lines is relative to
the “{“ and not from the beginning of the editor line as I was assuming. How
very clever. That makes alignment much easier than I’d thought!
Is this mentioned anywhere in the pollen tutorials? I must have missed it.
Kevin
T
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/2E23F40B-B3D9-495A-ACF6-34447B95A8A1%40gmail.com.
Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates
Thanks for the feedback! Some of these were not concerns for my use case, so I’ll do a bit more design before submitting something. -- Sent from my phoneamajig > On Oct 30, 2020, at 12:36, George Neuner wrote: > > >> On 10/30/2020 3:08 PM, William J. Bowman wrote: >> Let me aid this discussion by copying in the ~10 lintes of code in question: >> >> > (define-syntax (dictof syn) >> > (syntax-parse syn >> > [(_ (k:id pred?) ...) >> > (quasisyntax/loc syn >> >(dictof/proc `((k . ,pred?) ...)))])) >> > > (define ((dictof/proc spec) h) >> > (and (eq? (dict-keys h) (dict-keys spec)) >> >(for/and ([(k pred?) (in-dict spec)]) >> > (pred? (dict-ref h k) >> >> The macro is merely a syntactic transformation to 1 line of code that >> implements >> the functionality of the contract at run-time. >> Is there some reason to avoid macros in this particular case? > > There's rarely any problem with macros that only provide syntactic sugar. > > The issues wrt contracts are how heavy are the dictionary functions. The FOR > loop is concerning because the check time is proportional to the size of the > dictionary [again recalling that contracts live on in release code]. > > For performance it would be better to enforce the predicate on values as they > are entered, and then assume anything already in the dictionary is correct. > It is sensible to provide a function that validates the whole dictionary, but > I would make it something the programmer has to invoke deliberately rather > than a contract to be enforced at (even just 1st in module) mention of the > dictionary. > > YMMV, > George > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/95997336-33d4-5c5b-b329-9ea691fe59ef%40comcast.net. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/E9A25DEF-7B1B-426C-AFAD-319C5C2E9757%40williamjbowman.com.
Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates
On 10/30/2020 3:08 PM, William J. Bowman wrote: Let me aid this discussion by copying in the ~10 lintes of code in question: > (define-syntax (dictof syn) > (syntax-parse syn > [(_ (k:id pred?) ...) > (quasisyntax/loc syn >(dictof/proc `((k . ,pred?) ...)))])) > > (define ((dictof/proc spec) h) > (and (eq? (dict-keys h) (dict-keys spec)) >(for/and ([(k pred?) (in-dict spec)]) > (pred? (dict-ref h k) The macro is merely a syntactic transformation to 1 line of code that implements the functionality of the contract at run-time. Is there some reason to avoid macros in this particular case? There's rarely any problem with macros that only provide syntactic sugar. The issues wrt contracts are how heavy are the dictionary functions. The FOR loop is concerning because the check time is proportional to the size of the dictionary [again recalling that contracts live on in release code]. For performance it would be better to enforce the predicate on values as they are entered, and then assume anything already in the dictionary is correct. It is sensible to provide a function that validates the whole dictionary, but I would make it something the programmer has to invoke deliberately rather than a contract to be enforced at (even just 1st in module) mention of the dictionary. YMMV, George -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/95997336-33d4-5c5b-b329-9ea691fe59ef%40comcast.net.
Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates
On Fri, Oct 30, 2020 at 2:08 PM William J. Bowman wrote: > Let me aid this discussion by copying in the ~10 lintes of code in > question: > > > (define-syntax (dictof syn) > > (syntax-parse syn > > [(_ (k:id pred?) ...) > > (quasisyntax/loc syn > >(dictof/proc `((k . ,pred?) ...)))])) > > > > (define ((dictof/proc spec) h) > > (and (eq? (dict-keys h) (dict-keys spec)) > >(for/and ([(k pred?) (in-dict spec)]) > > (pred? (dict-ref h k) > > The macro is merely a syntactic transformation to 1 line of code that > implements > the functionality of the contract at run-time. > Is there some reason to avoid macros in this particular case? > > I don't think so. But I do think that you'd need more checking so things like (dictof (,(something scary) i-am-not-a-procedure)) give reasonable error messages. And eq? is probably not the right comparison (consider large integers for example). Robby > -- > William J. Bowman > > On Fri, Oct 30, 2020 at 03:04:04PM -0400, George Neuner wrote: > > > > On 10/30/2020 1:14 PM, William J. Bowman wrote: > > > Thanks! One follow-up: > > > > > > > 1. make these functions, not macros > > > The main implementation is a procedure, but I think I need a macro to > get the > > > syntactic interface I want. > > > > > > Is there some reason to avoid macros? > > > > You certainly can use macros in the implementation, but just remember > that > > macros evaluate at compile time and most contracts have to be checked at > > runtime: so a contract can't *exclusively* be a macro ... runtime code > has > > to be generated. > > > > Robby's comment about code size is relevant also: contracts are not > debug > > mode only like assertions in C ... Racket's contracts live on in release > > mode compiles, so you want to minimize the amount of runtime code > required > > to implement them. > > > > George > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/20201030190826.GA1988871%40williamjbowman.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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAL3TdOOOcb0MnmWnj7bWP5SwnDzGr0zCTdcs_5hRWutGmHpF0Q%40mail.gmail.com.
Re: [racket-users] [racket users] Pollen tag question
> On Oct 29, 2020, at 9:04 PM, Kevin Forchione wrote:
>
> I’ve noticed that the elements being sent to a pollen tag don’t preserve the
> spacing when the text spans multiple lines for any space occurring before
> characters on the subsequent line, although does preserve the spacing between
> characters on that line.Is thes intentional?
Yes:
"Spaces at the beginning of body lines do not appear in the resulting
S-expressions, but the column of each line is noticed, and all-space
indentation strings are added so the result has the same indentation … If the
first string came from the opening { line, it is not prepended with an
indentation"
https://docs.racket-lang.org/scribble/reader.html?q=spaces%20newlines#%28part._.Spaces__.Newlines__and_.Indentation%29
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/3998A523-1ED7-4446-80F4-A860324FA79C%40mbtype.com.
Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates
Let me aid this discussion by copying in the ~10 lintes of code in question: > (define-syntax (dictof syn) > (syntax-parse syn > [(_ (k:id pred?) ...) > (quasisyntax/loc syn >(dictof/proc `((k . ,pred?) ...)))])) > > (define ((dictof/proc spec) h) > (and (eq? (dict-keys h) (dict-keys spec)) >(for/and ([(k pred?) (in-dict spec)]) > (pred? (dict-ref h k) The macro is merely a syntactic transformation to 1 line of code that implements the functionality of the contract at run-time. Is there some reason to avoid macros in this particular case? -- William J. Bowman On Fri, Oct 30, 2020 at 03:04:04PM -0400, George Neuner wrote: > > On 10/30/2020 1:14 PM, William J. Bowman wrote: > > Thanks! One follow-up: > > > > > 1. make these functions, not macros > > The main implementation is a procedure, but I think I need a macro to get > > the > > syntactic interface I want. > > > > Is there some reason to avoid macros? > > You certainly can use macros in the implementation, but just remember that > macros evaluate at compile time and most contracts have to be checked at > runtime: so a contract can't *exclusively* be a macro ... runtime code has > to be generated. > > Robby's comment about code size is relevant also: contracts are not debug > mode only like assertions in C ... Racket's contracts live on in release > mode compiles, so you want to minimize the amount of runtime code required > to implement them. > > George -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20201030190826.GA1988871%40williamjbowman.com.
Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates
On 10/30/2020 1:14 PM, William J. Bowman wrote: Thanks! One follow-up: > 1. make these functions, not macros The main implementation is a procedure, but I think I need a macro to get the syntactic interface I want. Is there some reason to avoid macros? You certainly can use macros in the implementation, but just remember that macros evaluate at compile time and most contracts have to be checked at runtime: so a contract can't *exclusively* be a macro ... runtime code has to be generated. Robby's comment about code size is relevant also: contracts are not debug mode only like assertions in C ... Racket's contracts live on in release mode compiles, so you want to minimize the amount of runtime code required to implement them. George -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5f5fecff-01f9-5f66-1ffe-4486de354199%40comcast.net.
Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates
I've wanted this several times (and written more than one ad-hoc partial version): a general-purpose combinator would be great! On Fri, Oct 30, 2020 at 1:14 PM William J. Bowman wrote: > > 1. make these functions, not macros > The main implementation is a procedure, but I think I need a macro to get > the > syntactic interface I want. Personally, I'd think about an approach like `->` and `dynamic->*`: a nice syntactic interface that covers most use-cases paired with a somewhat-less-ergonomic procedural interface for more comprehensive functionality, e.g. when aspects of the contract to be generated aren't statically known. On Fri, Oct 30, 2020 at 11:06 AM Ben Greenman wrote: > 2. make "at least" the default behavior for dictof, add an option to > override (#:exact-keys?), and remove rho-dictof > To go a step further, I think there are two dimensions of "exactness": 1. Are keys other than those specified permitted? 2. Is a particular key required or optional? There are some combinations of answers to those questions that I think make for poor API design, but, in many of the cases when I've wanted these types of contracts, I've been working with messy pre-existing APIs (often JSON), which inhabit a whole lot of different points in this space. An even-more-general way of asking "Are keys other than those specified permitted?" would be, "What is the contract for a key–value pair not otherwise specified?", where `any/c` and `none/c` are important special cases. Even more generally, this could be a function to produce a contract à la `hash/dc`: I'll see if I can remember an example, but I think I've encountered APIs where this would have been useful. As far as "Is a particular key required or optional?", I'd want a nice syntax to specify this for all keys (I don't have a considered opinion about what the default should be), but I'd also want support for specifying it at the level of the individual key–value pair. Of course, even an implementation that didn't support all of this would be useful! -Philip -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/010001757ab1f633-6511db02-9764-4008-a0ec-088f33caafe9-00%40email.amazonses.com.
Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates
I didn't look at the code yet myself, but generally you want to minimize the amount of code you compile into (and so using a function is pretty minimal). Another reason is that a lot of stuff "just works" when you use functions (because they would be documented as functions and so come with certain expectations). Debugging stuff, other little details. But in the case of the contract system you might want macros because that way you can cooperate with the check syntax blame annotations (which need work in other parts of the contract library). Ben: if you have an example of the bad hash/dc error message I'd be interested to see it. Robby On Fri, Oct 30, 2020 at 12:14 PM William J. Bowman wrote: > Thanks! One follow-up: > > > 1. make these functions, not macros > The main implementation is a procedure, but I think I need a macro to get > the > syntactic interface I want. > > Is there some reason to avoid macros? > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/20201030171407.GP1611044%40williamjbowman.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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAL3TdOOGgigtq%2BP_fr5tmFf9M%3DvOKN64v-e3QBy3Enb5q%2BCkYw%40mail.gmail.com.
Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates
Thanks! One follow-up: > 1. make these functions, not macros The main implementation is a procedure, but I think I need a macro to get the syntactic interface I want. Is there some reason to avoid macros? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20201030171407.GP1611044%40williamjbowman.com.
Re: [racket-users] [racket users] Pollen tag question
If I remove my pollen.rkt from the directory and use: #lang pollen A B C D I get: '(root "A B" "\n" "C D”) But if I use: #lang pollen ◊(define foo "foo") A B C D I get: '(root " " "A B" "\n" " " "C D") Ievin -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/54B1567F-7ED0-4236-8220-BA74D4334EBF%40gmail.com.
Re: [racket-users] [racket users] Pollen tag question
> On Oct 29, 2020, at 9:21 PM, Sorawee Porncharoenwase
> wrote:
>
> Whoops. I meant:
>
> #lang pollen
>
> ◊(define (vb . s) s)
>
> ◊vb{ A B
>C D}
> and the output is:
>
> '(" A B" "\n" " " "C D")
>
> On Thu, Oct 29, 2020 at 9:19 PM Sorawee Porncharoenwase
> mailto:sorawee.pw...@gmail.com>> wrote:
> I think the issue is with vb. How does it work?
>
> If you try
>
> #lang pollen
>
> @(define (vb . s) s)
>
> ◊vb{ A B
>C D}
> you will find that it outputs:
>
> '(vb " A B"
> "\n"
> " "
> "C D")
> The third element is the space before “C”. It's not discarded.
>
> Also notice that the "start" of the line is at the marker shown below
>
>
>
>
> #lang pollen
>
> @(define (vb . s) s)
>
> ◊vb{ A B
> >>> C D}
> This is due to how @ syntax
>
> works.
Here’s my pollen.rkt:
#lang racket/base
(require pollen/decode pollen/misc/tutorial txexpr
#;(only-in racket make-list string->number))
(provide (all-defined-out))
(define (root . elements)
(txexpr 'root empty (decode-elements elements
#:txexpr-elements-proc decode-paragraphs
#:string-proc (compose1 smart-quotes smart-dashes
And here’s an initial test.html.pm:
#lang pollen
A B
C D
Which produces
'(root "A B" (br) "C D")
Now if I add the vb as you’ve done, but don’t use the tag:
#lang pollen
◊(define (vb . s) s)
A B
C D
I get this:
'(root "A B" (br) " " "C D")
Kevin
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/2202E524-AAC0-44D3-9B4B-C49216733900%40gmail.com.
Re: [racket-users] Contracts for (partially) specifying dictionary key -> value-predicates
On 10/29/20, William J. Bowman wrote: > I'm considering implementing, maybe as a library or a pull-request to > racket/dict, contracts for (partially) specifying which keys exist in a > dictionary and a contract for the value on that key. Great! Please make the contract error messages point out the bad key and bad value. The error messages from hash/dc are usually too big for me, and I end up moving my key-check and value-check contracts into a function that checks things one-by-one. (Maybe hash/dc can give better errors ... I never looked into a fix.) > I've got a quick prototype here: > > https://gist.github.com/wilbowma/7e97c8a38130c720568d008b288466f0 > > (dictof (id expr) ...) > A contract for a dictionary that contains exactly the keys id ... that map > to > values that satisfy the contracts expr ... (respectively). > > (rho-dictof (id expr) ...) > A contract for a dictionary that contains at least the keys id ... that > map to > values that satisfy the contracts expr ... (respectively). > > Before I start documenting and making it a thing, I thought I'd solicit > feedback. Two comments: 1. make these functions, not macros 2. make "at least" the default behavior for dictof, add an option to override (#:exact-keys?), and remove rho-dictof -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFUu9R7SMK%2BfCxGDHGm_eu%2BmTfcZ%2BZdC4R_dMceg%2Bn6VyY8oXQ%40mail.gmail.com.
