Sorry, couple typos: mapply = map and l = lst.
On Sat, Aug 9, 2014 at 10:10 AM, Sean Kanaley <skana...@gmail.com> wrote: > There's a simple enough example I think: apply with keyword parameters. > Apply has that built-in..sort of...but the list is supposed to be provided > inline to APPLY, seemingly requiring apply to be applied (e.g. (apply apply > (cons *thefunctiontoapply* params))), except keywords can't be expressions > anyway. I have a bunch of card definitions for Dominion with many defaults: > > (struct card (... actions buys ...)) > > (define (make-card ... #:actions actions #:buy buys ...) > ...) > > The non-keyword-requiring way is > > (define CARDS > (map (\ (lst) (apply make-card lst)) > '([... 1 1 ...] > [... 2 0 ...]))) > > The keyword way is > > ;ns is namespace > (mapply (\ (lst) (eval `(apply make-card ',(car l) ,@(cdr l)) ns)) > '([(...) #:actions 1 #:buys 1 ...])) > > Short of making a big macro to take some exact format and get it to work > with keywords and all that, eval seems to be just what is needed. > > > On Sat, Aug 9, 2014 at 8:27 AM, Neil Van Dyke <n...@neilvandyke.org> > wrote: > >> Sounds like a good rule of thumb. Two suggestions to add: >> >> * Maybe there could also be a second rule of thumb, like, "If you need >> arbitrary Racket expressions, then consider whether you can do it with one >> of the following patterns: [list some patterns involving combinations of >> syntax extension, custom #lang, dynamic requires, considering whether >> config files can actually be compile-time #lang, etc.]" This is less >> important than the first rule of thumb. >> >> * When we list typical newbie cases that don't actually require "eval", >> we can expect that newbie will immediately want an example of the >> non-"eval" way to do that typical thing. At the very least, an example >> showing, say, good use of hashes in parameters, with a sensible thin >> abstraction layer over it, for that case. These examples would be tedious >> to work through and write up well, but someday some knowledgeable and >> benevolent person will do it. (I am not this person. Book royalties >> aren't enough to ease the pain. I'd rather that newbies just never heard of >> "eval" or were scared away from it, rather than having to talk them down >> off the ledge all the time.) >> >> Neil V. >> >> >> Eli Barzilay wrote at 08/09/2014 07:31 AM: >> >> I think that I ran into a nice way to discourage eval except when >>> needed: the rule of thumb is to only use eval when you need to evaluate >>> any arbitrary (Racket) expression. It sounds simplistic but it covers >>> lots of cases that make newbies run to eval: >>> >>> * I just want to get the value of a variable whose name is held in x >>> >>> * More common: I have a symbol/string that names a function, I just need >>> to call that function >>> >>> * I need to keep an update-able mapping from names to values, just like >>> what the toplevel does >>> >>> * I want to let people write an arithmetic expression instead of a >>> number >>> >>> In such cases questions like "do you need allow calling all functions", >>> and "do you need to handle lambda expressions" have negative answers. >>> >>> >>> >>> On Sun, Jul 27, 2014 at 4:16 PM, Neil Van Dyke <n...@neilvandyke.org> >>> wrote: >>> >>>> Maybe there should be a periodic public service announcement about not >>>> using >>>> "eval". This time I will communicate in FAQ format: >>>> >>>> Q: How do I use eval? >>>> A: Don't use eval. >>>> >>>> Q: But don't so many academic books feature eval prominently, so doesn't >>>> that mean I should use try to eval? >>>> A: Those books use eval for pedagogic reasons, or because the author is >>>> enamored of some theoretical appeal of eval, or because the author >>>> wants to >>>> watch the world burn. Don't use eval. >>>> >>>> Q: But, but, but, I am just starting to learn, and eval seems to do >>>> what I >>>> need. >>>> A: Eval is almost certainly not what you want. Learn how to use the >>>> other >>>> basics effectively. Don't use eval. >>>> >>>> Q: I now am very comfortable with the language, I am aware that I should >>>> avoid eval in almost all cases, and I can tell you why eval is actually >>>> the >>>> right thing in this highly unusual case. >>>> A: Cool, that's why eval is there. >>>> >>>> Neil V. >>>> >>>> >>>> >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users >> > >
____________________ Racket Users list: http://lists.racket-lang.org/users
