On Thu, Dec 1, 2016 at 10:18 PM, Alexis King <lexi.lam...@gmail.com> wrote:
> > On Dec 1, 2016, at 21:43, David Storrs <david.sto...@gmail.com> wrote: > > > > The difference between a dictionary and a structure being that > dictionaries are easily extensible on the fly and structures are not? I'm > curious -- what are the elements of that design and what are the reasons? > It seems like a natural fit -- if Racket supported contracts on the values > of a contract then you would have the best of dictionaries and structures. > > The difference is that a structure has intrinsic meaning while a hash > with a particular collection of keys has extrinsic meaning.[...] Racket in > general heavily favors custom, tagged data over reusing > data structures Fair enough. I come from a Perl background and am used to a slightly more relaxed system, but I'll try to get used to the new way. > > > Hm. Well, that approach would work. It's not really what I'm looking > for, though -- this is data that's coming back from a SQL query and being > forwarded on to another function for further processing. It isn't needed > anywhere else, and creating a struct for this one use feels pretty clumsy > and heavyweight. "Hash of field-name-in-table to value-in-field" seemed > like a really intuitive solution. It's fine, though. I can just do a > manual check. > > If you are just handing off this data between two functions as an > implementation detail, do you need the contract at all? That is, what > value are you getting from it? Could the arguments be provided as > keyword arguments, instead? > That's a good thought. Yes, that will work. I had them as a hash because I used them in the source function and it was convenient to have them that way, so I figured I could just hand them off to the sub-function in the original hash form. Better to split it up though, I suppose. > That said, if you wanted a contract that does what you describe, it > wouldn’t be too difficult to write: > > (define (hash-object/c ctc-dict) > (make-contract > #:name `(hash-object/c > ,(for/list ([(k v) (in-dict ctc-dict)]) > (cons k (contract-name v)))) > #:projection > (λ (blame) > (λ (val) > (for ([(k v) (in-hash val)]) > (let ([ctc (dict-ref ctc-dict k #f)] > [blame (blame-add-context > blame (format "value for key ~e of" k))]) > (when ctc > (((contract-projection ctc) blame) v)))))))) > ...I think your definition of "not too hard" may differ from mine. :> > The existing hash contracts are mostly designed to accommodate > homogenous dictionaries, like (hash/c string? boolean?). I’m not > entirely sure what the intended use case of hash/dc is, and while I’m > sure I’d be very glad it exists if I ever needed it, I admit I’ve never > used it myself. It just allows you to provide a function that determines > the contract of a value given the key, but it still requires that all > keys have the same contract, and it does not let you specify which keys > should be supplied. > Okay, that makes more sense. Thanks for all the explanation. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
