Hello --

On Sun, 28 Apr 2002, Jean-Hugues ROBERT wrote:

> Hello,
>
> about "proc { if |a| then |b| else |c| end }, what does that means ?"
> At 11:36 27/04/2002 +0900, David wrote:
> >I'd refer you to the passage headed "Compile Time? Runtime? Any Time!"
> >in the pickaxe book:
> >
> >   The important thing to remember about Ruby is that there isn't a big
> >   difference between ``compile time'' and ``runtime.'' It's all the
> >   same. You can add code to a running process. You can redefine
> >   methods on the fly, change their scope from public to private, and
> >   so on. You can even alter basic types, such as Class and Object.
>
> This is for sure one of the feature of the language that I like most. Yet
> some things happen at "compile time" and others at "run time". In language
> design there is often a tradeoff to make between flexibility and speed. I
> like the tradeoff (i.e. the choices) of Ruby. More flexible languages
> exist. Faster languages too. The decision of going "compile time xor run
> time" is a decision to think about whenever a feature of the language is
> involved and this is a the case about the "block spread parameter passing
> feature" that was proposed.
>
> >Consider this (which I know can be attacked as an example because it
> >uses the ever-controversial eval, among other things, but anyway):
> >
> >   pr = proc { |a,b,c| if a then eval c else puts b.succ end }
> >   pr.call(rand(2)>0,"hi","puts b")
>
> The proposal (which I like a lot) was about rewriting this this way:
>    pr = proc { if |a| then eval |b| else puts |c|.succ end }
>
> whose semantic would almost be equivalent to:
>    pr = proc {|p| if (a=p[0]) then eval (b=p[1]) else puts (c=p[2]) end}
>
> ...if, "at compile time", the compiler collects the various |xxx| fragments
> in order to build the proper x in p[x].

It's actually p[2] that's getting eval'd, so I think it would be more
like:

   proc {|p| if (a=p[0]) then eval (c=p[2]) else puts (b=p[1]).succ end}

But it's still different from my example.  In my example (due to
horrible name coupling), the string being eval'd made reference to one
of the other variables.  When you eval p[2], it needs "b" to have been
assigned p[1].  So it depends on *all* the assignments always being
made.

[...]

> I have no desire to threaten the "Any Time!" principle. Fact is, I don't
> think the proposal does any threat. I am obviously missing something here.
> What are the "bad" consequences that you foresee regarding the proposal ?

I have to confess that to me it just doesn't look or feel like Ruby.
I know that's very vague... that's why I was trying to come up with a
case illustrating the importance (or at least Ruby-ness) of all the
assignments being made, independent of any branching within the code
of the block.


David

-- 
David Alan Black
home: dblack / candle.superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav