On Thu, Dec 1, 2016 at 10:18 PM, Alexis King <[email protected]> wrote:
> > On Dec 1, 2016, at 21:43, David Storrs <[email protected]> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
