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