From: Stefan Kaes Date: 2005-03-16T17:47:36+09:00 Subject: Re: eval/binding question --------------070406000007040004030302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert Klemme wrote: >"Stefan Kaes" schrieb im Newsbeitrag >news:4237CBC1.9070209@gmx.net... > > >>Yukihiro Matsumoto wrote: >> >> >> >>>Hi, >>> >>>In message "Re: eval/binding question" >>> on Wed, 16 Mar 2005 02:45:41 +0900, Stefan Kaes >>> >>> >writes: > > >>>|In the real environment, the names of the locally assigned variables >>> >>> >can > > >>>|not be determined in advance, of course. >>> >>>I'm sorry to say you can't pre-compile eRB allowing local variable set >>>not determined in advance. I know allowing this will make your >>>program 25% faster, but this also would make any other programs >>>slower. >>> >>> >>> >>> >>I fail to see why it would make other code slower. I am convinced with a >>proper compiler implementation there would'nt be any speed difference >>for local variables introduced via explicit assignment. Access to >>predeclared variables would use an optimized access method, whereas >>access to variable names whose declaration point cannot be determined by >>statical program analysis would use a less efficient access method. >> >> > >I wonder in which cases this would be useful. This code is artificial, >since one would never write test2 like you did: > > def test2 > eval "x=25" > print "x=#{x}\n" > end > > > This code is artificial because I only wrote it to demonstrate the semantics of the current implementation. >If you write something similar but with a string coming from somewhere >else > > def test2(s) > eval s > print "x=#{x}\n" > end > >you know already that "s" must contain an assignment to "x". So it's not >a problem to predeclare it IMHO. > > For this simple demonstration program you are absolutely right: there is no reason to write it that way, other than to demonstrate current semantics. >I don't really see which real world problems would be solved with a more >complex lookup for locals, which would make the second variant succeed >without the explicit declaration of "x". > >Kind regards > > robert > The current semantics introduces an artificial barrier between code executed in *eval "code"* vs. just writing *code*, which makes the semantics more difficult to explain and understand. Ideally, these two forms should have identical semantics. As I have already explained, the complexity of variable access increases only for variables whose declaration point cannot be determined statically and therfore would not have a negative performance impact on most programs. The real world example can be found in Rails. It has a function render_partial, which takes an erb template name (tn), a value (v) and a name=>value hash (local_assigns). It makes the value v accessible as a local variable named "tn" and all name=>value pairs in local_assigns accessible by their name. This works, because the whole template source is evaluated using an eval, but requires reparsing of the erb-code each time the template gets interpreted. And, of course, the code that implements this function cannot know the names of the local varaiables in advance. As soon as one tries to abstract the erb code into a function the whole scheme breaks down, because there is no way to dynamically declare local variables. I solved this problem by resorting to instance variables. That is okay for me, I just rewrote my template code, but it breaks backwards compatibility. So this valuable optimisation cannot be included in Rails, unless everyone rewrites their templates. For this reason, I have not proposed it to the Rails community. regards, stefan --------------070406000007040004030302--