On Tuesday 25 November 2003 02:27 pm, David A. Black wrote: Blah.

You're a real whirlwind of positive attitude.

I won't even bother respoding to this. You'd think the world just came to an 
end becuase I suggested that, just maybe, eval could extend its horizons a 
little.

And at least on this list, a few people ARE interested enough to talk about 
it.

> On Tue, 25 Nov 2003, T. Onoma wrote:
> > On Monday 24 November 2003 06:40 pm, Sean E Russell wrote:
> > > On Monday 24 November 2003 11:51, T. Onoma wrote:
> > > > In such a simple case, of course. But consider:
> > > >
> > > >   a=[1,2,3]
> > > >   eval "def z; p a; end;  z"
> > >
> > > But... this doesn't work in Ruby anyway.  'a' isn't in scope inside the
> > > method.  Cut, paste, and run:
> > >
> > > 	a = [1,2,3]
> > > 	def z
> > > 		p a
> > > 	end
> > > 	z
> > >
> > > Why should method definitions in evals behave any differently?
> >
> > What's the point of having eval, then? Look at your example. By your
> > argument there's no point in eval at all. Would you say the same thing
> > about:
>
> No, by Sean's argument there is no point having eval do some kind of
> bizarre magical treatment, before it's even executed, of local
> variables inside a scope that doesn't exist yet.
>
> >   a = [1,2,3]
> >   eval %Q{
> >     def z
> >       p "#{a}"
> >     end
> >     z
> >   }
> >
> > Should that be 'wrong' b/c "this doesn't work in Ruby anyway. 'a' isn't
> > in scope inside the method."
> >
> > No. Eval is for constructing code piecemeal with various variables, not
> > just to do what can already be done without it. But as it stands, one
> > must build literals within strings to accomplish such things. That's a
> > lot of extra work and makes for choppy ugly code.
>
> eval is not for constructing code piecemeal with various variables.
> eval is for evaluating strings as code at runtime.  If you wish to use
> that facility for the purpose of constructing code piecemeal with
> various variables, you may do so.  But if a facility that evaluates
> strings as code at runtime does not help you construct code piecemeal
> with various variables, then you need to find another way to do it or
> reconsider what you're doing.
>
> eval is rather simple, and provides a functionality that exists in
> many languages.  The first thing that happens is that a string gets
> created.  Then it gets evaluated as code.
>
> In your example, the string that gets created is:
>
>    def z
>      p [1,2,3]
>    end
>    z
>
> Then it gets evaluated as code.  The string does not, cannot, and must
> not communicate some non-existent knowledge of the future scope of
> what will be created once it's eval'd to eval.
>
> You can't solve every programming issue by introducing a new feature
> to the language, coming up with new (but usually already in-use)
> syntax, or redefining concepts like runtime string evaluation to fit
> one or two particular cases for which it isn't the right answer in the
> first place.
>
> > Of course, the above example dosen't really do what I want it to. For
> > that, I have to get fancy:
> >
> >   p "#{a.join(',')}"
> >
> > I don't like getting fancy.
>
> I don't either, which is why I don't think it's good to resort right
> out of the starting gate to syntax and core language changes.  New
> syntax and rules is not always the answer.
>
> Speaking of "core language", I'm not sure what this is doing on this
> list.  It belongs on ruby-talk, or perhaps on a wiki somewhere.
> So....  <http://www.rubygarden.org/ruby?EvalAndScope>.  I honestly
> think that's a better place for wide-ranging, open-ended, speculative
> discussions of the nature of string evaluation and so on.
>
>
> David