Re: [racket-users] hash->list with try-order? (like hash-map)
On Friday, October 22, 2021 at 6:45:18 PM UTC+2 david@gmail.com wrote: > On Thu, Oct 21, 2021 at 5:26 AM George Neuner wrote: > >> >> On 10/20/2021 5:53 PM, unlimitedscolobb wrote: >> >> >> > You can get a lot of mileage out of the 'set' datatype, which removes > ordering from the equation, especially since lists will act as sets in a > pinch. (When you want to improve performance, use 'in-set' and/or > 'list->set'. > > To see if 2 hashes contain the same set of keys: >> >> (and (= (hash-count hash1) (hash-count hash2)) >> (for/and ([k (in-list (hash-keys hash1))]) >>(hash-has-key? hash2 k))) >> > > Alternatively: > > (set=? (hash-keys hash1) (hash-keys hash2)) > > Ah, sure, good point! > > ; Return an unordered list of the keys that are in hash1 but not in hash2 > (set-subtract (hash-keys hash1) (hash-keys hash2)) > > ; Get a new hash consisting of the key/values that are in hash1 but not in > hash2 > (for/hash ([k (set-subtract (hash-keys hash1) (hash-keys hash2))]) > (values k (hash-ref hash1 k))) > > ; Get a ore detailed breakdown: > (require handy) > (define hash1 (for/hash ([k '(a b c d e f g)] [v 10]) (values k v))) > (define hash2 (for/hash ([k '(a b c d e z y)] [v 10]) (values k v))) > (define hash3 (hash-set* hash2 'c 111 'd 184)) > (disjunction hash1 hash3) > Result: > (dict-disjunction > '#hash((c . (2 111)) (d . (3 184))); values that differ between the hashes > '#hash((f . 5) (g . 6)) ; key/values that exist only in hash1 > '#hash((y . 6) (z . 5)) ; key/values that exist only in hash3 > '#hash((a . 0) (b . 1) (c . 2) (d . 3) (e . 4) (f . 5) (g . 6)) ; hash1 > '#hash((a . 0) (b . 1) (c . 111) (d . 3) (e . 4) (y . 6) (z . 5))) ; hash3 > > Wow, `handy` is very handy! I wasn't aware of its existence, but I'll guess you've got yourself a new user :-) > >> Unfortunately, there is no variant of "for" that creates mutable hashes. >> But the general form works for anything. >> > > If you don't mind inefficiency then handy can be, well, handy: > > (define imm-h (for/hash ([k '(a b c)][v 3]) (values k v))) > (immutable? imm-h) > (immutable? (hash->mutable imm-h)) > > hash->mutable takes an existing hash, which can be either immutable or > mutable, and adds its key/values to a new mutable hash one by one, then > returns that hash. > > Very nice! The handy module is a bit of a Fibber McGee that really needs to be broken > out. It's thoroughly documented, but unfortunately only in comments. > Converting that to proper scribble is one of my Copious Free Times projects. > > Ah, I see :-) /me looks at his own CFT projects and sighs lightly. - 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/0c1f416f-d254-4770-98e2-80f2873fc529n%40googlegroups.com.
Re: [racket-users] hash->list with try-order? (like hash-map)
On Thursday, October 21, 2021 at 11:26:16 AM UTC+2 gneuner2 wrote:
>
> On 10/20/2021 5:53 PM, unlimitedscolobb wrote:
>
> I have two main use cases for producing an ordered list from a hash table:
>
> 1. A canonical way to pretty print a hash table: In my projects, I carry
> around and print out hash tables a lot, so I like the elements to appear in
> the same order all the time, whatever that order may be. Luckily,
> `hash-map` orders symbols alphabetically and numbers according to the
> natural order, so it's perfect for my use.
>
>
> It's fine if it works for you. Just beware hashing on things like lists,
> structs, objects, etc.
>
>
Good point indeed, thank you.
> You might look into Laurent Orseau's "text-table" package. Tables are a
> great way to print structured output.
>
> Nice package! These are things which I typically want to do sometimes.
At the moment I rely on Org-mode: when evaluating a Racket source code
block, I can ask Org-mode to typeset the resulting list as a table, which
is often perfect for my purposes.
>
> 2. Testing the contents of a mutable hash table: The only way I found to
> that is to convert the hash table to an ordered list and compared it to the
> test list. This is clearly not the most efficient use of a hash table, but
> I can totally go with that, since it's about testing and not the actual
> performance.
>
> Of course, I am totally open to learning better ways of doing these things!
>
>
> Depends on what you're trying to do. Sometimes changing the data format
> IS the best way. That said ...
>
> Be aware that the code fragments below were just made up as I wrote this
> ... they have not been tested and may contain unbalanced parentheses but
> they should give you the idea. Nothing here depends on the ordering of
> data in the hashes. Also if you prefer "do" loops to "for" loops, you can
> use them instead.
>
> Note also the use of "in-list", "in-hash-pairs","in-mutable-hash-pairs".
> Racket "for" loops work with sequences, and although many data types -
> including lists and hashes - will implicitly ACT as sequences, explicitly
> using the relevant sequence constructors can make your "for" loops run
> faster.
>
> see https://docs.racket-lang.org/reference/sequences.html
>
>
Oh, sequences, of course! I try using them as much as I can in my code
because they are so nice, but I just forgot about them in this particular
situation :D
>
>=
>
>
> To see if 2 hashes contain the same set of keys:
>
> (and (= (hash-count hash1) (hash-count hash2))
> (for/and ([k (in-list (hash-keys hash1))])
>(hash-has-key? hash2 k)))
>
> There is a function "hash-keys-subset?" that checks if the keys in one
> hash are a subset of keys in another hash. It generally will be faster
> than an equivalent loop, but it requires that both hashes use the same key
> comparison function.
>
>
> To see if 2 hashes contain the same set of (k,v) pairs:
>
> ; immutable
> (for/and ([(k,v) (in-hash-pairs hash1)])
> (equal v (hash-ref hash2 k fail))
>
> ; mutable
> (for/and ([(k,v) (in-mutable-hash-pairs hash1)])
> (equal v (hash-ref hash2 k fail))
>
>
>
> Figuring out the difference between one hash vs another is a bit harder,
> but a loop similar to the equality check works for this also:
>
> (for/list ([(k,v) (in-{mutable-}hash-pairs hash1)]
> #:unless (equal v (hash-ref hash2 k fail)))
>(cons k v))
>
> Note that the ordering matters - the loop finds things that are in hash1
> but not in hash2. Also instead of creating a list of what's missing, you
> could create another hash:
>
> ; create immutable hash
> (for/hash ([(k,v) (in-{mutable-}hash-pairs hash1)]
> #:unless (equal v (hash-ref hash2 k fail)))
>(values k v))
>
> ; update a mutable hash
> (for ([(k,v) (in-{mutable-}hash-pairs hash1)]
> #:unless (equal v (hash-ref hash2 k fail)))
>(hash-set! result k v))
>
> Unfortunately, there is no variant of "for" that creates mutable hashes.
> But the general form works for anything.
>
>
>
> Obviously there is a theme here.
>
> You are free to mix and match things: if your test data already is in
> lists, you can use the lists directly - either as the source sequences or
> as the lookup targets (since it's only a test, searching lists with
> "member" et al shouldn't matter ).
>
>
Thank you for all these exam
Re: [racket-users] hash->list with try-order? (like hash-map)
Hi, Thank you George for your answer. On Wednesday, October 13, 2021 at 5:37:39 PM UTC+2 gneuner2 wrote: > > On 10/12/2021 7:01 PM, unlimitedscolobb wrote: > > I wrote myself this little function: > > > > (define (hash->ordered-list h) > > (hash-map h cons #t)) > > > > which uses the try-order? argument of hash-map. > > > > Is there a reason for hash->list not have an optional argument > > try-order? Or perhaps having such a standalone function would be > better? > > > > I was planning to submit a patch, but then I thought I may be missing > > something. > > > > - > > Sergiu > > > > I can't speak for the Racket team, but ... > > Hash tables entries inherently are unordered, so there really is no > reason to expect an ordered list from reading out the data. Also, the > docs indicate that 'try-order?' doesn't work for all data types - so it > may produce unexpected results. I have two main use cases for producing an ordered list from a hash table: 1. A canonical way to pretty print a hash table: In my projects, I carry around and print out hash tables a lot, so I like the elements to appear in the same order all the time, whatever that order may be. Luckily, `hash-map` orders symbols alphabetically and numbers according to the natural order, so it's perfect for my use. 2. Testing the contents of a mutable hash table: The only way I found to that is to convert the hash table to an ordered list and compared it to the test list. This is clearly not the most efficient use of a hash table, but I can totally go with that, since it's about testing and not the actual performance. Of course, I am totally open to learning better ways of doing these things! > Further, sorting the output potentially > can take a lot of extra time ... having never tried to get ordered > output from hash-map, I can only hypothesize that (at least in some > cases) it may be faster to create the unordered list and then sort it > than to try to produce an ordered list with 'try-order?'. > I scrounged around Racket sources a bit, and even though I am not sure I looked in the right place, I got the impression that that is what hash-map with try-order? set to #t does already: creating an unordered list out of the hash table and then `sort`ing it. Certainly, you are welcome to submit a change, but I think it would be > best to leave the existing behavior and make ordered output an addition. > > FYI, here's the PR: https://github.com/racket/racket/pull/4025 I pored a lot over this, and the reasoning which won at the end was that `hash->list` is basically a call to `hash-map` with `cons` as the function to apply. Thus, adding try-order? to hash->list is a very easy change, so why not have it. Just to be clear, my PR does not alter the default behavior of `hash->list`, and only adds an optional argument. - 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/a1e0bbd2-69f8-439e-b362-306c897926d3n%40googlegroups.com.
[racket-users] hash->list with try-order? (like hash-map)
Hi, I wrote myself this little function: (define (hash->ordered-list h) (hash-map h cons #t)) which uses the try-order? argument of hash-map. Is there a reason for hash->list not have an optional argument try-order? Or perhaps having such a standalone function would be better? I was planning to submit a patch, but then I thought I may be missing something. - 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/06052379-819d-45e1-8ea8-5dcced59d557n%40googlegroups.com.
[racket-users] Re: Racket v8.1
Hi Greg, I can run Racket on my Android phone via https://github.com/t184256/nix-on-droid , but last time I tried I couldn't get raco to work because of some weird file paths in Android/Termux. I have never tried running DrRacket though. - Sergiu On Tuesday, June 8, 2021 at 12:40:12 AM UTC+2 greg.d...@gmail.com wrote: > How can I run Racket 8.1 on Android? I'd love to run DrRacket natively > and/or run raco under Termux. Where can I find out more information? > Thanks, _Greg > > On Wednesday, May 5, 2021 at 9:39:22 AM UTC-7 johnbclements wrote: > >> -- >> Racket version 8.1 is now available from >> >> https://racket-lang.org/ >> >> >> - DrRacket tabs can be dragged, and have new close buttons. >> >> - Racket CS supports cross-compilation using `raco exe`. >> >> - Racket CS supports Android on 32-bit and 64-bit ARM processors. >> >> - The database library supports running queries in OS threads. >> >> - Check-Syntax arrows correctly identify the definition site of >> identifiers with contracts. >> >> - Racket CS performance has improved for structure predicates and >> accessors >> >> - Racket CS is faster at multiplying extremely large numbers and >> dividing large integers. >> >> - Racket CS allows callbacks to raise exceptions if they are annotated >> with `#:callback-exns?`. >> >> - New ephemeron hash tables simplify the implementation of tables where >> keys can refer to values. >> >> - Typed Racket supports for/foldr. >> >> - The stepper works for #lang htdp/*sl. >> >> - Struct signatures work for the ASL teaching language. >> >> The following people contributed to this release: >> >> Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Andrew >> Mauer-Oats, Anish Athalye, Ben Greenman, Bert De Ketelaere, Bob Burger, >> Bogdan Popa, Brian Adkins, Cameron Moy, David Van Horn, Dexter Lagan, >> Dominik Pantůček, Fred Fu, Greg Hendershott, Gustavo Massaccesi, Hazel >> Levine, Ismael Luceno, Jack Firth, Jarhmander, John Clements, Jörgen >> Brandt, Laurent Orseau, Lazerbeak12345, Matthew Flatt, Matthias >> Felleisen, Micah Cantor, Mike Sperber, Noah Ma, Patrick McCarty, Paulo >> Matos, Pavel Panchekha, Philip McGrath, Philippe Meunier, R. Kent >> Dybvig, Robby Findler, Ryan Culpepper, Ryan Kramer, Sam Tobin-Hochstadt, >> Sergiu Ivanov, Shu-Hung You, Sorawee Porncharoenwase, Stephen De >> Gabrielle, William J. Bowman, bmitc, xxyzz, yjqww6, and ymdarake >> >> Feedback Welcome >> -- >> >> -- 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/51e8dccf-385a-49e1-8a5d-9f3e6fba95c4n%40googlegroups.com.
Re: [racket-users] Package install conflicts on the Racket package catalog
Hi Sam, On Wednesday, May 5, 2021 at 10:38:03 PM UTC+2 Sam Tobin-Hochstadt wrote: > I think there's two things you're seeing. > > 1. The results hadn't yet updated for your typed-compose change. I no > longer see a conflict here: https://pkg-build.racket-lang.org/ Oh, that's right! I misread some update dates yesterday and I thought the conflict report was already for the latest version of my code. > 2. The conflicts page is for _all_ the packages in the whole package > catalog. That's why it always mentions mischief. > > Aaah, now things start to make sense, thank you! > The issue for on-macro and social-contract is that they both have a > file tests/private/util.rkt, which means they can't be installed at > the same time. > > Finally, mischief has that issue intentionally -- there are two > versions of it on the pkg server, one of which is the development > branch. It's true that it hasn't been updated recently, but that's the > idea. > > Got it, thanks! - Sergiu > Sam > > > On Wed, May 5, 2021 at 4:08 PM unlimitedscolobb > wrote: > > > > Hi, > > > > I'd like to chime back in and say that renaming manual.rkt to > typed-compose.rkt didn't seem to affect much the list of install conflicts > for typed-compose. I also get a lot of conflicts with mischief (but not > only), even though typed-compose doesn't depend on it, or doesn't even > define names which would be similar to what mischief defines. > > > > That's puzzling. > > > > - > > Sergiu > > > > On Wednesday, May 5, 2021 at 9:16:14 PM UTC+2 Siddhartha Kasivajhula > wrote: > >> > >> Hi, > >> I'd like to report that I'm seeing conflicts being reported on my > packages as well. I haven't made recent changes to these packages so the > conflicts seem to have appeared spontaneously. > >> > >> Here is one example: https://pkgs.racket-lang.org/package/lazytree > >> Clicking into the "conflicts" results in a 404. > >> > >> Another example: https://pkgs.racket-lang.org/package/on-macro > >> Here, clicking into "conflicts" seems to implicate, believe it or not, > the `mischief` package, of which it appears there are two separate versions > on the package index. This does seem rather mischievous, and maybe raco > doesn't like it? Yet, it doesn't look like either mischief or mischief-dev > have been changed in years, so I'm not sure why it should complain now > about these longstanding shenanigans. > >> > >> A third example: https://pkgs.racket-lang.org/package/social-contract > >> Clicking into "conflicts" once again seems to implicate mischief, but > mischief isn't even in the dependencies for this package so this just seems > unfair! > >> > >> On other packages that I've uploaded, the conflicts link was a 404. > >> > >> Similar questions as OP - should I fix something here, for instance by > avoiding the mischief dependency? Should mischief itself be updated in some > way? Or is this (as seems likely) caused by a recent change in the package > index, and if so, how should package authors respond (assuming it isn't a > bug)? What to do about the 404s -- e.g. is there a command to generate the > conflicts locally? > >> > >> Thanks, > >> > >> > >> > >> On Sun, May 2, 2021 at 6:59 AM unlimitedscolobb > wrote: > >>> > >>> Hi Jay, > >>> > >>> Thanks a lot for helping me read that file! > >>> > >>> I didn't know Scribble outputs shared the same namespace. I renamed > the documentation file to typed-compose.scrbl as you suggest and I'm > waiting for build reports from the package catalog. > >>> > >>> In fact, I hesitated between manual.scrbl and typed-compose.scrbl > initially, and couldn't find a reason to prefer one over the other. Now I > have a reason :-) > >>> > >>> - > >>> Sergiu > >>> > >>> On Saturday, May 1, 2021 at 3:23:47 PM UTC+2 jay.mc...@gmail.com > wrote: > >>>> > >>>> Howdy Sergiu, > >>>> > >>>> The conflicts file you link to has all the conflicts for everything > >>>> that `pkg-build` builds. The line relevant for you is: > >>>> > >>>> ``` > >>>> doc "manual": > >>>> bystroTeX cbor print-de
Re: [racket-users] Package install conflicts on the Racket package catalog
Hi, I'd like to chime back in and say that renaming manual.rkt to typed-compose.rkt didn't seem to affect much the list of install conflicts for typed-compose. I also get a lot of conflicts with mischief (but not only), even though typed-compose doesn't depend on it, or doesn't even define names which would be similar to what mischief defines. That's puzzling. - Sergiu On Wednesday, May 5, 2021 at 9:16:14 PM UTC+2 Siddhartha Kasivajhula wrote: > Hi, > I'd like to report that I'm seeing conflicts being reported on my packages > as well. I haven't made recent changes to these packages so the conflicts > seem to have appeared spontaneously. > > Here is one example: https://pkgs.racket-lang.org/package/lazytree > Clicking into the "conflicts" results in a 404. > > Another example: https://pkgs.racket-lang.org/package/on-macro > Here, clicking into "conflicts" seems to implicate, believe it or not, the > `mischief` package, of which it appears there are two separate versions > <https://pkgd.racket-lang.org/pkgn/search?q=mischief> on the package > index. This does seem rather mischievous, and maybe raco doesn't like it? > Yet, it doesn't look like either mischief or mischief-dev have been changed > in years, so I'm not sure why it should complain now about these > longstanding shenanigans. > > A third example: https://pkgs.racket-lang.org/package/social-contract > Clicking into "conflicts" once again seems to implicate mischief, but > mischief isn't even in the dependencies for this package so this just seems > unfair! > > On other packages that I've uploaded, the conflicts link was a 404. > > Similar questions as OP - should I fix something here, for instance by > avoiding the mischief dependency? Should mischief itself be updated in some > way? Or is this (as seems likely) caused by a recent change in the package > index, and if so, how should package authors respond (assuming it isn't a > bug)? What to do about the 404s -- e.g. is there a command to generate the > conflicts locally? > > Thanks, > > > > On Sun, May 2, 2021 at 6:59 AM unlimitedscolobb > wrote: > >> Hi Jay, >> >> Thanks a lot for helping me read that file! >> >> I didn't know Scribble outputs shared the same namespace. I renamed the >> documentation file to typed-compose.scrbl as you suggest and I'm waiting >> for build reports from the package catalog. >> >> In fact, I hesitated between manual.scrbl and typed-compose.scrbl >> initially, and couldn't find a reason to prefer one over the other. Now I >> have a reason :-) >> >> - >> Sergiu >> >> On Saturday, May 1, 2021 at 3:23:47 PM UTC+2 jay.mc...@gmail.com wrote: >> >>> Howdy Sergiu, >>> >>> The conflicts file you link to has all the conflicts for everything >>> that `pkg-build` builds. The line relevant for you is: >>> >>> ``` >>> doc "manual": >>> bystroTeX cbor print-debug ratchet riff simply-scheme typed-compose >>> ``` >>> >>> The solution is to rename your manual from `manual.scrbl` to >>> `typed-compose.scrbl`. Scribble outputs are in a kind of "global" >>> namespace. >>> >>> Jay >>> >>> -- >>> Jay McCarthy >>> Associate Professor @ CS @ UMass Lowell >>> http://jeapostrophe.github.io >>> Vincit qui se vincit. >>> >>> >>> -- >>> Jay McCarthy >>> Associate Professor @ CS @ UMass Lowell >>> http://jeapostrophe.github.io >>> Vincit qui se vincit. >>> >>> >>> On Sat, May 1, 2021 at 5:56 AM unlimitedscolobb >>> wrote: >>> > >>> > Hello, >>> > >>> > I checked my package >>> https://pkgd.racket-lang.org/pkgn/package/typed-compose recently and >>> noticed that it listed some "Conflicts" in the field "Most recent build >>> results". On the other hand, the separate field "Conflicts" slightly above >>> says "None". >>> > >>> > When I open the log shown in "Most recent build results" (attached) it >>> starts with the line "Install conflicts:", which as far as I get are not >>> the same thing as "Package Conflicts" explained here in the manual: >>> https://docs.racket-lang.org/pkg/Package_Concepts.html#(part._concept~3aconflicts) >>> >>> . >>> > >>> > Wha
Re: [racket-users] Package install conflicts on the Racket package catalog
Hi Jay, Thanks a lot for helping me read that file! I didn't know Scribble outputs shared the same namespace. I renamed the documentation file to typed-compose.scrbl as you suggest and I'm waiting for build reports from the package catalog. In fact, I hesitated between manual.scrbl and typed-compose.scrbl initially, and couldn't find a reason to prefer one over the other. Now I have a reason :-) - Sergiu On Saturday, May 1, 2021 at 3:23:47 PM UTC+2 jay.mc...@gmail.com wrote: > Howdy Sergiu, > > The conflicts file you link to has all the conflicts for everything > that `pkg-build` builds. The line relevant for you is: > > ``` > doc "manual": > bystroTeX cbor print-debug ratchet riff simply-scheme typed-compose > ``` > > The solution is to rename your manual from `manual.scrbl` to > `typed-compose.scrbl`. Scribble outputs are in a kind of "global" > namespace. > > Jay > > -- > Jay McCarthy > Associate Professor @ CS @ UMass Lowell > http://jeapostrophe.github.io > Vincit qui se vincit. > > > -- > Jay McCarthy > Associate Professor @ CS @ UMass Lowell > http://jeapostrophe.github.io > Vincit qui se vincit. > > > On Sat, May 1, 2021 at 5:56 AM unlimitedscolobb > wrote: > > > > Hello, > > > > I checked my package > https://pkgd.racket-lang.org/pkgn/package/typed-compose recently and > noticed that it listed some "Conflicts" in the field "Most recent build > results". On the other hand, the separate field "Conflicts" slightly above > says "None". > > > > When I open the log shown in "Most recent build results" (attached) it > starts with the line "Install conflicts:", which as far as I get are not > the same thing as "Package Conflicts" explained here in the manual: > https://docs.racket-lang.org/pkg/Package_Concepts.html#(part._concept~3aconflicts) > > . > > > > What are install conflicts? Should I fix them? What is the command that > generates that log? > > > > (typed-compose also used to have an undeclared dependency, which I have > just fixed by updating it's info.rkt.) > > > > - > > 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...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/03bfa876-6418-41a2-a37a-5c39ad13121cn%40googlegroups.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/eb380f03-7a73-40e7-a3a6-0e8c3252525an%40googlegroups.com.
[racket-users] Package install conflicts on the Racket package catalog
Hello, I checked my package https://pkgd.racket-lang.org/pkgn/package/typed-compose recently and noticed that it listed some "Conflicts" in the field "Most recent build results". On the other hand, the separate field "Conflicts" slightly above says "None". When I open the log shown in "Most recent build results" (attached) it starts with the line "Install conflicts:", which as far as I get are not the same thing as "Package Conflicts" explained here in the manual: https://docs.racket-lang.org/pkg/Package_Concepts.html#(part._concept~3aconflicts) . What are install conflicts? Should I fix them? What is the command that generates that log? (typed-compose also used to have an undeclared dependency, which I have just fixed by updating it's info.rkt.) - 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/03bfa876-6418-41a2-a37a-5c39ad13121cn%40googlegroups.com. Install conflicts: module ((lib "mischief/main.rkt")): mischief mischief-dev module ((lib "mischief/lang/config.rkt")): mischief mischief-dev module ((lib "mischief/match.rkt")): mischief mischief-dev module ((lib "mischief/place.rkt")): mischief mischief-dev module ((lib "no-debug/racket/base/lang/reader.rkt")): mischief mischief-dev module ((lib "mischief/visitor.rkt")): mischief mischief-dev doc "postmark": postmark postmark-client module ((lib "mischief/stylish/format.rkt")): mischief mischief-dev module ((lib "mischief/phrase.rkt")): mischief mischief-dev lib "swscale-4.dll": ffmpeg-i386-win32-3-4 ffmpeg-x86_64-win32-3-4 doc "manual": bystroTeX cbor print-debug ratchet riff simply-scheme typed-compose module ((lib "debug/low-level.rkt")): mischief mischief-dev module ((lib "mischief/transform.rkt")): mischief mischief-dev lib "swresample-2.dll": ffmpeg-i386-win32-3-4 ffmpeg-x86_64-win32-3-4 module ((lib "egg-herbie/to-egg-pattern.rkt")): egg-herbie-linux egg-herbie-osx egg-herbie-windows module ((lib "mischief/scribblings/debugging.scrbl")): mischief mischief-dev doc "image-colors": image-coloring image-colors module ((lib "mischief/tests/stylish.rkt")): mischief mischief-dev module ((lib "hill/king.rkt")): tweedledee tweedledum module ((lib "mischief/scribblings/metaprogramming-moderate.scrbl")): mischief mischief-dev module ((lib "image-coloring/main.rkt")): image-coloring image-colors module ((lib "mischief/stepper.rkt")): mischief mischief-dev module ((lib "mischief/memoize.rkt")): mischief mischief-dev module ((lib "mischief/preserve-expensive-metadata.rkt")): mischief mischief-dev lib "avutil-55.dll": ffmpeg-i386-win32-3-4 ffmpeg-x86_64-win32-3-4 module ((lib "debug/mischief.rkt")): mischief mischief-dev module ((lib "mischief/stylish/expression.rkt")): mischief mischief-dev module ((lib "debug/racket/base/lang/reader.rkt")): mischief mischief-dev module ((lib "colors-as-strings/main.rkt")): color-strings colors-as-strings module ((lib "mischief/contract.rkt")): mischief mischief-dev module ((lib "postmark/postmark.scrbl")): postmark postmark-client module ((lib "mischief/scribblings/fold.scrbl")): mischief mischief-dev module ((lib "mischief/web.rkt")): mischief mischief-dev module ((lib "mischief/scribblings/parse.scrbl")): mischief mischief-dev module ((lib "mischief/scribblings/metaprogramming-complex.scrbl")): mischief mischief-dev doc "rackunit-grade": racket-rackunit-grade rackunit-grade module ((lib "mischief/error.rkt")): mischief mischief-dev module ((lib "mischief/sort.rkt")): mischief mischief-dev module ((lib "mischief/scribblings/bindings.scrbl")): mischief mischief-dev module ((lib "mischief/scribblings/kernel-syntax.scrbl")): mischief mischief-dev module ((lib "debug/main.rkt")): mischief mischief-dev module ((lib "mischief/props/lang/reader.rkt")): mischief mischief-dev module ((lib "mischief/string.rkt")): mischief mischief-dev module ((lib "no-debug/main.rkt")): mischief mischief-dev module ((lib "mischief/dict.rkt")): mischief mischief-dev module ((lib "mischief/values.rkt")): mischief mischief-dev module ((lib "mischief/private/reify-value.rkt")): mischief mischief-dev module ((lib "mischief/function.rkt")): mischief mischief-dev module ((lib "rackunit/raco-grade.rkt")): racket-rackunit-grade rackunit-grade module ((lib "image-coloring/scribblings/image-colors.scrbl")): image-coloring image-colors lib "avcodec-57.dll": ffmpeg-i386-win32-3-4 ffmpeg-x86_64-win32-3-4 module ((lib "debug/racket.rkt")): mischief mischief-dev module ((lib "mischief/scribblings/printing.scrbl")): mischief mischief-dev module ((lib "mischief/stylish/signatures.rkt")): mischief mischief-dev module ((li
[racket-users] Re: [ANNOUNCE] New package typed-compose
Thank you for the feedback! I think this macro is a very nice idea and should indeed allow removing most compose-i functions, except maybe for compose-3 and compose-4, which can be examples of use of make-compose. I added a Contributing section to the README of the Git repo: https://git.marvid.fr/scolobb/typed-compose#contributing . Do you think you can make the modifications directly a git clone of my repository and submit the changes to me as patches? - Sergiu On Sunday, January 10, 2021 at 6:00:58 AM UTC+1 philngu...@gmail.com wrote: > Nice package. I don't have an account and don't know how to do pull > request on Marvid thing, but I suggest making a macro generating > `compose-n` for arbitrary (statically known) n, and export it along side > with the predefined compose-n functions, something along these lines: > > #lang typed/racket/base > > (provide make-compose > compose-3 compose-4) > > (require (for-syntax racket/base > racket/match > racket/list > racket/syntax > syntax/parse)) > > (define-for-syntax (make-compose-type n) > (with-syntax* ([(t ...) (generate-temporaries (make-list n 't))] > [a (generate-temporary 'a)] > [(_ ... t₀) #'(a t ...)] > [(F ...) > (let step ([u #'a] [ts (syntax->list #'(t ...))]) > (match ts > ['() '()] > [(cons t ts*) (cons #`(#,t → #,u) (step t ts*))]))]) > #'(∀ (a t ...) (F ... → t₀ → a > > (define-syntax make-compose > (syntax-parser > [(_ n:nat) > (with-syntax* ([(f ...) (generate-temporaries (make-list (syntax-e > #'n) 'f))] > [x (generate-temporary 'x)] > [T (make-compose-type (syntax-e #'n))] > [body (foldr (λ (fᵢ res) #`(#,fᵢ #,res)) #'x > (syntax->list #'(f ...)))]) >#'(ann (λ (f ...) (λ (x) body)) T))])) > > (define compose-3 (make-compose 3)) > (define compose-4 (make-compose 4)) > ;; and so on > > > > On Monday, January 4, 2021 at 12:52:11 PM UTC-8 unlimitedscolobb wrote: > >> Hello, >> >> I am glad to announce typed-compose, a small package defining some >> utilities for composing functions in Typed Racket: >> >> https://pkgd.racket-lang.org/pkgn/package/typed-compose >> >> Typed Racket's compose only takes two arguments, because in general it >> is difficult to specify that the return types and the argument types should >> be the same for two successive functions in the argument list. This package >> defines some further utilities to allow compose-ing more than two >> functions more comfortable in Typed Racket. >> >> This is my first ever Racket package, so I'm taking all kinds of feedback. >> >> - >> 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/25e19ab5-54ea-40b2-a1c0-621982b520a9n%40googlegroups.com.
[racket-users] [ANNOUNCE] New package typed-compose
Hello, I am glad to announce typed-compose, a small package defining some utilities for composing functions in Typed Racket: https://pkgd.racket-lang.org/pkgn/package/typed-compose Typed Racket's compose only takes two arguments, because in general it is difficult to specify that the return types and the argument types should be the same for two successive functions in the argument list. This package defines some further utilities to allow compose-ing more than two functions more comfortable in Typed Racket. This is my first ever Racket package, so I'm taking all kinds of feedback. - 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/f0024b3e-65af-4687-8ee6-0135e22d8518n%40googlegroups.com.
[racket-users] Re: Typed Racket: require macros from untyped modules
I continued doing various tests and realized that my problem was something else, since the following code works: #lang typed/racket (module untyped-submodule racket (provide a macro) (define a 2) (define-syntax-rule (macro arg) (+ 1 arg))) (require 'untyped-submodule) (macro 3) Using a in the enclosing module doesn't work (a is required without a type), but macro works fine. Getting back to thinking and trying. - Sergiu On Sunday, January 3, 2021 at 9:22:16 PM UTC+1 unlimitedscolobb wrote: > Hello, > > How can I require macros coming from untyped modules into typed modules? > > Intuitively I'd expect that to be possible in a way or another because > such imports don't seem to violate any safety guarantees, but maybe I'm > missing something. > > - > 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/937fdcb5-2e59-46da-8a16-1262d35a97d1n%40googlegroups.com.
[racket-users] Typed Racket: require macros from untyped modules
Hello, How can I require macros coming from untyped modules into typed modules? Intuitively I'd expect that to be possible in a way or another because such imports don't seem to violate any safety guarantees, but maybe I'm missing something. - 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/b4315813-0a63-4a1f-a1d5-1ea344cd5c67n%40googlegroups.com.
[racket-users] Package typed/graph (was require/typed and opaque structures)
Since apparently I am not the only one wanting to use graphs in Typed Racket, I will prepare a typed interface to Stephen Chang's graph library: typed-graph. I am planning to upload it to the main package catalog. If you have any advice or ideas, or want to contribute to the effort, do tell me. - Sergiu On Wednesday, December 23, 2020 at 11:59:16 PM UTC+1 unlimitedscolobb wrote: > Hello, > > Again, a question out of curiosity, because I think I found a solution, > but I'd like to have something more elegant. > > I'm trying to use the (untyped) Racket generic graph library from my Typed > Racket code: > > #lang typed/racket > > (require/typed graph > [#:opaque Graph graph?] > [directed-graph (->* ((Listof (List Any Any))) ((Listof Any)) Graph)]) > > (directed-graph '((a b) (b c))) > > When I load this code in the REPL I get > > graph?: contract violation > any-wrap/c: Unable to protect opaque value passed as `Any` > value: # > This warning will become an error in a future release. > in: the 1st argument of > a part of the or/c of > (or/c >struct-predicate-procedure?/c >(-> Any boolean?)) > contract from: (interface for graph?) > blaming: /dds/tmp.rkt >(assuming the contract is correct) > at: /dds/tmp.rkt:4.18 > # > > I found this solution by Alex Knauth: > https://stackoverflow.com/questions/65386334/racket-generic-graph-library-in-typed-racket > > , which essentially consists in wrapping the opaque graph struct into > another struct. Alex says that the problem comes from the fact that graph? > essentially encompasses a couple different internal representations the > graph library uses. > > While this solution should fit me, I was wondering whether anybody here > has encountered this issue and has a different solution. > > - > 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/0073afbf-4309-4573-a8fc-aa4bfd4e4d77n%40googlegroups.com.
[racket-users] require/typed and opaque structures
Hello, Again, a question out of curiosity, because I think I found a solution, but I'd like to have something more elegant. I'm trying to use the (untyped) Racket generic graph library from my Typed Racket code: #lang typed/racket (require/typed graph [#:opaque Graph graph?] [directed-graph (->* ((Listof (List Any Any))) ((Listof Any)) Graph)]) (directed-graph '((a b) (b c))) When I load this code in the REPL I get graph?: contract violation any-wrap/c: Unable to protect opaque value passed as `Any` value: # This warning will become an error in a future release. in: the 1st argument of a part of the or/c of (or/c struct-predicate-procedure?/c (-> Any boolean?)) contract from: (interface for graph?) blaming: /dds/tmp.rkt (assuming the contract is correct) at: /dds/tmp.rkt:4.18 # I found this solution by Alex Knauth: https://stackoverflow.com/questions/65386334/racket-generic-graph-library-in-typed-racket , which essentially consists in wrapping the opaque graph struct into another struct. Alex says that the problem comes from the fact that graph? essentially encompasses a couple different internal representations the graph library uses. While this solution should fit me, I was wondering whether anybody here has encountered this issue and has a different solution. - 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/e2899e3e-7f2c-42cd-a994-2b711423a7aan%40googlegroups.com.
Re: [racket-users] Scribble and main.rkt
Thanks a lot, that's perfectly clear and worked for me!
I'll go with main.rkt though, because requiring the package is simpler this
way.
-
Sergiu
On Tuesday, December 22, 2020 at 3:46:03 PM UTC+1 Ben Greenman wrote:
> > Is it correct that calling the main file of the package something else
> than
> > main.rkt is bad style, unsupported by Scribble?
>
> It's okay to call the main file something else, but you'll have to
> tell Scribble about it.
>
> Right now, I guess you have a @defmodule[typed-compose]{}
> somewhere. That would tell Scribble that the defprocs below come from
> typed-compose/main.rkt
>
> If the main module is typed-compose.rkt, then a
> @defmodule[typed-compose/typed-compose]{} should fix the broken
> links.
> (And, it'll tell readers how to require the things below.)
>
--
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/36f2a486-432b-41c7-b395-37f30f7a3d27n%40googlegroups.com.
[racket-users] Scribble and main.rkt
Hello,
This is mainly a question out of curiosity, because I think I figured out
how to do what I want.
I'm setting up a small (8 functions and 2 macros) package called
typed-compose. I called the main file typed-compose.rkt (not main.rkt) and
put the following in the preamble of typed-compose.scrbl:
@(require scribble/example racket/sandbox
(for-label racket/base "typed-compose.rkt"
(only-in typed/racket/base
-> compose)))
I then get the following undefined tag errors:
WARNING: undefined tag in /typed-compose/typed-compose.scrbl:
((lib "typed-compose/typed-compose.rkt") compose-3)
((lib "typed-compose/typed-compose.rkt") compose-4)
((lib "typed-compose/typed-compose.rkt") compose-n)
((lib "typed-compose/typed-compose.rkt") multi-chain)
((lib "typed-compose/typed-compose.rkt") multi-compose)
These symbols happen to be those for which typed-compose.scrbl has defproc
or defform statements.
Weirdly, evaluators set up by the following code work no problem:
@(define typed-compose-evaluator
(parameterize ([sandbox-output 'string]
[sandbox-error-output 'string]
[sandbox-memory-limit 50])
(make-evaluator 'typed/racket/base #:requires '("typed-compose.rkt"
If I now rename typed-compose.rkt to main.rkt and update all the references
to this file, everything works fine. Everything also works fine if I
replace "main.rkt" by typed-compose in typed-compose.scrbl.
I read up some docs and recalled that main.rkt is what require
automatically looks for when I give it a collection name (not a file
name). However, I am somewhat surprised to see (require (for-label
"typed-compose.rkt")) fail in this context.
Is it correct that calling the main file of the package something else than
main.rkt is bad style, unsupported by Scribble?
-
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/d115ae86-6700-4526-8b22-dd62a461a80bn%40googlegroups.com.
Re: [racket-users] compose in Typed Racket
Oh wow, that's impressively better than what I wrote! I didn't know one could have *recursive* macros, to say nothing about the proper usage of syntax-parse. Thank you very much for your quick answer! - Sergiu On Wednesday, December 16, 2020 at 11:03:49 PM UTC+1 sorawe...@gmail.com wrote: > syntax-parse can already perform pattern matching. No need to use match > > (define-syntax (multi-compose stx) > (syntax-parse stx > [(_ f:expr g:expr) > #'(compose f g)] > [(_ f:expr funcs:expr ...) > #'(compose f (multi-compose funcs ...))])) > > > On Wed, Dec 16, 2020 at 1:37 PM unlimitedscolobb > wrote: > >> On Thursday, December 10, 2020 at 6:01:52 PM UTC+1 unlimitedscolobb wrote: >> >>> On Thursday, December 10, 2020 at 5:49:43 PM UTC+1 hen...@topoi.pooq.com >>> wrote: >>> >>> A macro might be able to generate either of the above from >>>> (comp f g h k) >>>> . >>>> >>> Indeed. I'm re-reading the docs on macros and I think I see a clean and >>> clear way to achieve what I need. >>> >>> I'll post my attempt as soon as I get the time to write it. >>> >>> >> Okay, so this is my shot: >> >> #lang typed/racket >> >> (require (for-syntax syntax/parse racket/match)) >> >> (define-syntax (multi-compose stx) >> (syntax-parse stx >> [(_ funcs:expr ...) >> (match-define (list fn fn-1 fs ...) >>(reverse (syntax->list #'(funcs ... >> (datum->syntax stx (for/fold ([sexp `(compose ,fn-1 ,fn)]) >> ([f (in-list fs)]) >> `(compose ,f ,sexp)))])) >> >> (multi-compose f1 f2 ... fn-1 fn) expands to (compose f1 (compose f2 ( >> ... (compose fn-1 fn) ... ))) >> >> My syntax-transformation-fu is essentially non-existent, even after >> reading through Greg's Fear of Macros multiple times, so please do tell me >> if you see some flagrant opportunities for improvement in the code above. >> >> I'm planning to throw together a small package with compose-n , compose-3 >> to compose-10, and multi-compose, and publish it. It would normally be my >> Christmas package for myself, but it make take some more time :-) >> >> - >> 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...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/219c189f-dd93-4b18-9ef9-2ff477ce3a15n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/racket-users/219c189f-dd93-4b18-9ef9-2ff477ce3a15n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/f067ec8c-ed47-4718-944b-eb3a40e53234n%40googlegroups.com.
Re: [racket-users] compose in Typed Racket
On Thursday, December 10, 2020 at 6:01:52 PM UTC+1 unlimitedscolobb wrote: > On Thursday, December 10, 2020 at 5:49:43 PM UTC+1 hen...@topoi.pooq.com > wrote: > > A macro might be able to generate either of the above from >> (comp f g h k) >> . >> > Indeed. I'm re-reading the docs on macros and I think I see a clean and > clear way to achieve what I need. > > I'll post my attempt as soon as I get the time to write it. > > Okay, so this is my shot: #lang typed/racket (require (for-syntax syntax/parse racket/match)) (define-syntax (multi-compose stx) (syntax-parse stx [(_ funcs:expr ...) (match-define (list fn fn-1 fs ...) (reverse (syntax->list #'(funcs ... (datum->syntax stx (for/fold ([sexp `(compose ,fn-1 ,fn)]) ([f (in-list fs)]) `(compose ,f ,sexp)))])) (multi-compose f1 f2 ... fn-1 fn) expands to (compose f1 (compose f2 ( ... (compose fn-1 fn) ... ))) My syntax-transformation-fu is essentially non-existent, even after reading through Greg's Fear of Macros multiple times, so please do tell me if you see some flagrant opportunities for improvement in the code above. I'm planning to throw together a small package with compose-n , compose-3 to compose-10, and multi-compose, and publish it. It would normally be my Christmas package for myself, but it make take some more time :-) - 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/219c189f-dd93-4b18-9ef9-2ff477ce3a15n%40googlegroups.com.
Re: [racket-users] compose in Typed Racket
On Thursday, December 10, 2020 at 9:51:50 PM UTC+1 Ben Greenman wrote: > >> A package for compose-n and compose-3 to like 10 or 20? > > Yes > > I like the idea of _small packages that do one thing_ better than > _one-stop all-utility packages_ ... but do what you think makes sense. > Sounds reasonable to me, I'll create that package soon. Thanks for the advice. > >> Someday later, perhaps poly dots and #:rest-star can combine to > >> improve the built-in type. > >> > > > > From my naive viewpoint, I don't really see other natural ways of > improving > > the type of compose other than what I wrote, the problem being that > writing > > the type for arbitrary-arity composition would require specifying > equality > > between the return type of every function and the argument type of the > > preceding one. I'm not sure even Coq and Agda have that facility > directly, > > certainly not Haskell or Idris to the best of my knowledge. I don't > expect > > them to go beyond binary compose, because it's sufficient to do any > > compositions. It's that in Racket I find writing chains of nested > compose > > calls somewhat clunky. > > Typed Racket already has some domain-specific ideas to support the > #:rest-star option. The equality-chaining constraint is definitely > new, but doesn't seem out of the question. > > > https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/rep/type-rep.rkt#L586-L612 I see, #:rest-star seems quite powerful. I'm curious to see what kind of stuff will come out of it. I think other languages (Coq Agda Haskell Idris) have a harder time > here because they want to support currying. And even if they added > #:rest-star logic, their users might call it an anti-pattern because > it doesn't fit with partial application. > That's a good point. I started forgetting how important implicit currying is in these languages. - 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/164ca420-75dc-4241-b512-dea79fe6e0aan%40googlegroups.com.
Re: [racket-users] compose in Typed Racket
On Thursday, December 10, 2020 at 5:49:43 PM UTC+1 hen...@topoi.pooq.com wrote: > On Wed, Dec 09, 2020 at 10:16:16PM -0800, unlimitedscolobb wrote: > > > I'm not sure whether macros could be of use here. I'll give it a think. > > Idea: Have a look at parendown > https://docs.racket-lang.org/parendown/index.html > > It would let you write > (compose f > (compose g > (compose h k))) > as > ( compose f > #/ compose g > #/ compose h k > ) > > Which at least cuts down on the heavy indentation and parenthesis pile-up. > > Interesting, thank you. I haven't yet tried parendown, but the more I see mentions of it the more likely I'm to try it out :-) > A macro might be able to generate either of the above from > (comp f g h k) > . > Indeed. I'm re-reading the docs on macros and I think I see a clean and clear way to achieve what I need. I'll post my attempt as soon as I get the time to write it. - 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/94f9eb1e-00bf-4ac7-81bd-24dc4235d8a0n%40googlegroups.com.
Re: [racket-users] compose in Typed Racket
On Wednesday, December 9, 2020 at 11:50:26 PM UTC+1 Ben Greenman wrote: > > If the answer is no, is there any interest in including these three > > functions (as well as compose-5, 6, 7, 8) into Typed Racket? > > I think these would be excellent in a package. > > A package for compose-n and compose-3 to like 10 or 20? I'm still not sure about how high the granularity of packages may get in Racket, but I'd like to share these functions, because they feel very useful to me. > Someday later, perhaps poly dots and #:rest-star can combine to > improve the built-in type. > >From my naive viewpoint, I don't really see other natural ways of improving the type of compose other than what I wrote, the problem being that writing the type for arbitrary-arity composition would require specifying equality between the return type of every function and the argument type of the preceding one. I'm not sure even Coq and Agda have that facility directly, certainly not Haskell or Idris to the best of my knowledge. I don't expect them to go beyond binary compose, because it's sufficient to do any compositions. It's that in Racket I find writing chains of nested compose calls somewhat clunky. I'm not sure whether macros could be of use here. I'll give it a think. - 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/d0eacc64-c11b-4edd-aa38-c62c15494c06n%40googlegroups.com.
[racket-users] compose in Typed Racket
Hello, I've found out that compose in Typed Racket has the type (: compose (All (a b c) (-> (-> b c) (-> a b) (-> a c which means that Typed Racket's compose can only combine two functions at a time. In untyped code, I tend to use compose to combine more functions (e.g., 7), so I wrote myself the following definitions: (: compose-n (All (a) (-> (-> a a) * (-> a a (define (compose-n . funcs) (λ (x) (for/foldr ([x x]) ([f funcs]) (f x (: compose-3 (All (a b c d) (-> (-> c d) (-> b c) (-> a b) (-> a d (define (compose-3 f1 f2 f3) (λ (x) (f1 (f2 (f3 x) (: compose-4 (All (a b c d e) (-> (-> d e) (-> c d) (-> b c) (-> a b) (-> a e (define (compose-4 f1 f2 f3 f4) (λ (x) (f1 (f2 (f3 (f4 x)) Is there a better way to chain compose calls in Typed Racket? If the answer is no, is there any interest in including these three functions (as well as compose-5, 6, 7, 8) into Typed Racket? - 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/98bb349f-5de9-4e19-bc7d-d8c2be4d8c9an%40googlegroups.com.
[racket-users] Re: Cannot install packages in DrRacket
Hi Teo, I had this issue last week, and here's what I found: https://github.com/mbutterick/pollen/issues/239 TL;DR : raco pkg config --set catalogs https://download.racket-lang.org/releases/7.9/catalog/ "" I don't exactly what causes this issue, though. - Sergiu On Thursday, December 3, 2020 at 10:41:20 AM UTC+1 deepintocode wrote: > > Hi all, > > It is just me, or is there an issue with the package manager? > > I tried installing *the sicp* and *simply-scheme *packages through the > graphical package manager and through the terminal using *raco pkg > install*, but they both result in the same error: > > raco pkg install sicp > Resolving "sicp" via > https://download.racket-lang.org/releases/7.9/catalog/ > raco pkg install: cannot find package on catalogs > > Also, the page https://download.racket-lang.org/releases/7.9/catalog/ > returns a 404 page. > > Thanks, > Teo > -- 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/7629d4db-0680-45d0-9cdf-6e620e70c156n%40googlegroups.com.
Re: [racket-users] Historical note.
On Monday, November 9, 2020 at 1:51:05 AM UTC+1 Kieron Hardy wrote: > > > On Nov 8, 2020, at 2:58 PM, Hendrik Boom wrote: > > > >> On Sun, Nov 08, 2020 at 12:47:11PM -0800, unlimitedscolobb wrote: > >> The idea of having structs whose fields contain functions has never > occurred to me ... > > > > Historical note: > > > > I first encountered structures containing function in the source code > for > > OS/360 way back in the late 60's. In assembler. > > > Structures with fields containing functions has never occurred to me > before, either, at least not in those terms. > > However isn’t that exactly one of the key design principles behind how > device-drivers are implemented and installed into an OS? And also how > classes and objects were initially added to C as some pretty hairy #define > macros and function pointers? > > This design pattern insight would have been beneficial to me sooner - doh! > > I completely share your feelings Kieron. In fact, I have already defined structures with functions in the fields multiple times and in many programming languages, but I have never thought how this pattern could be used to implement generic-like functionality :D Thank you Hendrik for the historical note! - 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/2fa2c643-04cd-4b59-9842-c68913124505n%40googlegroups.com.
[racket-users] Re: Generics vs. Classes?
Thank you for you answer! I'll need to think more about it. The idea of having structs whose fields contain functions has never occurred to me, but it may actually fit my relatively simple use case (and the planned migration to Typed Racket). - Sergiu On Sunday, November 8, 2020 at 8:22:16 PM UTC+1 jackh...@gmail.com wrote: > The typical use case for classes in Racket is writing GUIs, and that's > mostly because the GUI framework is class based. > > For most other use cases, generics are a better choice than classes. > They're simpler and have a less intrusive effect on your API surface. If > you don't need to support arbitrary user implementations, you can avoid > generics and classes altogether and use structs whose fields contain > functions. > > On Sunday, November 8, 2020 at 6:12:37 AM UTC-8 unlimitedscolobb wrote: > >> Hi, >> >> A general knowledge question: what would be the typical use cases of >> Racket generics vs. the typical use cases of Racket classes? >> >> Am I correct in assuming that I can do everything with classes what I >> could do with generics, and that generics have made their way into the >> language before the classes? >> >> - >> Sergiu >> >> P.S. I'm reading the section on classes in the updated Typed Racket >> reference, and I'm very happy to see this new functionality! Very good job >> the Typed Racket Team! >> > -- 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/dccc148b-6f20-42c0-a5bf-c5a7f42b3bd2n%40googlegroups.com.
[racket-users] Generics vs. Classes?
Hi, A general knowledge question: what would be the typical use cases of Racket generics vs. the typical use cases of Racket classes? Am I correct in assuming that I can do everything with classes what I could do with generics, and that generics have made their way into the language before the classes? - Sergiu P.S. I'm reading the section on classes in the updated Typed Racket reference, and I'm very happy to see this new functionality! Very good job the Typed Racket Team! -- 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/e992ac74-4aed-4b3f-a160-193bd7fb6026n%40googlegroups.com.
[racket-users] Re: hash-filter: PR or not PR
On Saturday, October 31, 2020 at 10:32:22 AM UTC+1 jackh...@gmail.com wrote: > This is definitely a useful thing to have and I've wanted it myself > before. However I'm generally of the opinion that we should avoid making > more collection manipulation functions that are unnecessarily specialized > to one type of collection. I completely agree, and I think this is one of the reasons I felt the need to ask the question. > I'd like to see functions that operate on all sequences rather than on > hash tables alone. Here are some usages of hash-filter compared with some > existing alternatives: > > (hash-filter ht #:predicate pred) > == > ; Sequence composition > (make-immutable-hash > (sequence->list > (sequence-filter (lambda (pair) (pred (cdr pair))) >(sequence-map cons ht > == > ; For macros > (for/hash ([(k v) (in-hash ht)] #:when (pred v)) (values k v)) > Yeah! I was looking at iteration macros, but forgot about #:when! Thank you for reminding me, this code is good enough for my immediate purposes and I'll ditch hash-filter. Iteration macros in Racket are ridiculously powerful and even though I use them all the time, I still don't feel like I know them well. > The for macro is probably what I'd reach for in standard racket code. It > has some drawbacks: the first time I tried to write it I forgot to write > (values k v) and instead just wrote v. Keeping track of pulling apart the > key and value, naming them with variables, and putting them back together > is a little annoying. > > The sequence composition approach is, in my humble opinion, completely > unreadable and difficult to write to boot. The sequence-map function works > totally fine on multivalued sequences but sequence-filter only works on > single-value sequences, so we have to do a dance with cons car and cdr to > turn the multivalued sequence of keys and values into a single-valued > sequence of key-value cons pairs. Furthermore, the only built-in function > for building a hash table from a sequence is overly specialized to lists, > so you have to copy the sequence into a list solely so you can turn that > list into a hash table with make-immutable-hash. > I completely agree with your reasoning about the readability. I'm also a little bit concerned about the performance of converting sequences to lists before building the hash table, but I'm not yet knowledgeable enough about these questions. > Instead of adding hash-filter to racket/hash, I think there's a few > improvements we could make to the sequence composition side of things: > > - Make sequence-filter allow multivalued sequences, provided the arity of > the predicate is consistent with the arity of the sequence. > - Add a sequence->hash function that accepts a multivalued sequence of > keys and values (exactly like what in-hash produces) and copies them into a > hash table. > These sound interesting, thank you! I feel like I'd give both a try, but no promises :-) For the filter-by-value, filter-by-key, and filter-by-key-and-value cases, > this lets us write: > > (sequence->hash (sequence-filter (lambda (k v) (pred v)) ht)) ; Filter > values > (sequence->hash (sequence-filter (lambda (k v) (pred k)) ht)) ; Filter keys > (sequence->hash (sequence-filter pred ht)) ; Filter key-value pairs > Very nice ! Which is close enough to hash-filter to satisfy my desire for conciseness, > while still being general enough to work with other kinds of key-value > sequences. > > Shameless self plug: you might be interested in Rebellion > <https://docs.racket-lang.org/rebellion/index.html>'s take on this, which > uses transducers <http://goog_836594457> and key-value structs called > entries <https://docs.racket-lang.org/rebellion/Entries.html>: > I've never heard about Rebellion before in fact, thank you for the self plug :-) I started reading the docs, and my first impressions are that your library is very featureful and that it solves some of the small issues I've had with core Racket collections (e.g., the option structure, the unification of collection algorithms, etc.). I'll keep on reading and see how I can use Rebellion and/or contribute, thanks! - Sergiu (transduce (in-hash-entries ht) (filtering-values pred) #:into into-hash) ; > Filter values > (transduce (in-hash-entries ht) (filtering-keys pred) #:into into-hash) ; > Filter keys > (transduce (in-hash-entries ht) (filtering (lambda (e) (pred (entry-key e) > (entry-value e #:into into-hash) ; Filter key-value entries > On Friday, October 30, 2020 at 4:35:31 PM UTC-7 unlimitedscolobb wrote: > >> Hi, >
[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.
[racket-users] Re: “If you could have a wish granted, what would you like to see next in Racket?”
> but I would be surprised if it was on par with Racket's macro and type system, but who knows? I worked through the Julia user manual last year and my impression is that their macro system is probably less powerful than Racket's, but that their types are more powerful than Racket's. When reading the chapter on types [0], I felt like I was doing Haskell. Disclaimer, though: I never really developed anything in Julia, and my Racket development experience is still quite limited. - Sergiu [0] https://docs.julialang.org/en/v1/manual/types/ On Saturday, July 25, 2020 at 11:19:19 AM UTC+2, Marc Kaufmann wrote: > > 1. More how-to guides/good practice guides and discussions of some Racket > specific features: continuations (especially for the web); Typed Racket; > parameters/dynamic scope. Maybe macros, but I don't use them, so can't > comment on whether I'd miss how-tos for it. I like "the 4 types of > documentation" (https://documentation.divio.com/), and think Racket does > great on reference, well on tutorials, and when one knows where to look for > also often on 'discussion' - but how-to's are too sparse for me, so I end > up with stupid code for situations that feel fairly standard. > > 2. I am interested in using Racket for symbolic maths/simulations/etc and > Rosette seems to provide one big useful block. It would be great to have > support for numerics in Racket, probably by integrating well with the > Python/R/Julia universe of packages. There is no point in rebuilding much > of it from scratch, it seems too huge, but it would be nice to use Racket's > features in a way that integrates nicely with the numerics. Julia > apparently has a good macro system, but I would be surprised if it was on > par with Racket's macro and type system, but who knows? > > On Friday, July 24, 2020 at 8:46:55 PM UTC+2, wanp...@gmail.com wrote: >> >> Faster load time and less memory consumption. > > -- 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/05101884-fee5-4f26-aa1d-88b3269907a6o%40googlegroups.com.
[racket-users] Re: “If you could have a wish granted, what would you like to see next in Racket?”
A more powerful Typed Racket: covering more of Racket (e.g. generics) and with type classes, as in Haskell. >From what I've seen though, work is underway in this direction, and I also plan to contribute once my Racket-fu is up to snuff. - Sergiu On Thursday, July 23, 2020 at 2:30:33 PM UTC+2, Stephen De Gabrielle wrote: > > “If you could have a wish granted, what would you like to see next in > Racket?” > > > https://www.reddit.com/r/Racket/comments/hwe49b/if_you_could_have_a_wish_granted_what_would_you/?utm_source=share&utm_medium=ios_app&utm_name=iossmf > > or [original twitter]( > https://twitter.com/racketlang/status/1286020900660404232?s=20) > -- > > -- 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/a5e645a9-23ca-4d98-989b-a3b8e4591e41o%40googlegroups.com.
[racket-users] raco setup --fix-pkg-deps needs --avoid-main on NixOS
Hi Racket+NixOS-heads out there, I was trying to use `raco setup --fix-pkg-deps` to get the dependencies of my package automatically fixed, but it would fail with a lot of "cannot delete file" errors. That's because `raco setup --fix-pkg-deps` looks at all packages, including the system-wide ones, which are immutable on NixOS (or under Nix, more generally). It is actually easy to prevent `raco setup` from messing with the immutable parts of the installation by running it with the additional flag `--avoid-main`, like this: `$ raco setup --fix-pkg-deps --avoid-main` Easy when you know where to look :-) On a side note, I am a little bit surprised that `raco setup --fix-pkg-deps` does nothing to user-specific packages when it fails on the system-wide ones. I'd expect it to fail gracefully and operate on those sets of packages to which it has the rights. But hey, having an explicit command line switch to control that behaviour is still fine by me. - 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/5aa7f73f-a63c-4f6c-a780-8592d6869a48%40googlegroups.com.
[racket-users] Re: Rhombus project plan
Hello everyone and thank you for this very interesting discussion! I'd like to share my opinion on parenthesized prefix syntax: I actually switched to Racket/Lisp because of it! This highly uniform structure best fits the shape of mind as of today. Now, I explicitly don't pretend to be representative. Consider me to be the voice of those folks out there who are actually fond of parenthesis. - Sergiu On Monday, April 27, 2020 at 7:25:09 PM UTC+2, Anurag Mendhekar wrote: > > First of all, Thank you to the team for making such a fantastic system > available for the rest of us. I don't know what I'd have done without it. > As a very long time Schemer/Racketeer/Lisper and a consistent industry > practitioner (I have used Chez Scheme and Racket as critical parts of every > one of my companies in the past 20 years). > > It is somewhat unclear to me from reading this proposal what the expected > outcomes of this project are, or ought to be (in terms of making a real > change in the language ecosystem). But, if one of the outcomes is to gain > widespread adoption, my first thoughts upon reading this proposal are as > follows. > > 1. The obsession with parentheses/syntax is misplaced. My analysis of the > psychology of parentheses that it is a redirection of frustration with > functional-style programming. Let's acknowledge the fact that functional > programming is a difficult paradigm for the average CS graduate and they > generally skew imperative (it's probably rooted in human psychology, since > that is how our systems are organized: around change of state). In any > case, the frustration in dealing with it is directed towards syntax in the > case of Racket. Other functional languages with conventional syntax suffer > the same outcome: lack of widespread adoption because of perceived > "annoyances". While I would welcome the ability to more easily add new > (possibly infix) notation into my own syntactic extensions, spending too > much time designing a new "better" syntax for racket is not going to reduce > the adoption barrier. So, I would rather own it than defend it. > > 2. Adoption will be widespread once the language and its accompanying > platform can stake out a claim for itself in terms of what can be built > with it. > > I can't speak to the other aspects of internal design that this post talks > about but here is what I believe we need in the industry to convince my new > crop of engineers to start adopting Racket at a larger scale. In some ways, > I'm looking at it as a "sell" job, and here are the things I know I can > sell. This is not so much about language design as much as it is about the > Platform itself, although I'm sure Racketeers can do a far better job of > bringing in elements of language design into this. Of course, the community > needs to work towards doing this along with the Racket team, but as a > community, we should set an agenda and work towards it. The Rhombus > discussion provides an opportunity for this. So here are my two cents. > > A) Performance. As a point of comparison, the JVM has gotten amazingly > good over the past couple of decades, but Java continues to be derided as a > terrible language with much lower productivity. Given how productive one > can be in Racket, combining that with comparable performance will make it > an easy sell. This has largely been Go's and Rust's strategy. C++ level > performance with high productivity. For this day and age, this would have > to include GPU support (kind of like openCL). > B) Web First. The current the built-in web framework is not enough. The > language must support end-to-end development of asynchronous > web-applications, and it must be trivial to tack on web front-ends to > anything. This is the Node/JS and Ruby/Rails strategy. Racket has some > elements of this, but building a web-app in racket is still a lot of work. > With web-assembly on the horizon, Racket can very easily be a front-end > language as well as a back-end language. > C) Mobile First (ok, Second :-). The language must provide inherent > support for building mobile front-ends (both android and IoS). This is the > Swift/XCode strategy. > D) AI Support. AI is clearly the next wave of software and people are > going to be building AI into their systems for decades to come. In this > instance, Lisp's AI legacy might actually be of help, if we can make it > very easy to develop AI applications. While Python seems to be the > preferred language right now, I don't believe it will last too long. AI > programming in Python is at best a puke-worthy experience. > E) Cloud Ready out of the box - Simple deployment using docker, AWS Lambda > and the like; built-in support for directly working with cloud resources > (buckets, ACL's, Logs, etc.) > F) Broad IDE support. Rather than focus on Emacs/Dr. Racket, I believe > Racket should take the approach of integrating with all the different > IDE's. (
Re: [racket-users] Typed Racket: Generics and interfaces/subtyping
Hi Sam, Thank you for your answer! I'll try to hang around on Slack next week (starting tomorrow). Contributing to Typed Racket would be very exciting to me! - Sergiu On Saturday, April 25, 2020 at 9:55:30 PM UTC+2, Sam Tobin-Hochstadt wrote: > > Structure type properties are getting better support incrementally > thanks to Fred Fu, and that sentence needs to be revised. However, > there's been no work yet on generic interfaces. I'm happy to chat > about the issues there, but it's not simply a matter of doing some > programming -- there are a lot of hard design questions. Feel free to > ping me on Slack to discuss further. > > Sam > > On Sat, Apr 25, 2020 at 12:10 PM unlimitedscolobb > > wrote: > > > > Hello, > > > > The Typed Racket Guide states "Most structure type properties do not > work in Typed Racket, including support for generic interfaces." [0] Is > that due to some incompatibility between the design of Typed Racket and > structure type properties, or is it because somebody should just get around > and implement these? I'm particularly interested in generics right now. > > > > How would you go about expressing something like an abstract interface > in Typed Racket? Something similar to the collections library, possibly > even less featureful. Should I be looking at class inheritance? > > > > As a lot of people here, I don't have very much time spare time, but I > would be happy to extend Typed Racket to handle more of the code I write. > > > > - > > Sergiu > > > > [0] > https://docs.racket-lang.org/ts-guide/caveats.html#%28part._.Unsupported_features%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...@googlegroups.com . > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/6e5f6bb0-4768-4f4d-86b0-0c0c08f64171%40googlegroups.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/0a4d8713-7414-4f62-976d-55c0dee400be%40googlegroups.com.
[racket-users] Typed Racket: Generics and interfaces/subtyping
Hello, The Typed Racket Guide states "Most structure type properties do not work in Typed Racket, including support for generic interfaces." [0] Is that due to some incompatibility between the design of Typed Racket and structure type properties, or is it because somebody should just get around and implement these? I'm particularly interested in generics right now. How would you go about expressing something like an abstract interface in Typed Racket? Something similar to the collections library, possibly even less featureful. Should I be looking at class inheritance? As a lot of people here, I don't have very much time spare time, but I would be happy to extend Typed Racket to handle more of the code I write. - Sergiu [0] https://docs.racket-lang.org/ts-guide/caveats.html#%28part._.Unsupported_features%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/6e5f6bb0-4768-4f4d-86b0-0c0c08f64171%40googlegroups.com.
[racket-users] Re: Puzzler - A Language for Puzzle Games
Hi Alex, Sounds really interesting! I'm not into puzzle games myself, but I have some friends who could definitely be excited. I shared it on the Fediverse: https://bidule.menf.in/notice/9uKmWBX2f0i52XqwF6 - Sergiu On Thursday, April 23, 2020 at 12:51:41 AM UTC+2, Alex Owens wrote: > > Hello everyone! > > My name is Alex Owens and I've been a lurker on this mailing list - and in > the Racket community in general - for a while. While I'm still relatively > new to Racket, I wanted to share a project I worked on called Puzzler. > > Puzzler is a DSL to enable easy creation of 2D grid-based puzzle games. It > features a very concise and readable syntax for representing puzzle games > through a small collection of built-in constructs like win/lose conditions > and entity interactions. Most of the actual work for Puzzler was done about > a year ago at the end of my undergrad, and while I'm not planning any big > new features soon, I have recently been cleaning up the implementation and > adding documentation. > > Mostly I hope that if you're interested in language-oriented programming > for game development you will check it out. It is a small language, but > even if it doesn't suit all of your needs you may find it a useful > reference project for what a language for puzzle game development might > look like! If you do decide to use Puzzler and you find any bugs or > functionality you think is missing, feel free to submit an issue (or better > yet a pull request) on my GitHub. I can't promise I'll fix things > immediately, but I will try my best to respond in a timely fashion - I'm > always up to learn more Racket. Of course, you are also free to clone/fork > it and build onto it however you see fit. > > Puzzler on the package catalog: > https://pkgs.racket-lang.org/package/puzzler > Source code: https://github.com/aowens-21/puzzler > > Stay safe and healthy, and I look forward to getting to know you all and > being more active here in the future! > > - Alex > -- 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/25b9bb76-0bb6-41be-b026-33c2f644a53c%40googlegroups.com.
Re: [racket-users] NixOS: (help map) does not find documentation
On Thursday, April 16, 2020 at 7:48:35 PM UTC+2, asumu wrote: > > On 2020-04-16 05:19:26 -0700, unlimitedscolobb wrote: > >I started a discussion on NixOS Discourse here: > > > https://discourse.nixos.org/t/racket-does-not-find-documentation-after-update/ > > >Would you mind submitting a PR from your `racket-enable-useprefix` > branch? > >If you don't have time, I can handle that as well, but it's probably > best > >that it comes from you. > > No problem, and thanks for testing it! I submitted a PR here: > > https://github.com/NixOS/nixpkgs/pull/85385 > > Cool, thank you! I made some noise on the PR and on the corresponding thread on Discourse, let's hope your change gets merged soon. - Sergiu Cheers, > Asumu > -- 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/d78e3bf1-749a-4d63-8484-62f46341e0ac%40googlegroups.com.
Re: [racket-users] NixOS: (help map) does not find documentation
Hi Asumu and great thanks for your answer! On Thursday, April 16, 2020 at 12:42:46 AM UTC+2, asumu wrote: > > On 2020-04-14 15:53:09 -0700, unlimitedscolobb wrote: > >Turns out this file does not even exist on my machine, but > > > /nix/store/za0k7s00bg3v5sasyqalv12ii7pxjbjn-racket-7.6/share/doc/index.html > > >does! (mind the added share/) > > > >I'm running Racket 7.6 and I am on nixos-unstable channel. > > > >Does any one of you have similar symptoms? > > I suspect this is because of a packaging bug in Racket that changes > where things get installed: > > https://github.com/racket/racket/issues/3046 > > You should be able to work around this by adjusting the configure flags > for the Racket Nix package. Here's a commit for nixpkgs that should do > that: > > > https://github.com/takikawa/nixpkgs/commit/b766b42f0a2f79f19f9e73f46264f91ba6cb3bdd > > > When I built this locally, `(help map)` and such seemed to work for me. > That's excellent, thank you very much! I'll test that locally in a moment. > If someone can land a fix for #3046 for Racket 7.7, that'd be really > great. This bug also affects the packaging for Debian, Ubuntu PPA (these > shipped with the workaround) and probably other distros too. > > I started a discussion on NixOS Discourse here: https://discourse.nixos.org/t/racket-does-not-find-documentation-after-update/ Would you mind submitting a PR from your `racket-enable-useprefix` branch? If you don't have time, I can handle that as well, but it's probably best that it comes from you. - Sergiu Cheers, > Asumu > -- 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/7caff889-1321-443e-94d3-b20e59037e96%40googlegroups.com.
[racket-users] NixOS: (help map) does not find documentation
Hello, I noticed the following behaviour today: > (require racket/help) > (help map) Loading help index... ; help: no documentation found for: map provided by: "/nix/store/za0k7s00bg3v5sasyqalv12ii7pxjbjn-racket-7.6/collects/racket/base.rkt" ; Context: ; /nix/store/za0k7s00bg3v5sasyqalv12ii7pxjbjn-racket-7.6/collects/racket/repl.rkt:11:26 Also, weirdly: ``` my-test.rkt> (help) Sending to web browser... file: /nix/store/za0k7s00bg3v5sasyqalv12ii7pxjbjn-racket-7.6/doc/index.html ``` Turns out this file does not even exist on my machine, but /nix/store/za0k7s00bg3v5sasyqalv12ii7pxjbjn-racket-7.6/share/doc/index.html does! (mind the added share/) I'm running Racket 7.6 and I am on nixos-unstable channel. Does any one of you have similar symptoms? For the reference, I ran into this problem with Greg Hendershott's help: https://github.com/greghendershott/racket-mode/issues/446 - 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/9117210c-3278-4ce0-84c0-98f1851d2b62%40googlegroups.com.
Re: [racket-users] Gradual Typed Racket?
On Monday, March 23, 2020 at 9:59:22 PM UTC+1, Hendrik Boom wrote: > > On Mon, Mar 23, 2020 at 12:16:45PM -0400, Ben Greenman wrote: > > > > > Not sure about best practices, but I definitely prefer keeping typed > > and untyped code in separate modules. > > It can be veru useful to be able to mix them while in transition from one > to the other. > > -- hendrik > Absolutely! In my case I am writing code from scratch for my research (theoretical computer science), but I end up wanting to write some stuff which Typed Racket cannot type (converting to a polymorphic type variable, for example), or even stuff which is difficult to type without writing long dependent types. For these cases, I'd prefer to just drop the types "temporarily", which the different modules approach should probably allow me to do. - 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/9bce12f3-fbba-4dec-b849-235ef573602c%40googlegroups.com.
Re: [racket-users] Gradual Typed Racket?
Hi Ben, Thank you for your answer! I'll give (sub)modules a try. The examples from the plot library are very helpful, I'll peruse them attentively. I didn't realise that (provide (contract-out)) gave better error messages than define/contract. I'm glad to have chosen to use (provide (contract-out)) in my code. - Sergiu On Monday, March 23, 2020 at 5:16:52 PM UTC+1, Ben Greenman wrote: > > On 3/21/20, unlimitedscolobb > wrote: > > Hello, > > > > I come to Racket from Haskell and so far I am quite happy, as I feel > freer > > to do some weird stuff from time to time, and I am absolutely in love > with > > the Lisp-parens syntax. > > > > As a former Haskeller, one of the first things I tried was Typed Racket. > > It worked like a charm for small examples, but started getting in my way > > too much as soon as I got to some more advanced stuff (e.g. polymorphic > > functions, generics, eval, even apply). My immediate reaction was > ditching > > types for contracts, which are rather fine and allow me to use a > familiar > > language, but I am somewhat worried about the performance penalties > > defining everything via define/contract may incur. Also, it seems weird > to > > set up runtime contract checks where a simple type annotation would do. > > I have no problem with Typed Racket not being able to type every single > one > > of my functions (after all, I came to Racket to be able to do weird > stuff), > > but so far I couldn't figure out what would be the best way to mix typed > > into two separate files. > > > > What is the standard practice for mixing typed and untyped code within a > > single module? Submodules? Typed regions within untyped code? Maybe > > there is an example somewhere I can have a look at? > > Yep, submodules and typed regions are the two ways to do this. > > The plot library uses typed submodules in untyped code in a few small > places: > > > https://github.com/racket/plot/blob/master/plot-lib/plot/private/common/contract.rkt > > > https://github.com/racket/plot/blob/master/plot-lib/plot/private/common/parameter-groups.rkt > > > I've done a similar thing to make typed parameters in untyped code. > > Not sure about best practices, but I definitely prefer keeping typed > and untyped code in separate modules. > > For contracts, though, (provide (contract-out ...)) gives better error > messages than define/contract. > -- 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/1aa90aad-c951-43a1-be7e-24df02ec5c67%40googlegroups.com.
[racket-users] Gradual Typed Racket?
Hello, I come to Racket from Haskell and so far I am quite happy, as I feel freer to do some weird stuff from time to time, and I am absolutely in love with the Lisp-parens syntax. As a former Haskeller, one of the first things I tried was Typed Racket. It worked like a charm for small examples, but started getting in my way too much as soon as I got to some more advanced stuff (e.g. polymorphic functions, generics, eval, even apply). My immediate reaction was ditching types for contracts, which are rather fine and allow me to use a familiar language, but I am somewhat worried about the performance penalties defining everything via define/contract may incur. Also, it seems weird to set up runtime contract checks where a simple type annotation would do. I have no problem with Typed Racket not being able to type every single one of my functions (after all, I came to Racket to be able to do weird stuff), but so far I couldn't figure out what would be the best way to mix typed and untyped code inside a single module, ideally without having to split it into two separate files. What is the standard practice for mixing typed and untyped code within a single module? Submodules? Typed regions within untyped code? Maybe there is an example somewhere I can have a look at? - 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/2b1c49ad-2076-47f7-8589-d20eff9feca1%40googlegroups.com.
Re: [racket-users] Racket Generic Graph Library: non-numerical edge weight/labels + Graphviz?
Thank you very much for your answer Stephen! I'll be busy the whole day tomorrow, but I'll come back in the evening most probably and will continue the discussion on the GitHub issue. Indeed, I haven't seen the constructors actually check the edges to be numerical, but I had the impression that edge-weight had number? as the output contract: https://docs.racket-lang.org/graph/index.html#%28def._%28%28lib._graph%2Fmain..rkt%29._edge-weight%29%29 You are right: allowing non-numerical edges should be a matter of replacing a couple ='s with equal? and maybe generalising a contract or two. I'll also give you an example in the discussion on the GitHub issue, in about 24 hours. - Sergiu On Monday, February 24, 2020 at 4:54:55 PM UTC+1, Stephen Chang wrote: > > > I am somewhat surprised that the graph library enforces numerical edge > weights at all. > > The docs do informally say number weights but I don't think the > constructors do any checking? Any enforcement should be deferred to > individual algorithms. > > Re: graphviz, I took a quick look and I think we could get the > behavior you want with a 1-line modification here, changing = to > equal? > > https://github.com/stchang/graph/blob/master/graph-lib/graph/graph-fns-graphviz.rkt#L59-L60 > > > Do you have an example I can work with? > > I opened an issue so feel free to reply there instead: > https://github.com/stchang/graph/issues/53 > > On Sun, Feb 23, 2020 at 8:45 AM unlimitedscolobb > > wrote: > > > > Hello, > > > > I'm using the wonderful graph library which can do tons of various > graph-related tasks. However, I haven't found a way to attach > non-numerical weights/labels to edges _and_ have them appear in the > Graphviz rendering of the graph. > > > > Is it at all possible? > > > > I did see define-edge-property, but properties defined in this way do > not appear in the Graphviz output. I was looking for ways of passing edge > properties to the graphviz function of the library, but there don't seem to > be any. > > > > I am planning to do a pull request enhancing the graphviz function with > the possibility to include edge properties, but I wanted to ask around for > some solutions which may already exist. > > > > > > - > > 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...@googlegroups.com . > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/e4cb44fd-0a21-4e91-a75c-f1442127bfa9%40googlegroups.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/955e7962-ee85-4548-a779-ba903b514d49%40googlegroups.com.
[racket-users] Racket Generic Graph Library: non-numerical edge weight/labels + Graphviz?
Hello, I'm using the wonderful graph library which can do tons of various graph-related tasks. However, I haven't found a way to attach non-numerical weights/labels to edges _and_ have them appear in the Graphviz rendering of the graph. Is it at all possible? I did see define-edge-property, but properties defined in this way do not appear in the Graphviz output. I was looking for ways of passing edge properties to the graphviz function of the library, but there don't seem to be any. I am planning to do a pull request enhancing the graphviz function with the possibility to include edge properties, but I wanted to ask around for some solutions which may already exist. On a different note, I am somewhat surprised that the graph library enforces numerical edge weights at all. I understand that some algorithms don't work if edges are not numbers, but on the other hand they could just fail gracefully on non-numerical edges. Anyway, my best solution as of now would be extending graphviz, as this update would require modifying less code. - 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/e4cb44fd-0a21-4e91-a75c-f1442127bfa9%40googlegroups.com.
Re: [racket-users] Typed Racket: Casting to types containing type variables
Hi Ben, Thank you for your answer. On Thursday, February 20, 2020 at 3:29:15 AM UTC+1, Ben Greenman wrote: > > On 2/19/20, unlimitedscolobb > wrote: > > > > [] > > > > ;Type Checker: Type a could not be converted to a contract because it > > contains free variables. > > ; in: a > > > > Does this mean that I can never cast to types containing type variables? > > Yes > Ah, okay, got it. > > My original problem comes from playing around with eval, which returns > > AnyValues. Ideally, I would like to be able to retrieve the first > returned > > > > value (done), and then convert it to a type variable bound by one of the > > arguments: > > > > (: my-super-func (All (a) (-> (Type1 a) a))) > > (define (my-super-func arg) > > ... > > (get-first-value (eval some-stuff))) ; how to cast to a ? > > You can ask the caller to supply a cast function that turns an Any to an > A. > Ahaa, that's a clever idea! But depending on what you want to cast to, occurrence typing may be > more convenient. For example: > > #lang typed/racket > > (: my-super-func (All (a) (-> (-> Any) (-> Any Boolean : #:+ a) a))) > (define (my-super-func get-v check-v) > (assert (get-v) check-v)) > > (ann (my-super-func (lambda () 42) exact-integer?) Integer); > ;; 42 > (ann (my-super-func (lambda () '(A)) (lambda (x) (and (list? x) > (andmap symbol? x (Listof Symbol)) > ;; '(A) > This does look quite a bit like lifting contracts to types, very nice. Thank you very much for clarifying and giving a detailed example. I'm coming over from Haskell, so I'm still in process of wrapping my head around types and contracts in Racket. - 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/3fdb2744-fd5b-4668-9da0-ab853fa0efaa%40googlegroups.com.
[racket-users] Typed Racket: Casting to types containing type variables
Hello, I'm trying to get something similar to the following code working: #lang typed/racket (: f (-> Integer Any)) (define (f x) (+ 1 x)) (: g (All (a) (-> Integer a))) (define (g x) (f x)) Of course, this gets me a type error: ;Type Checker: type mismatch ; expected: a ; given: Any ; in: (f x) Now, I try to throw a cast into g: (: g (All (a) (-> Integer a))) (define (g x) (cast (f x) a)) This gives the following type error: ;Type Checker: Type a could not be converted to a contract because it contains free variables. ; in: a Does this mean that I can never cast to types containing type variables? My original problem comes from playing around with eval, which returns AnyValues. Ideally, I would like to be able to retrieve the first returned value (done), and then convert it to a type variable bound by one of the arguments: (: my-super-func (All (a) (-> (Type1 a) a))) (define (my-super-func arg) ... (get-first-value (eval some-stuff))) ; how to cast to a ? - 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/d8f098d0-5427-4871-9b6b-b2f65635048b%40googlegroups.com.
