[racket-users] Re: [racket/racket] bc5556: raco pkg update: add `---unclone` as a kind of ali...
YAY! I can *never* remember this flag. Many thanks, John > On Apr 25, 2018, at 9:32 AM, Matthew Flatt wrote: > > Branch: refs/heads/master > Home: https://github.com/racket/racket > Commit: bc55560f8dcef2780c2b64a95c2fc89513e3f447 > > https://github.com/racket/racket/commit/bc55560f8dcef2780c2b64a95c2fc89513e3f447 > Author: Matthew Flatt > Date: 2018-04-25 (Wed, 25 Apr 2018) > > Changed paths: >M pkgs/racket-doc/pkg/scribblings/pkg.scrbl >M pkgs/racket-test/tests/pkg/tests-clone.rkt >M racket/collects/pkg/main.rkt > > Log Message: > --- > raco pkg update: add `---unclone` as a kind of alias for `--lookup` > > It's difficult to remember that the opposite of `--clone` is > effectively `--lookup`. > > -- 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] Re: RacketCon 2018 Website
Okay, Jay just merged my commit that makes the ascii art work with screen
readers. I still don't know if search engines will be able to pick it up (I
doubt it though), and its still hard to see when using screen magnifiers. I
think if we either used a different font, or slightly increased the space
between letters the problem would go away, maybe.
Thoughts?
~Leif Andersen
On Sat, Apr 21, 2018 at 1:44 AM, Jay McCarthy
wrote:
> On Sat, Apr 21, 2018 at 1:07 AM, Greg Hendershott
> wrote:
> > 0. Another consideration with the ASCII art font is that it won't get
> > indexed by search engines. This doesn't matter so much for the first
> > three, since the same info is in the page . But it means
> > searching for "Kent Dybvig" won't turn up this page.
>
> I think that someone with more CSS pizazz than me could put something in
> this
>
> line https://github.com/racket/racket-lang-org/blob/master/
> rcon/2018/pollen.rkt#L117
>
> and then in the CSS to put the text directly in there but hide/show it
> with certain media-types.
>
> > 1. The "organizers" href is "http://mailto:jay.mccar...@gmail.com"; --
> > which on some browsers opens gmail.com. I think
> > "mailto:jay.mccar...@gmail.com"; was meant.
>
> I think this is an error in Pollen or maybe an error in Jay. The code is
>
> ◊link["mailto:jay.mccar...@gmail.com"]{organizers}
>
> --
> -=[ Jay McCarthy http://jeapostrophe.github.io]=-
> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> -=[ Moses 1:33: And worlds without number have I created; ]=-
>
> --
> 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] Re: RacketCon 2018 Website
Side comment, for students... One way to do this kind of distributed hypertext Web page (for now; Tim Berners-Lee is giving a relevant big talk at MIT next week) is to start with an mid-1990s declarative model for all the content of the page (with minimal tweaks for HTML5), then do the CSS in terms of those structural elements and of any structural extensions you add (`div`, `span`, `id`, etc.). More bold static graphic design can be accomplished with the use of `img` (with `alt` attributes), more CSS, and SVG. Very judicious JS can be used for any dynamic graphic design that is not already covered by CSS and the layout engine, while keeping the static HTML semantic such that the page could usually still be viewed in a mid-1990s Mosaic (not that that's the goal, but it's a good test to be clear about where and how the content of the page should usually be encoded. (Then you use usually limit dynamic content to contexts that are inherently dynamic, not, as some do now, to use piles and piles of JS HTML frameworks as a GUI toolkit, to approximate the model that has always existed for the static, while breaking the Web as a distributed hypertext.) -- 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] Re: [racket/racket] bc5556: raco pkg update: add `---unclone` as a kind of ali...
This is awesome! I never knew that un-cloning can be done by using --lookup. Shu-Hung On Wed, Apr 25, 2018 at 12:35 PM, 'John Clements' via Racket Users wrote: > YAY! > > I can *never* remember this flag. > > Many thanks, > > John > >> On Apr 25, 2018, at 9:32 AM, Matthew Flatt wrote: >> >> Branch: refs/heads/master >> Home: https://github.com/racket/racket >> Commit: bc55560f8dcef2780c2b64a95c2fc89513e3f447 >> >> https://github.com/racket/racket/commit/bc55560f8dcef2780c2b64a95c2fc89513e3f447 >> Author: Matthew Flatt >> Date: 2018-04-25 (Wed, 25 Apr 2018) >> >> Changed paths: >>M pkgs/racket-doc/pkg/scribblings/pkg.scrbl >>M pkgs/racket-test/tests/pkg/tests-clone.rkt >>M racket/collects/pkg/main.rkt >> >> Log Message: >> --- >> raco pkg update: add `---unclone` as a kind of alias for `--lookup` >> >> It's difficult to remember that the opposite of `--clone` is >> effectively `--lookup`. >> >> > > > > -- > 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.
[racket-users] Unexpected pattern matching behavior
I'm confused by the behavior of pattern matching in some cases. I'll discuss a few sets of examples involving segment patterns, then a mix of `and`, `or`, and `not` patterns. Here is a basic segment pattern matching the entire contents of a list: > (match '(1 2 3) ((list x ...) `(result: ,x))) '(result: (1 2 3)) Let's add a prefix to the scrutinized list, and match it with a separate pattern variable: > (match '((1 2 3) 1 2 3) ((list w x ...) `(result: ,w ,x))) '(result: (1 2 3) (1 2 3)) Now let's constrain the prefix to be the same as the matched segment: > (match '((1 2 3) 1 2 3) ((list x x ...) `(result: ,x))) '(result: (1 2 3)) Everything seems fine so far. Let's make the segment pattern more interesting. This time, we'll have our segment pattern match elements that are lists of two elements: > (match '((a 1) (b 2) (c 3)) ((list (list k v) ...) `(result: ,k ,v))) '(result: (a b c) (1 2 3)) We can add a prefix as before, corresponding to the first element of each two-element list in the remaining segment, and match it with a separate pattern variable: > (match '((a b c) (a 1) (b 2) (c 3)) ((list j (list k v) ...) `(result: ,j ,k ,v))) '(result: (a b c) (a b c) (1 2 3)) So far so good. Now let's try constraining the prefix to be the same as the first element of each two-element list in the segment pattern: > (match '((a b c) (a 1) (b 2) (c 3)) ((list k (list k v) ...) `(result: ,k ,v))) ; k113: unbound identifier; ; also, no #%top syntax transformer is bound ; in: k113 ; [,bt for context] Something went wrong. Is this behavior expected? This error doesn't look like the kind you'd expect a user to see. Let's try another example with segment patterns: > (match '(1 2 3 : 1 2 3) ((list x ... ': y ...) `(result: ,x ,y))) '(result: (1 2 3) (1 2 3)) We're using : as a divider, allowing both the x and y segments to be non-empty. In this case, they are bound to the same values. What happens if we try to constrain the two segments to be identical by repeating the variable?: > (match '(1 2 3 : 1 2 3) ((list x ... ': x ...) `(result: ,x))) non-linear pattern used in `match` with ... at # and # '(result: (1 2 3)) It looks like we got the right result (see the next example), but it looks like an error message was printed beforehand. Is this message intended as a warning? Should it actually be raising an error instead? It almost looks like debug logging. Why might an error be the expected behavior? It seems we get the right result only coincidentally. If we remove the divider and use separate variables, we can see the greedy behavior of segment patterns: > (match '(1 2 3 1 2 3) ((list x ... y ...) `(result: ,x ,y))) '(result: (1 2 3 1 2 3) ()) When we try to constrain the segment by repeating the same variable, we get the printed warning followed by an unexpected result: > (match '(1 2 3 1 2 3) ((list x ... x ...) `(result: ,x))) non-linear pattern used in `match` with ... at # and # '(result: (1 2 3 1 2 3)) Is this greedy behavior expected even when the segment pattern variable is constrained in this way? It seems like we should at least get an error. Moving on, here's an example using `and` and `not` that behaves reasonably: > (match (list 1 2 3) ((and (list a _ _) (not (list _ a _))) `(result: ,a))) '(result: 1) We can see how the scrutinized list is being constrained to not repeat the same first two elements: > (match (list 1 1 3) ((and (list a _ _) (not (list _ a _))) `(result: ,a))) ; match: no matching clause for '(1 1 3) [,bt for context] If we swap the order of the sub-patterns, expecting the same behavior as the first example, we get a surprise: > (match (list 1 2 3) ((and (not (list _ a _)) (list a _ _)) `(result: ,a))) ; match: no matching clause for '(1 2 3) [,bt for context] It seems that the order of sub-patterns in an `and` pattern matters, and determines logical scoping of pattern variables. In the first pattern, we are getting the behavior of the logical proposition: (exists (a) (and (== VALUE (list a _ _)) (not (== VALUE (list _ a _) While in the second example, we seem to be getting the behavior of the logical proposition: (exists (a) (and (== VALUE (list a _ _)) (not (exists (a) (== VALUE (list _ a _)) Or, pushing the `not` inward slightly: (exists (a) (and (== VALUE (list a _ _)) (forall (a) (not (== VALUE (list _ a _)) Is this non-commutative behavior of `and` intended? Here's an example involving `and` and `or` that attempts to ensure that a three-element list either has identical first and second elements, or identical second and third elements: > (match (list 1 2 2) ((and (list a b c) (or (list _ a _) (list _ _ b))) 'success)) ; readline-input:2:47: match: variable not bound in all or patterns ; at: b ; in: (or (list _ a _) (list _ _ b)) ; [,bt for context] Given the binding behavior we saw with `and` in the previous example, I figured t
Re: [racket-users] Unexpected pattern matching behavior
There are a lot of examples here, so I'll try to offer a broad description of what's going on. 1. Non-linear patterns with `...` do not have the non-linear behavior that you'd want, and fixing this requires changing how `...` is implemented quite drastically. That's why there's a warning. It's not an error because some programs exist that rely on the (not right) behavior. 2. The unbound identifier problem is a bug. 3. `or` patterns indeed require that all of the disjuncts have the same pattern variables. 4. `and` is indeed ordered, and you can rely on the ordering. 5. Being under `not` doesn't lift these restrictions, even though it potentially could in some cases. It may well be that the documentation can be clarified here, and I'd be happy to take suggestions on how. And of course, 2 is a bug. Sam On Wed, Apr 25, 2018 at 4:54 PM, Greg Rosenblatt wrote: > I'm confused by the behavior of pattern matching in some cases. I'll > discuss a few sets of examples involving segment patterns, then a mix of > `and`, `or`, and `not` patterns. > > > Here is a basic segment pattern matching the entire contents of a list: >> (match '(1 2 3) > ((list x ...) `(result: ,x))) > '(result: (1 2 3)) > > Let's add a prefix to the scrutinized list, and match it with a separate > pattern variable: >> (match '((1 2 3) 1 2 3) > ((list w x ...) `(result: ,w ,x))) > '(result: (1 2 3) (1 2 3)) > > Now let's constrain the prefix to be the same as the matched segment: >> (match '((1 2 3) 1 2 3) > ((list x x ...) `(result: ,x))) > '(result: (1 2 3)) > > Everything seems fine so far. Let's make the segment pattern more > interesting. > > This time, we'll have our segment pattern match elements that are lists of > two elements: >> (match '((a 1) (b 2) (c 3)) > ((list (list k v) ...) `(result: ,k ,v))) > '(result: (a b c) (1 2 3)) > > We can add a prefix as before, corresponding to the first element of each > two-element list in the remaining segment, and match it with a separate > pattern variable: >> (match '((a b c) (a 1) (b 2) (c 3)) > ((list j (list k v) ...) `(result: ,j ,k ,v))) > '(result: (a b c) (a b c) (1 2 3)) > > So far so good. Now let's try constraining the prefix to be the same as the > first element of each two-element list in the segment pattern: >> (match '((a b c) (a 1) (b 2) (c 3)) > ((list k (list k v) ...) `(result: ,k ,v))) > ; k113: unbound identifier; > ; also, no #%top syntax transformer is bound > ; in: k113 > ; [,bt for context] > > Something went wrong. Is this behavior expected? This error doesn't look > like the kind you'd expect a user to see. > > > Let's try another example with segment patterns: >> (match '(1 2 3 : 1 2 3) > ((list x ... ': y ...) `(result: ,x ,y))) > '(result: (1 2 3) (1 2 3)) > > We're using : as a divider, allowing both the x and y segments to be > non-empty. In this case, they are bound to the same values. > > What happens if we try to constrain the two segments to be identical by > repeating the variable?: >> (match '(1 2 3 : 1 2 3) > ((list x ... ': x ...) `(result: ,x))) > non-linear pattern used in `match` with ... at # and > # > '(result: (1 2 3)) > > It looks like we got the right result (see the next example), but it looks > like an error message was printed beforehand. Is this message intended as a > warning? Should it actually be raising an error instead? It almost looks > like debug logging. > > Why might an error be the expected behavior? It seems we get the right > result only coincidentally. If we remove the divider and use separate > variables, we can see the greedy behavior of segment patterns: >> (match '(1 2 3 1 2 3) > ((list x ... y ...) `(result: ,x ,y))) > '(result: (1 2 3 1 2 3) ()) > > When we try to constrain the segment by repeating the same variable, we get > the printed warning followed by an unexpected result: >> (match '(1 2 3 1 2 3) > ((list x ... x ...) `(result: ,x))) > non-linear pattern used in `match` with ... at # and > # > '(result: (1 2 3 1 2 3)) > > Is this greedy behavior expected even when the segment pattern variable is > constrained in this way? It seems like we should at least get an error. > > > Moving on, here's an example using `and` and `not` that behaves reasonably: >> (match (list 1 2 3) >((and (list a _ _) (not (list _ a _))) `(result: ,a))) > '(result: 1) > > We can see how the scrutinized list is being constrained to not repeat the > same first two elements: >> (match (list 1 1 3) > ((and (list a _ _) (not (list _ a _))) `(result: ,a))) > ; match: no matching clause for '(1 1 3) [,bt for context] > > If we swap the order of the sub-patterns, expecting the same behavior as the > first example, we get a surprise: >> (match (list 1 2 3) > ((and (not (list _ a _)) (list a _ _)) `(result: ,a))) > ; match: no matching clause for '(1 2 3) [,bt for context] > > It seems that the order of sub-patterns in an `and` pattern matters, and > determines logical sco
