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
