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].

However I signaled the "at runtime" approach that would have a different 
semantic, eqv to:
   pr = proc {|p| if (a=p.unshift) then eval (b=p.unshift) else puts 
(c=p.unshift) end }.

I feel like the "compile time" approach (using (v=p[x])) is less 
surprising, specially for small code fragments. Yet the "runtime approach" 
(using (v=p.unshift)) is valuable too, specially for long code fragments. 
Some proc { if |a| then |b| then |c| end } is an example where the "run 
time" approach gives a surprising result whereas the "compile time" 
approach behave as if proc was { |a,b,c| if a then b else c }.

One benefit of the "compile time" approach is that it can be optimized back 
into proc { |a,b,c| xxx } whereas the "run time" approach can not.

>The door is open for anyone wanting to give a non-horrible example :-)
>But generally I think the { if |a| ... } notion doesn't hold up very
>well in the face of the "Any Time!" principle. David.

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 ?

Yours,

Jean-Hugues

-------------------------------------------------------------------------
Web:  http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17