From: Markus <markus@...>
Date: 2004-10-12T14:33:12+09:00
Subject: Re: 1.8.2 [WAS] Re: TempFile

On Mon, 2004-10-11 at 21:14, Ara.T.Howard@noaa.gov wrote:
> On Tue, 12 Oct 2004, Yukihiro Matsumoto wrote:
> 
> > Hi,
> >
> > In message "Re: 1.8.2 [WAS] Re: TempFile"
> >    on Tue, 12 Oct 2004 11:24:36 +0900, Ara.T.Howard@noaa.gov writes:
> >
> > |would you say it should be safe to move from 1.8.1 to 1.8.2 without extensive
> > |testing? meaning are there known incompatibilities, or only
> > |fixes/improvments/additions?
> >
> 
> > It should be, except for yield semantics, which I still need to examine.
> 
> can you expand (or provide reference for me to read)?

See my post:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/113663

and the threads surrounding it for some background.  This is not the
complete picture, but I have been unable to find english translations
for what went before.

     A very superficial summary:

      * There are several ways to get a list of values into a list of
        local variables.  You can use:
              * assignment:        
                        v1,v2... = e1,e2...
              * assignment with explosion: 
                        v1,v2... = *[e1,e2...]
              * assignment with implicit explosion: 
                        v1,v2... = [e1,e2...]
              * procedure calls: 
                        def p(v1,v2...)
                        ...
                        p(e1,e2...)
              * proc objects:
                        p=Proc.new{|v1,v2...|...};
                        ...
                        p.call(e1,e2...)
              * yield: 
                        def p;
                            ...
                            yield e1,e2
                         ...
                        p {|v1,v2...|...}
              * and so forth
                
      * It was noted (in the japanese thread, so I'm somewhat guessing
        here from the example code and the change that was made) that
        yield did not work like assignment, in that assignment
        implicitly explodes the first value if 
             1. it is an array, 
             2. there are multiple variables being assigned to
             3. there is only one value on the right
        whereas yield did not--it behaved like def, etc.
        
      * From this it was decided to change the semantics of proc objects
        to include this special case, with the added complexity that
        Proc objects created with proc {} did _not_ behave that way.

      * Several people (myself included) objected to this on the grounds
        that:
              * It quietly caused a number of very subtle problems;
                initially they were noticed in algorithms using the
                first/rest idiom, but they were spotted in several other
                fairly common situations once the problem was
                recognized.
                
              * It would be easy to explicitly explode a single argument
                if that was desired (simply use *) but it is impossible
                to "unexplode" if you do not want the feature (you have
                no way of knowing if this favour was done to you).
                
              * It does not remove the inconsistency, but merely moves
                it

      * My recommendation (and hope) is that the change will be removed
        for 1.8.2 final, restoring the 1.8.0 semantics, and that (if it
        is deemed important to remove the inconsistency) this be done by
        requiring an explicit '*' to explode arrays on assignment, since
        that would be easy to detect, report, and remedy.  

      * matz has not (so far as I know) reached a conclusion on the
        matter.

  -- Markus