On eval in dynamic languages generally and in Racket specifically <http://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html> Posted by Matthew Flatt http://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html
2015-08-03 13:32 GMT+02:00 Josh Grams <j...@qualdan.com>: > On 2015-08-03 01:22AM, Neil Van Dyke wrote: > > Eval might indeed be the perfect solution this time, iff every other > > conceivable alternative has been rejected. :) > > > > Shameless link to PSA on the topic of eval: > > http://lists.racket-lang.org/users/archive/2014-July/063597.html > > > > Suggestions for other forms for PSA are welcome: > > If people knew *why* and *how* to avoid eval, wouldn't they already be > doing it? To be useful to your target audience, I think you *need* to > back this up with a link to supporting documentation. I'd be looking > for: > > - A *brief* high-level statement of why eval causes problems: maybe > something like this? I'm sure there are better statements out there... > > "eval takes code which was constructed in one context and assigns > meaning to it in a different context. This can cause the code to have > an unexpected meaning, or fail to work altogether. It can also cause > security problems (if you pass it code from an untrusted source) or be > unnecessarily slow (evaluating code at runtime which could have been > fixed at compile time)." > > - Rules of thumb for how to decide what to use instead, and when eval > might be ok. This answer (http://stackoverflow.com/a/2571549/2426692) > suggests asking: > > - Do I really need eval or does the compiler/evaluator already do what > I want? > - Does the code really need to be constructed at runtime or can it be > constructed earlier? > - Will funcall, reduce, or apply work instead? > > - Concrete examples of where beginners tend to use eval and how to code > them without it. This is sort of the same as the previous one, but I > like to see a short overview of the whole strategy by itself, so I > would put the examples separately, e.g. HTDP has a *nice* clear > overview of the design recipe, whereas HTDP 2e has no place where you > can go for a quick refresher of "what were the steps of the design > recipe again?" > > ----- > > That's my two cents. I always see these sorts of things getting brushed > off as unhelpful or even patronizing, so I think you want to go out of > your way to make it easy to dig into it and reach successively deeper > levels of understanding. > > --Josh > > -- > 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. > -- -- Jens Axel Søgaard -- 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.
