>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.
···
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
···
In message "Re: ruby-dev summary 26468-26661" > on Fri, 5 Aug 2005 10:06:05 +0900, "Trans" <transfire@gmail.com> writes:
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.
> 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.
In the 1.9 I tried, the new syntax that few people like works
both for lambdas and blocks.
···
--- James Edward Gray II <james@grayproductions.net> wrote:
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.
____________________________________________________
Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
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=
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( ... )
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.
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.
____________________________________________________
Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
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.
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.
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.
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.
