ruby-dev summary 26468-26661

[Brian Schröder]

[snip]
=20
I'm still not seeing a bit need for a change in this direction.
=20

Just for the protocol, I'm also very happy with the way blocks work
right now. Though I wondered a bit that block parameters are written
with pipes instead of parents when I first came to ruby.

regards,

Brian

--=20
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 26468-26661"

|> I like it! Looks much more uniform and consistent with function
|> syntax than {|...| ...}
|
|I assume you mean method syntax. But why is that important? Until
|this new syntax was posted, I'd never heard anyone complain that they
|found it hard to recognize {|...| } as a code block. Now there seems
|to be a retroactive sentiment in the air that the block syntax is, and
|always has been, obscure or garbled.

lambda is an anonymous function, so that it requires full syntax of
function/method argument, including optional arguments, keyword
arguments, block arguments etc., not just parallel assignment as in
plain block parameters.

|If uniformity is important maybe def should be redesigned:
|
| def x |a,b,c=1|
| end

Stop joking. ;-)
Unlike others, I have never given uniformity a top priority.

matz.

 

[Trans]

Hi,

In message "Re: ruby-dev summary 26468-26661"

|> I like it! Looks much more uniform and consistent with function
|> syntax than {|...| ...}
|
|I assume you mean method syntax. But why is that important? Until
|this new syntax was posted, I'd never heard anyone complain that they
|found it hard to recognize {|...| } as a code block. Now there seems
|to be a retroactive sentiment in the air that the block syntax is, and
|always has been, obscure or garbled.

lambda is an anonymous function, so that it requires full syntax of
function/method argument, including optional arguments, keyword
arguments, block arguments etc., not just parallel assignment as in
plain block parameters.

|If uniformity is important maybe def should be redesigned:
|
| def x |a,b,c=1|
| end

Stop joking. ;-)
Unlike others, I have never given uniformity a top priority.

If lambda === Method (minus context), I don't think he would be joking.

def x |a,&b|
b[a]
end

x(1) def |a|
a+1
end

But that does nothing to solve | ambiguity. So forget 'em and go back
to parens:

def x(a,&b)
b[a]
end

x(1) def n(a,b)
a+1
end

Such that #def returns a lambda/Method. The name of the lambda, n,
would be local to the block, and while usually extraneous, it can be
useful as a reference to the block itself.

[:a,:b,:c].each def n(i)
p n.count;
end
#=> 1 2 3

That still leaves { } notation. If { == def and } == end, as D. Black
"jests", at first it seems ambiguous. But actually I don't think it is.

x(1) { n(a,b) a+1 }

is decernable from:

x(1) { n(a,b) ; a+1 }

for example.

Yet I agree, over unifority can be hard on the eyes. Which is why #do
makes a good substitute for #def in block contexts.

T.

 

[Gavin Kistner]

--Apple-Mail-2-999620092
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
delsp=yes;
format=flowed

