I don't know why but at some point in the 20th century people really
became afraid of viewing programs as pure data (which they are) and
started to call it metacircular (which of course also refers to other
properties of a list processor treating each and every start of list,
i.e. opening parenthese, as an apply instruction).
One the one hand I reject any security concerns about /eval /which is as
good or bad as input data as are the key codes from your favorite event
handling loop determining your programs actions. A simple /(send object
message arguments)/ could be implemented by evaluating /message/ in the
environment of /object/, i.e. applying it to the /arguments/. The use of
/eval/ shouldn't be restricted to proclaimed designers of algorithmic
notations but using it correctly needs some understanding of Scheme and
its specifications. That necessary knowledge used to be conveyed in a
lecture of one semester at the MIT with SICP (I've read).
But then /eval/ would need behave as expected and respect its current
environment aka lexical scope. Maybe Racket does this right but a lot of
Scheme implementation show their true nature when it comes to /eval/ and
lexical scope: they revert back to Lisp mode and evaluate the forms in
the top level environment. This unexpected behavior might explain why
some people still feel uncomfortable with /eval./
As a matter of style one should use /eval/ where it means what it is
good for: evaluating (sub) programs. Contrary to some advertisement
material /eval/ doesn't really support sand boxing as it is only
possible to restrict the name space of the evaluation but not the
computing resources needed. Maybe you want to read in that SGML data as
s-expression and evaluate it in the HTML environment - but maybe it
would be better to traverse the data graph with your own algorithms ...
On 03/08/2015 13:32, Josh Grams wrote:
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.
