Home > Archive > Ruby > August 2005 > ruby-dev summary 26468-26661
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ruby-dev summary 26468-26661
|
|
| Takaaki Tateishi 2005-08-03, 5:05 pm |
| Here are recent ruby-dev summaries.
Regards,
ruby-dev:26468-26661
[ruby-dev:26468] security error of open-uri when accessing a redirect URL.
Kazuhiko suggested that a security error should not be caused if we access a remote site specified
by an untainted URL string using open-uri in case of $SAFE=1 and the remote server returns redirect
URL. This post set off a discussion about the definition of the taint feature and the security
mechanism, since the definition seems to use undefined ambiguous terms and we don't explicitly
explain when and how we untaint a tainted object.
[ruby-dev:26616] public method
Seki asked about features like 'public', 'private' and 'protected', since He tried to change his
codes in dRuby to check restriction of method calls. In this issue, he proposed a new method like
'send', which can't call private methods. Matz will accept his idea if its appropriate name is decided.
[ruby-dev:26623] Ruby2.0BlockParameterNotation
Sa a asked about new notation of block parameter. This issue is summarized
at the following sites. Now ruby(HEAD) accepts the notation '->(...){...}'.
http://pub.cozmixng.org/~the-rwiki/...rameterNotation
http://redhanded.hobix.com/inspect/blockAndLambda.html
--
Takaaki Tateishi <ttate@ttsky.net>
| |
| Navindra Umanee 2005-08-03, 5:05 pm |
| Takaaki Tateishi <ttate@ttsky.net> wrote:
> [ruby-dev:26623] Ruby2.0BlockParameterNotation
> Saa 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 {|...| ...}
Thanks for your summary.
Cheers,
Navin.
> http://pub.cozmixng.org/~the-rwiki/...rameterNotation
> http://redhanded.hobix.com/inspect/blockAndLambda.html
> --
> Takaaki Tateishi <ttate@ttsky.net>
>
>
| |
| Berger, Daniel 2005-08-03, 5:05 pm |
| > -----Original Message-----
> From: Navindra Umanee [mailto:navindra@cs.mcgill.ca]=20
> Sent: Wednesday, August 03, 2005 11:33 AM
> To: ruby-talk ML
> Subject: Re: ruby-dev summary 26468-26661
>=20
>=20
> Takaaki Tateishi <ttate@ttsky.net> wrote:
> issue is summarized
>=20
> I like it! Looks much more uniform and consistent with=20
> function syntax than {|...| ...}
>=20
> Thanks for your summary.
>=20
> Cheers,
> Navin.
Blech. It's no cleaner, consistent or uniform to me. Ruby's problems
have nothing to do with syntax. Stop messing with it please.
Regards,
Dan
| |
| Daniel Berger 2005-08-03, 5:05 pm |
| Takaaki Tateishi wrote:
<snip>
> [ruby-dev:26616] public method
> Seki asked about features like 'public', 'private' and 'protected', since He tried to change his
> codes in dRuby to check restriction of method calls. In this issue, he proposed a new method like
> 'send', which can't call private methods. Matz will accept his idea if its appropriate name is decided.
>
deliver
direct
dispatch
issue
post
connect
transmit
call
Of these, I like "call" the most, but I'm aware of the confusion it
might cause wrt Method#call.
Regards,
Dan
| |
| Joel VanderWerf 2005-08-03, 5:05 pm |
| Daniel Berger wrote:
> Takaaki Tateishi wrote:
>
> <snip>
>
>
>
>
> deliver
> direct
> dispatch
> issue
> post
> connect
> transmit
> call
>
> Of these, I like "call" the most, but I'm aware of the confusion it
> might cause wrt Method#call.
>
> Regards,
>
> Dan
Or, looking at it from the point of view of the receiver:
handle
respond
receive
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
| |
|
| Instead of another method like send, which does exactly what normally
calling a method does, expect it allows for a variable method name (ie.
symbol or string) why not just allow '.' to dispatch a symbol or
string, instead of just a literal:
obj.:meth
obj."meth"
That would be useless in itself (one can just type 'obj.ameth'), but
now you can use variable interpolation:
m = "meth"
obj."#{m}"
Which does the job. Hmm... scaling this back to just the core
requirement, we could simplify to:
obj#{m}
or
obj#m
That later would require trailing remarks to begin with a space, but
that's a common practice anyway. It's a nice simple notation, but maybe
to "easy" for matz taste?
T.
T.
| |
|
| Let me get this straight:
meth(x,y) -> (a,b) {
...
}
instead of
meth(x,y) { |a,b|
...
}
Two extra keystrokes. So why this? B/c Perl6 has it?
What are the critera for this? Is it only for the ambiguity of '|' with
default parameters? Does being able to do this help?
meth(x,y) -> (a,b)
{
...
}
Will we be able to drop the parens?
meth x,y -> a,b {
...
}
And use the word 'with' in place of '->' to go with 'do..end'
meth x,y with a,b do
...
end
Is that the developing picture?
Thanks,
T.
| |
| Jim Freeze 2005-08-03, 5:06 pm |
| > meth(x,y) -> (a,b) {
> ...
> }
What about scope? This notation makes me think that
(a,b)'s scope is not confined within { }.
--=20
Jim Freeze
| |
| George Moschovitis 2005-08-03, 5:06 pm |
| > at the following sites. Now ruby(HEAD) accepts the notation '->(...){...}'.
> I like it! Looks much more uniform and consistent with function
> syntax than {|...| ...}
Couldn't agree more. I like this! Perhaps the notation could be further
improved though.
George
--
http://www.gmosx.com
http://www.nitrohq.com
| |
| Trans 2005-08-03, 10:02 pm |
| > What about scope? This notation makes me think that
> (a,b)'s scope is not confined within { }.
That's a good point.
| |
| David A. Black 2005-08-04, 9:06 am |
| Hi --
On Thu, 4 Aug 2005, Takaaki Tateishi wrote:
> [ruby-dev:26623] Ruby2.0BlockParameterNotation
> Saa 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
--
David A. Black
dblack@wobblini.net
| |
| David A. Black 2005-08-04, 9:06 am |
| Hi --
On Thu, 4 Aug 2005, Navindra Umanee wrote:
> Takaaki Tateishi <ttate@ttsky.net> wrote:
>
> 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
--
David A. Black
dblack@wobblini.net
| |
| Jamis Buck 2005-08-04, 9:06 am |
| On Aug 4, 2005, at 7:31 AM, David A. Black wrote:
> Hi --
>
> On Thu, 4 Aug 2005, Takaaki Tateishi wrote:
>
>
>
> 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.
>
>
IIRC, part of the problem with the || syntax is that it makes it very
difficult to support default parameter values, because the | becomes
ambiguous:
{ |x=5| x+7 }
It's no longer possible to tell if the | marks the end of the
parameter block or a bit-wise OR without reading ahead, possibly to
the end of the block.
- Jamis
| |
| Brian Schröder 2005-08-04, 5:06 pm |
| On 04/08/05, Jamis Buck <jamis@37signals.com> wrote:
> On Aug 4, 2005, at 7:31 AM, David A. Black wrote:
>=20
>=20
> IIRC, part of the problem with the || syntax is that it makes it very
> difficult to support default parameter values, because the | becomes
> ambiguous:
>=20
> { |x=3D5| x+7 }
>=20
> It's no longer possible to tell if the | marks the end of the
> parameter block or a bit-wise OR without reading ahead, possibly to
> the end of the block.
>=20
> - Jamis
>=20
>=20
>=20
Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.
{ (a, b=3D12) a+b }
is quite clear, and counting nesting parenthesis has to be done in any
parser so this
{ (a=3D12, (b,c) =3D [1,2]) a+b**c }
is also possible
regards,
Brian
--=20
http://ruby.brian-schroeder.de/
Stringed instrument chords: http://chordlist.brian-schroeder.de/
| |
| David A. Black 2005-08-04, 5:06 pm |
| | |
| Brian Schröder 2005-08-04, 5:06 pm |
| On 04/08/05, David A. Black <dblack@wobblini.net> wrote:
> Hi --
>=20
> On Thu, 4 Aug 2005, [ISO-8859-1] Brian Schr=F6der wrote:
>=20
>=20
> However, { (a) } would be ambiguous. (I don't particularly mind living
> without default values in blocks, but I think () wouldn't fly.)
One could disambiguate this the same way it is done with methods:
{ () (a) }
like in
def anonymus() (a) end
or one could use a differnt pair of symbols, though I don't really like tha=
t.
{ <a, b=3D12> a+b }
Though it's easier to type on a german keyboard. (Thats also one of
the reasons I thoroughly dislike any use of the backslash \. Its just
really inkonvenient to me ;)
regards,
Brian
--=20
http://ruby.brian-schroeder.de/
Stringed instrument chords: http://chordlist.brian-schroeder.de/
| |
| Nikolai Weibull 2005-08-04, 5:06 pm |
| Brian Schr=F6der wrote:
> Then why don't we use two different delimiters, e.g. (,) which would
> even unify with method declaration.
>=20
> { (a, b=3D12) a+b }
I don't understand why we can't retain the use of vertical bars. Is
there some problem with extending their use to be like methods in
general?,
nikolai
--=20
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
| |
| David A. Black 2005-08-04, 5:06 pm |
| | |
| David A. Black 2005-08-04, 5:06 pm |
| | |
| Eric Mahurin 2005-08-04, 5:06 pm |
| --- Brian Schr=F6der <ruby.brian@gmail.com> wrote:
> On 04/08/05, David A. Black <dblack@wobblini.net> wrote:
> which would
> be done in any
> mind living
> fly.)
>=20
> One could disambiguate this the same way it is done with
> methods:
>=20
> { () (a) }
>
> like in
>=20
> def anonymus() (a) end
That doesn't sound bad and is consistent with "def". But, it
does introduce a backwards incompatibility when you have "{ (a)
}" in existing code.
> or one could use a differnt pair of symbols, though I don't
> really like that.
>=20
> { <a, b=3D12> a+b }
Definitely wouldn't work. Take a look at this:
{ <a, b=3D12 > a+b>2 }
Do you interpret it that way or this way:
{ < a, b=3D12>a+b > 2 }
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=3D1
other=3D[3,4]
a,b=3D2,*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.
I like this because it gives the minimal amount of punctuation
for the arg list - one character as a delimiter.
=09
________________________________________
____________
Start your day with Yahoo! - make it your home page=20
http://www.yahoo.com/r/hs=20
=20
| |
| Brian Schröder 2005-08-04, 5:06 pm |
| On 04/08/05, David A. Black <dblack@wobblini.net> wrote:
> Hi --
>=20
> On Thu, 4 Aug 2005, [ISO-8859-1] Brian Schr=F6der wrote:
>=20
y[color=darkred]
>=20
> But then you'd have empty parens all over the place. I guess there
> aren't that many paramless blocks, but there are some, like:
>=20
> Hash.new { () [] } # ugh
>=20
Why should you write it like that. If there is no starting ( there is
no argument list. So
Hash.new { [] }
would work in this case.
You'd only need an () if the expression starts with a (.
But maybe there are better options.
regards,
Brian
that.[color=darkred]
>=20
> irb(main):005:0> def x(a =3D 1 > 0); p a; end
> =3D> nil
> irb(main):006:0> x
> true
>=20
Ahh, I didn't think of that, and I'm shure theres also a big flaw in
my other thoughts.
regards,
Brian
--=20
http://ruby.brian-schroeder.de/
Stringed instrument chords: http://chordlist.brian-schroeder.de/
| |
| Brian Schröder 2005-08-04, 5:06 pm |
| On 04/08/05, David A. Black <dblack@wobblini.net> wrote:
> [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 2005-08-04, 5:06 pm |
| Hi,
In message "Re: ruby-dev summary 26468-26661"
on Thu, 4 Aug 2005 22:38:06 +0900, "David A. Black" <dblack@wobblini.net> writes:
|> 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.
| |
| Christian Neukirchen 2005-08-04, 5:06 pm |
| Jamis Buck <jamis@37signals.com> writes:
> IIRC, part of the problem with the || syntax is that it makes it very
> difficult to support default parameter values, because the | becomes
> ambiguous:
>
> { |x=5| x+7 }
>
> It's no longer possible to tell if the | marks the end of the
> parameter block or a bit-wise OR without reading ahead, possibly to
> the end of the block.
I have no clue about the Bison grammar underlying Ruby, but can't you
"simply" say that if the first token after { is a |, you need to parse
until the next | to get the block parameters?
Of course, you couldn't write { |x = 5|7 | true } then... *I* can live
with that.
> - Jamis
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
| |
| Yukihiro Matsumoto 2005-08-04, 5:06 pm |
| Hi,
In message "Re: ruby-dev summary 26468-26661"
on Fri, 5 Aug 2005 01:14:46 +0900, Christian Neukirchen <chneukirchen@gmail.com> writes:
|I have no clue about the Bison grammar underlying Ruby, but can't you
|"simply" say that if the first token after { is a |, you need to parse
|until the next | to get the block parameters?
It would be great if it's possible. But unfortunately I don't have
enough skills to accomplish this using yacc/bison.
|Of course, you couldn't write { |x = 5|7 | true } then... *I* can live
|with that.
You can always use {|x=(5|7)| true }.
matz.
| |
|
|
Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: ruby-dev summary 26468-26661"
> on Thu, 4 Aug 2005 22:38:06 +0900, "David A. Black" <dblack@wobblini.net> writes:
>
> |> 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.
| |
| Christian Neukirchen 2005-08-04, 5:07 pm |
| Yukihiro Matsumoto <matz@ruby-lang.org> writes:
> Hi,
>
> In message "Re: ruby-dev summary 26468-26661"
> on Fri, 5 Aug 2005 01:14:46 +0900, Christian Neukirchen <chneukirchen@gmail.com> writes:
>
> |I have no clue about the Bison grammar underlying Ruby, but can't you
> |"simply" say that if the first token after { is a |, you need to parse
> |until the next | to get the block parameters?
>
> It would be great if it's possible. But unfortunately I don't have
> enough skills to accomplish this using yacc/bison.
Neither do I...
> |Of course, you couldn't write { |x = 5|7 | true } then... *I* can live
> |with that.
>
> You can always use {|x=(5|7)| true }.
Good point.
> matz.
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
| |
| Gavin Kistner 2005-08-04, 5:07 pm |
| On Aug 4, 2005, at 9:47 AM, Brian Schröder wrote:
> 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
whose first statement started with a paren:
10.times{ (a,b = [1,2]).each{ ... } }
| |
| Jim Freeze 2005-08-04, 5:07 pm |
| It was brought up today at lunch by Hal
that we could always use paren' to denote
default arguments. I think it is a rare enough
event, and the method has little impact on=20
the language, that it may be the best idea yet.
<disclaimer>I'm not sure if Hal or someone else
came up with the idea first</disclaimer>
x(a,b) { |y, (z=3D2)| .... }
x(a,b) { |y, (z=3D5|7)| ... }
mylambda =3D lambda { |(a=3D1), (b=3D2) ... }
x(a,b, &mylambda)
--=20
Jim Freeze
| |
| David A. Black 2005-08-04, 5:07 pm |
| Hi --
On Fri, 5 Aug 2005, Jim Freeze wrote:
> It was brought up today at lunch by Hal
> that we could always use paren' to denote
> default arguments. I think it is a rare enough
> event, and the method has little impact on
> the language, that it may be the best idea yet.
> <disclaimer>I'm not sure if Hal or someone else
> came up with the idea first</disclaimer>
>
> x(a,b) { |y, (z=2)| .... }
> x(a,b) { |y, (z=5|7)| ... }
> mylambda = lambda { |(a=1), (b=2) ... }
> x(a,b, &mylambda)
Just thinking out loud, so to speak (so to speak [so to speak...]):
x(a,b) {|y, z(=2)| ... }
Sort of: "z (which defaults to 2)"
David
--
David A. Black
dblack@wobblini.net
| |
| Jim Freeze 2005-08-04, 5:07 pm |
| > Just thinking out loud, so to speak (so to speak [so to speak...]):
>=20
> x(a,b) {|y, z(=3D2)| ... }
>=20
> Sort of: "z (which defaults to 2)"
As long as we are being noisy in our thinking, I'm pretty sure
that a parser would not confuse the character combo '(=3D'
with a valid syntax. :)
lambda { |x(=3D1), y(=3D(2**(3-2))| ... }
lambda { |(x=3D1), (y=3D(2**(3-2))| ... }
Hmm, it defintely makes the arguments more visible when there are defaults.
--=20
Jim Freeze
| |
| Ryan Leavengood 2005-08-04, 10:02 pm |
| Jim Freeze said:
>
> As long as we are being noisy in our thinking, I'm pretty sure
> that a parser would not confuse the character combo '(=3D'
> with a valid syntax. :)
>
> lambda { |x(=3D1), y(=3D(2**(3-2))| ... }
> lambda { |(x=3D1), (y=3D(2**(3-2))| ... }
>
> Hmm, it defintely makes the arguments more visible when there are
> defaults.
I agree. I like this one more than most of the other suggestions. In fact=
,
a lot of them I strongly dislike. But I tend to resist changes in
programming languages I use, especially Ruby. Mostly because changes are
usually wanted by novices or new programmers who haven't yet fully
embraced the idioms of the language (though this does not always apply,
like any generalization.)
I'm still mulling over the original ->(...){...} change, but my first gut
reaction was dislike.
Ryan
| |
| Trans 2005-08-04, 10:02 pm |
|
Jim Freeze wrote:
> lambda { |x(=1), y(=(2**(3-2))| ... }
> lambda { |(x=1), (y=(2**(3-2))| ... }
It may seem simple enough but its horrible. I think maybe this should
be looked upon as an oppurtunity to go back and really think about this
part of the Ruby syntax and how it all fits together. Really, there
won't be another chance. I can't imagine this kind of indepth
consideration come Ruby 3.0. So now is the time to do it. I think
truely fixing the issue rather than patching it is a better solution
even if mens some work on our part to transition our old programs.
2c,
T.
| |
| Trans 2005-08-04, 10:02 pm |
| 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 2005-08-04, 10:02 pm |
|
On Aug 4, 2005, at 6:31 AM, David A. Black wrote:
> Hi --
>
> On Thu, 4 Aug 2005, Takaaki Tateishi wrote:
>
>
>
> 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
>
> --
> David A. Black
> dblack@wobblini.net
>
+100
-Ezra Zygmuntowicz
WebMaster
Yakima Herald-Republic Newspaper
ezra@yakima-herald.com
509-577-7732
| |
| David A. Black 2005-08-04, 10:02 pm |
| Hi --
On Fri, 5 Aug 2005, Trans wrote:
>
> Jim Freeze wrote:
>
>
> It may seem simple enough but its horrible. I think maybe this should
> be looked upon as an oppurtunity to go back and really think about this
> part of the Ruby syntax and how it all fits together. Really, there
> won't be another chance. I can't imagine this kind of indepth
> consideration come Ruby 3.0. So now is the time to do it. I think
> truely fixing the issue rather than patching it is a better solution
> even if mens some work on our part to transition our old programs.
Sorry for the "horrible" suggestion, but I think we are all discussing
and examining the syntax in good faith.
David
--
David A. Black
dblack@wobblini.net
| |
| Ezra Zygmuntowicz 2005-08-04, 10:02 pm |
|
On Aug 4, 2005, at 6:38 AM, David A. Black wrote:
> Hi --
>
> On Thu, 4 Aug 2005, Navindra Umanee wrote:
>
>
>
> 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
>
> --
> David A. Black
> dblack@wobblini.net
>
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
ezra@yakima-herald.com
509-577-7732
| |
| Yukihiro Matsumoto 2005-08-04, 10:02 pm |
| Hi,
In message "Re: ruby-dev summary 26468-26661"
on Fri, 5 Aug 2005 10:06:05 +0900, "Trans" <transfire@gmail.com> writes:
|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 2005-08-04, 10:02 pm |
| Hi,
In message "Re: ruby-dev summary 26468-26661"
on Fri, 5 Aug 2005 10:09:55 +0900, Ezra Zygmuntowicz <ezra@yakima-herald.com> writes:
|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.
| |
| Ezra Zygmuntowicz 2005-08-04, 10:02 pm |
|
On Aug 4, 2005, at 9:23 AM, Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: ruby-dev summary 26468-26661"
> on Fri, 5 Aug 2005 01:14:46 +0900, Christian Neukirchen
> <chneukirchen@gmail.com> writes:
>
> |I have no clue about the Bison grammar underlying Ruby, but can't you
> |"simply" say that if the first token after { is a |, you need to
> parse
> |until the next | to get the block parameters?
>
> It would be great if it's possible. But unfortunately I don't have
> enough skills to accomplish this using yacc/bison.
>
> |Of course, you couldn't write { |x = 5|7 | true } then... *I* can
> live
> |with that.
>
> You can always use {|x=(5|7)| true }.
>
> matz.
>
>
I think this looks the best to me.
-Ezra Zygmuntowicz
WebMaster
Yakima Herald-Republic Newspaper
ezra@yakima-herald.com
509-577-7732
| |
| Jim Freeze 2005-08-04, 10:02 pm |
| >=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 2005-08-04, 10:02 pm |
|
Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: ruby-dev summary 26468-26661"
> on Fri, 5 Aug 2005 10:06:05 +0900, "Trans" <transfire@gmail.com> writes:
>
> |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 2005-08-04, 10:02 pm |
|
Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: ruby-dev summary 26468-26661"
> on Fri, 5 Aug 2005 10:06:05 +0900, "Trans" <transfire@gmail.com> writes:
>
> |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 2005-08-04, 10:02 pm |
| 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.
--
Nobu Nakada
| |
| Florian Groß 2005-08-05, 4:01 am |
| Trans wrote:
> 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.
| |
|
|
Jim Freeze wrote:
>
> 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.
| |
|
|
Florian Gro=DF wrote:
> Trans wrote:
>
>
> 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
-> =3D=3D as/with
{ =3D=3D do
} =3D=3D 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=2E
| |
| Eric Mahurin 2005-08-05, 5:04 pm |
| --- nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:
> Hi,
>=20
> At Fri, 5 Aug 2005 00:29:55 +0900,
> Eric Mahurin wrote in [ruby-talk:150730]:
> the
> This
> the
> as
>=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
| |
| gabriele renzi 2005-08-05, 5:04 pm |
| Yukihiro Matsumoto ha scritto:
> Hi,
>
> In message "Re: ruby-dev summary 26468-26661"
> on Fri, 5 Aug 2005 01:14:46 +0900, Christian Neukirchen <chneukirchen@gmail.com> writes:
>
> |I have no clue about the Bison grammar underlying Ruby, but can't you
> |"simply" say that if the first token after { is a |, you need to parse
> |until the next | to get the block parameters?
>
> It would be great if it's possible. But unfortunately I don't have
> enough skills to accomplish this using yacc/bison.
jus to notice: there is a language named SuperCollider[1] which by some
strange case
- has a rubyish syntax
- seem to be able to handle all this things:
{ stuff() } #block with no arguments
{|i| stuff_with(i))} #block with argument
{ |a="", b=""| stuff_with(defaulted_args) } # block with default args
- has a "|" pairwise operator
My only experience with yacc/bison has been a (mini)pascal->c compiler
so I'm definitely not intelligent enough to check this out, but maybe
some wiser people can take a look.
[1] see http://c2.com/cgi/wiki?SuperCollider
and http://sourceforge.net/projects/supercollider
| |
| James Edward Gray II 2005-08-05, 5:05 pm |
| On Aug 4, 2005, at 11:23 AM, Yukihiro Matsumoto wrote:
> |Of course, you couldn't write { |x = 5|7 | true } then... *I* can
> live
> |with that.
>
> You can always use {|x=(5|7)| true }.
That makes it seem like a very small sacrifice then. It's an edge
case and there's a work-around, they way I read that. Works for me.
I too hate the -> (...) idea. I left Perl for Ruby. ;)
James Edward Gray II
| |
| James Edward Gray II 2005-08-05, 5:05 pm |
| On Aug 5, 2005, at 3:59 PM, James Edward Gray II wrote:
> I too hate the -> (...) idea. I left Perl for Ruby. ;)
Now that I've read on, I understand that this is for lambdas only and
it bothers me a *little* less. I still would prefer we translate ->
to a keyword though, if possible.
James Edward Gray II
| |
| Eric Mahurin 2005-08-05, 5:05 pm |
| --- James Edward Gray II <james@grayproductions.net> wrote:
> On Aug 5, 2005, at 3:59 PM, James Edward Gray II wrote:
>=20
>=20
> Now that I've read on, I understand that this is for lambdas
> only and =20
> it bothers me a *little* less. I still would prefer we
> translate -> =20
> to a keyword though, if possible.
In the 1.9 I tried, the new syntax that few people like works
both for lambdas and blocks.
=09
________________________________________
____________
Start your day with Yahoo! - make it your home page=20
http://www.yahoo.com/r/hs=20
=20
| |
| nobuyoshi nakada 2005-08-08, 4:02 am |
| 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.
--
Nobu Nakada
|
|
|
|
|