[#5218] Ruby Book Eng tl, ch1 question — Jon Babcock <jon@...>

13 messages 2000/10/02

[#5404] Object.foo, setters and so on — "Hal E. Fulton" <hal9000@...>

OK, here is what I think I know.

14 messages 2000/10/11

[#5425] Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...>

18 messages 2000/10/11
[#5427] RE: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — OZAWA -Crouton- Sakuro <crouton@...> 2000/10/11

At Thu, 12 Oct 2000 03:49:46 +0900,

[#5429] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...> 2000/10/11

Thanks for the input.

[#5432] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Yasushi Shoji <yashi@...> 2000/10/11

At Thu, 12 Oct 2000 04:53:41 +0900,

[#5516] Re: Some newbye question — ts <decoux@...>

>>>>> "D" == Davide Marchignoli <marchign@di.unipi.it> writes:

80 messages 2000/10/13
[#5531] Re: Some newbye question — matz@... (Yukihiro Matsumoto) 2000/10/14

Hi,

[#5544] Re: Some newbye question — Davide Marchignoli <marchign@...> 2000/10/15

On Sat, 14 Oct 2000, Yukihiro Matsumoto wrote:

[#5576] Re: local variables (nested, in-block, parameters, etc.) — Dave Thomas <Dave@...> 2000/10/16

matz@zetabits.com (Yukihiro Matsumoto) writes:

[#5617] Re: local variables (nested, in-block, parameters, etc.) — "Brian F. Feldman" <green@...> 2000/10/16

Dave Thomas <Dave@thomases.com> wrote:

[#5705] Dynamic languages, SWOT ? — Hugh Sasse Staff Elec Eng <hgs@...>

There has been discussion on this list/group from time to time about

16 messages 2000/10/20
[#5712] Re: Dynamic languages, SWOT ? — Charles Hixson <charleshixsn@...> 2000/10/20

Hugh Sasse Staff Elec Eng wrote:

[#5882] [RFC] Towards a new synchronisation primitive — hipster <hipster@...4all.nl>

Hello fellow rubyists,

21 messages 2000/10/26

[ruby-talk:5396] Re: Allowing *ary's in the middle of a camma separated list

From: Aleksi Niemel<aleksi.niemela@...>
Date: 2000-10-10 18:59:59 UTC
List: ruby-talk #5396
Guy tells:

>  I've tried this but it don't work :-)
>  try a 'make test' and normally you've some errors

That's true. On this case I'd like to make somewhat more extensive testing
as it's parsing which changes, so there are new features to use the
language, and something new which shouldn't work.

Anyway, as I said I don't have a machine blessed with a compiler at hand to
test out. I left testing to be an exercise for the readers. The second step
on that exercise is to find out why it doesn't work, and the third is to
make it work, and publish a real patch. :)

It was actually just an idea disguised to look like a patch B-]. 

What it comes to Akinori Musha's original idea, I agree for the right hand
side expressions. I feel the left hand side issues are more convoluted, and
wouldn't go for them immediately.

> I also think it's nice to accept it even in an L-value like this:
>   rev = "1.1.2.2"
>   *first, last = rev.split '.'

This particular case is quite nice and useful. And probably the forms like

  lhs_first_term, second, *the_list_grabbing_whats_left, 
    second_last, last = ary

are useful too. After the first and the second elements from ary have been
shifted, and the next to last and the last popped, the rest what's left will
be assigned to the *list.

The Perlish semantics for starred mlhs would be

  *grab_everything, free_initialize, to_nil = ary

And example of that:

  my (@everything, $free_initialization) = (1,2,3);
  print(join(', ', @everything)) unless defined $free_initialization;

  Outputting:
  1, 2, 3

That's nice but unnecessary, and from my experience something that's easy to
code and get errors later.

But I feel the multiple '*' versions start to get too complex. And the
semantics of your latter example approached Perlish way to do it:

  *a, b, *c, d = [1,2,3,4,5] # a = [1,2,3], b = 4, c = [], d = 5

Let me add that this is actually following the same semantics as the grab
everything what's left, but the resolution for multiple grabs goes from left
to right. So after *a has grabbed everything left after b and d, there's
nothing left for *c. That's a logic too, but I doubt this is as useful as
it's complex.

	- Aleksi

In This Thread

Prev Next