Why should you write it like that. If there is no starting ( there is
no argument list. So

Hash.new { [] }

Though that opens up the question of how to define a param-less block =20=

whose first statement started with a paren:

10.times{ (a,b =3D [1,2]).each{ ... } }=

--Apple-Mail-2-999620092--

 

[Trans]

I suprised no one's picked up on this.

[:a,:b,:c].each do n(i)
p n.count;
end
#=> 1 2 3

Seems like a very insteresting and useful notion to locally name the
block. And open up other possibilites like:

[:a,:b,:c].each do n(i)
if n.first?
# ...
end
end
#=> 1 2 3

T.

 

[Ezra Zygmuntowicz]

Hi --

[ruby-dev:26623] Ruby2.0BlockParameterNotation
Sasada asked about new notation of block parameter. This issue is
summarized
at the following sites. Now ruby(HEAD) accepts the notation '->
(...){...}'.

I'm not clear on what problem or shortcoming this addresses. Also,
I'm concerned that this amount of multiplied punctuation is going to
detract seriously from "clean" look of Ruby. I know it's not just a
matter of counting punctuation characters. But going from {|x|} to
->(x){} seems like a major move in the "line noise" direction.


David

+100
-Ezra Zygmuntowicz
WebMaster
Yakima Herald-Republic Newspaper
(e-mail address removed)
509-577-7732

 

[Ezra Zygmuntowicz]

Hi --

[ruby-dev:26623] Ruby2.0BlockParameterNotation
Sasada asked about new notation of block parameter. This issue is
summarized
at the following sites. Now ruby(HEAD) accepts the notation '->
(...){...}'.

I like it! Looks much more uniform and consistent with function
syntax than {|...| ...}

I assume you mean method syntax. But why is that important? Until
this new syntax was posted, I'd never heard anyone complain that they
found it hard to recognize {|...| } as a code block. Now there seems
to be a retroactive sentiment in the air that the block syntax is, and
always has been, obscure or garbled.

If uniformity is important maybe def should be redesigned:

def x |a,b,c=1|
end

Then you'd have parallels between blocks and methods:

def == {
end == }
|| == ||

without the -> thing.


David

I think one of the first things that attracted me to ruby is the {|
x|...} syntax. So please leave my happy little blocks alone. Or at
least leave them as an option.
-Ezra Zygmuntowicz
WebMaster
Yakima Herald-Republic Newspaper
(e-mail address removed)
509-577-7732

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 26468-26661"

|I suprised no one's picked up on this.
|
| [:a,:b,:c].each do n(i)
| p n.count;
| end
| #=> 1 2 3

The meaning of above code is not obvious for me at all, besides its
syntax conflicts existing ones.

matz.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 26468-26661"

|I think one of the first things that attracted me to ruby is the {|
|x|...} syntax. So please leave my happy little blocks alone. Or at
|least leave them as an option.

Don't worry. The block syntax will not be changed. Never.

matz.

 

[Jim Freeze]

=20

Don't worry. The block syntax will not be changed. Never.
=20
matz.

Ok, that's good to hear. So, if a new lambda syntax is created,
it doesn't necessarilly need to work for block? That is, it won't
be an alternate syntax for defining blocks?

Is there a reason that this notation wouldn't/couldn't work
for defining lambdas?

f =3D () { puts 5 } # () always required for a lambda. space doesn't m=
atter
f =3D (a){ puts a }
f =3D (x, y=3D5) { ... }

And, if used as a block...

func(a,b) (x=3D2*2) { ... }

--=20
Jim Freeze

 

[Trans]

Hi,

In message "Re: ruby-dev summary 26468-26661"

|I suprised no one's picked up on this.
|
| [:a,:b,:c].each do n(i)
| p n.count;
| end
| #=> 1 2 3

The meaning of above code is not obvious for me at all, besides its
syntax conflicts existing ones.

Read as "each do n of i ... end" such that "n of i" is the block name
and args. That's too bad if syntax conflicts, I had though maybe it was
possible. But even so I think giveng the block handle (i.e. a name such
as n above) has a lot of merit. No more need fo _with_index for
instance. Perhaps you can find another way to have block handle.

Thanks,
T.


P.S. I sent this post once but it seems to have been lost. Forgive me
if it comes up twice.

 

[Trans]

Hi,

In message "Re: ruby-dev summary 26468-26661"

|I suprised no one's picked up on this.
|
| [:a,:b,:c].each do n(i)
| p n.count;
| end
| #=> 1 2 3

The meaning of above code is not obvious for me at all, besides its
syntax conflicts existing ones.

Hmm.. read as "each do n of i ... end". But if the syntax conflict
that's too bad. Having a handle on the block (i.e. n) would be very
useful --no more _with_index stuff. Perhaps there is another way you
can work in a block handle?

Thanks,
T

 

[nobuyoshi nakada]

Hi,

At Fri, 5 Aug 2005 00:29:55 +0900,
Eric Mahurin wrote in [ruby-talk:150730]:

Here is my proposal:

{ args : code }

Even if when you make the args : optional to preserve
compatibility, I think this would be parsable if you treat the
arg list (possibly with default expressions) like a normal
statment except that the delimiter is ":" instead of ";". This
should work because an arg list is a syntactically valid
statement. i.e.

a=1
other=[3,4]
a,b=2,*other

When the lexer finds a ":" instead of a ";" or newline as the
statement delimiter of first statement, it would treat that as
the arg list.

Default values can be very long beyond new lines, if it is a
block statement or is parenthesized. it seems very confusing
and I guess such parser is impossible. Leading sign would be
mandatory.

 

[Florian Groß]

Seems like a very insteresting and useful notion to locally name the
block. And open up other possibilites like:

[:a,:b,:c].each do n(i)
if n.first?
# ...
end
end
#=> 1 2 3

I'd insert an as:

[:a, :b, :c].each as n(i) do
if n.first? then
# ...
end
end

Still needs getting used to it, though.

 

[Trans]

Ok, that's good to hear. So, if a new lambda syntax is created,
it doesn't necessarilly need to work for block? That is, it won't
be an alternate syntax for defining blocks?

Is there a reason that this notation wouldn't/couldn't work
for defining lambdas?

f = () { puts 5 } # () always required for a lambda. space doesn't matter
f = (a){ puts a }
f = (x, y=5) { ... }

And, if used as a block...

func(a,b) (x=2*2) { ... }

My concern with this is admittedly a matter of wishful thinking, but I
would nonetheless like to see ruby with currying one day like this:

def f(x,y)
x + y
end

g = f(1)

g(2) #=> 3

which means:

f(1)(2) #=> 3

Your proposed block notation would make this impossible.

T.

 

[Trans]

Seems like a very insteresting and useful notion to locally name the
block. And open up other possibilites like:

[:a,:b,:c].each do n(i)
if n.first?
# ...
end
end
#=> 1 2 3

I'd insert an as:

[:a, :b, :c].each as n(i) do
if n.first? then
# ...
end
end

Still needs getting used to it, though.

That'll work. Fits in well with the "with" version too. And really if
you substitute
-> == as/with
{ == do
} == end

[:a, :b, :c].each -> n(i) {
if n.first? then
# ...
end
}

All except for the named block, this is excactly what matz has now.

T.

 

[Eric Mahurin]

Hi,
=20
At Fri, 5 Aug 2005 00:29:55 +0900,
Eric Mahurin wrote in [ruby-talk:150730]:

Here is my proposal:
=20
{ args : code }
=20
Even if when you make the args : optional to preserve
compatibility, I think this would be parsable if you treat the
arg list (possibly with default expressions) like a normal
statment except that the delimiter is ":" instead of ";".=20 This
should work because an arg list is a syntactically valid
statement. i.e.
=20
a=3D1
other=3D[3,4]
a,b=3D2,*other
=20
When the lexer finds a ":" instead of a ";" or newline as the
statement delimiter of first statement, it would treat that as
the arg list.

=20
Default values can be very long beyond new lines, if it is a
block statement or is parenthesized. it seems very confusing
and I guess such parser is impossible. Leading sign would be
mandatory.

When I said ";" or newline, the newlines I'm talking about are
only those that delimit statements. So, you could have
newlines in your arglist as long as they don't look like a
statement terminator:

{ a,
b=3D
a*
a :
a*b
}

"->" has also been suggested instead of ":". And I suggested
;/newline if you can make the arg-list mandatory (possibly
empty).

Would you agree that any valid arg-list is also syntactically a
valid statement? Or am I wrong? Wouldn't this fact be useful
in parsing this optional arg-list?

You still have the problem of ambiguities with the hash though.
Here are a few potential options for that:

%h{ ... } # like another quoting operator
hash( ... ) # simply a Kernel method
h( ... )


{} seems too overloaded now:

{ key=3D>value, ... } # hash
{ code } # block/lambda without args
{ |args| code } # block/lambda with args

I think that the syntax should either be left alone or
backwards compatibility should be broken (where necessary) and
these ambiguities solved once and for all.




=09
____________________________________________________
Start your day with Yahoo! - make it your home page=20
http://www.yahoo.com/r/hs=20
=20

 

[nobuyoshi nakada]

Hi,

At Fri, 5 Aug 2005 23:43:27 +0900,
Eric Mahurin wrote in [ruby-talk:150889]:

Would you agree that any valid arg-list is also syntactically a
valid statement? Or am I wrong? Wouldn't this fact be useful
in parsing this optional arg-list?

Agree for the former, but not for the later. I think it
would be confusing rather than useful.

And your suggenstion would require re-parsing the source or
re-construction of nodes, after the separator was found.