Prev: swapping regex libraries
Next: what about allowing to specify, which end belongs to which start?
From: Caleb Clausen on 10 Jul 2010 11:54
On 7/9/10, Jan Lelis <prog(a)janlelis.de> wrote:
> So what about allowing to specify, which end belongs to which start?
> I've thought about something like this:
>
> end|do
> end|if
> end|def
>
> or
>
> end~do
> end~if
> end~def
>
> or
>
> end:do
> end:if
> end:def

I've been told that very old versions of ruby used to have this
feature, using a space to separate the end from the keyword being
terminated instead of | ~ or : as suggested by Jan. So, in other
words, you could write:

if foo
bar
end if


I like this syntax far above anything involving punctuation.
Supposedly, this feature was removed when the 'modifier' versions of
if and unless and etc were added to the language; keeping both was
difficult to support in the parser. However, after giving it a little
thought, it seems to me that a form of this feature could be
reintroduced with not an excessive amount of trouble. If the keyword
being terminated is immediately followed by a newline or semicolon, it
is treated as a Jan wants. Otherwise, it's treated as a 'modifier'
flow control (if it's an if or unless or etc).

I could write a RubyLexer-based preprocessor which does this pretty
easily. However, I'm not terribly motivated. This doesn't seem like
that useful a feature to me and I've got so much else to work on....

From: Brian Candler on 10 Jul 2010 12:04
Jan Lelis wrote:
> Hi Ruby mailing list,
>
> I've recently come across a pretty common situation in Ruby:
>
> end
> end
> end
>
> After those parts, you often don't know, where exactly you have to
> continue.

You can always use comments, although I'd only usually do this for
nested modules. e.g.

module Foo
module Bar
class Baz
....
end # class Baz
end # module Bar
end # module Foo

Otherwise, I've never found it a problem, unless I've missed an 'end',
or forgotten a 'do'.

ruby 1.9 with -w flag has a neat feature where it will warn if the
indentation is not as expected, thus making it much easier to find where
the problem is.

e.g.

$ cat test.rb
def foo
puts "hello"
5.times # note missing "do"
puts "world"
end
puts "goodbye"
end
$ ruby19 test.rb
test.rb:7: syntax error, unexpected keyword_end, expecting $end
$ ruby19 -w test.rb
test.rb:5: warning: mismatched indentations at 'end' with 'def' at 1
test.rb:7: syntax error, unexpected keyword_end, expecting $end

This shows that the 'end' at line 5 was associated with the 'def' at
line 1, which helps localise the problem.

It's a shame that ruby 1.8.7 doesn't have this feature, although you can
keep a copy of ruby 1.9 lying around just for locating such problems
(the parsing of the two languages is very similar, even though the
semantics are very different)
--
Posted via http://www.ruby-forum.com/.

From: Caleb Clausen on 11 Jul 2010 07:32
On 7/11/10, Robert Klemme <shortcutter(a)googlemail.com> wrote:
> I don't want to advocate this but concatenating "end" directly with the
> opening keyword is probably easy to do because it will create a whole
> bunch of new tokens , so there would be
>
> endclass
> endmodule
> enddef
> endbegin
> endif
> endunless
> endwhile
> enduntil
> endfor
> enddo
> endcase

Eh, I don't like it either.


>> However, after giving it a little
>> thought, it seems to me that a form of this feature could be
>> reintroduced with not an excessive amount of trouble. If the keyword
>> being terminated is immediately followed by a newline or semicolon, it
>> is treated as a Jan wants. Otherwise, it's treated as a 'modifier'
>> flow control (if it's an if or unless or etc).
>
> IMHO this is not feasible: "if <condition>" is almost always followed by
> a line break. And think about

Yes, but 'if' itself almost never is. So when the parser sees 'end'
followed by 'if' followed by newline, it can treat that specially.

> begin
> puts "aaa"
> end if
> x > 100
>
> This is perfectly legal with the current syntax but it looks like "end
> if" would be a terminator while in reality it is a statement modifier.

I did consider this. Who ever writes this way, instead of putting the
'if' and condition on the same line? In cases like this, I think it
would be acceptable to break broken style.

From: Jan Lelis on 11 Jul 2010 07:37
Thank you for all the opinions :)

Robert wrote:
> endclass
> endmodule
> enddef
> endbegin
> endif
> endunless
> endwhile
> enduntil
> endfor
> enddo
> endcase
>
> Did I miss one?
>
> Each of those would be then alternatively allowed to "end", so you
could
> write
>
> begin
> if foo
> else
> case x
> when y
> when z
> endcase
> end
> endbegin
>
> I still don't like it.
>

I agree, that does not look good. But with a little punctation, it
becomes more readable:

begin
if foo
else
case x
when y
when z
end~case
end
end~begin

Also compare the readability of the whole list with the token version:

end~class
end~module
end~def
end~begin
end~if
end~unless
end~while
end~until
end~for
end~do
end~case

The token version might be easier to implement, but I think, it is not
satisfying.

Caleb wrote:
> I could write a RubyLexer-based preprocessor which does this pretty
> easily. However, I'm not terribly motivated. This doesn't seem like
> that useful a feature to me and I've got so much else to work on....

Cool :). I also want to try to implement it in some way, but at the
earliest in about a month (also have too many things to do).

@Brian
Thank you for this neat 1.9 indention warning hint :)


From: Caleb Clausen on 11 Jul 2010 16:30
On 7/11/10, Robert Klemme <shortcutter(a)googlemail.com> wrote:
> On 11.07.2010 13:32, Caleb Clausen wrote:
>> On 7/11/10, Robert Klemme<shortcutter(a)googlemail.com> wrote:
>>> IMHO this is not feasible: "if<condition>" is almost always followed by
>>> a line break. And think about
>>
>> Yes, but 'if' itself almost never is.
>
> Unfortunately the word "almost" makes this unusable for creating a
> parser. How do you want the parser to decide if the case at hand is one
> of the rare cases? Even if it would be feasible this sounds like an
> awful hack and I'd rather not make parsing more complicated (and thus
> slower) as it is today.

The syntax change I proposed requires forbidding a construct which is
currently legal but rarely used and considered to be poor style. What
is wrong with that? In those few cases where someone decided to
separate an 'if' from its condition with a newline, the code would
have to be rewritten (inserting a backslash to make the newline soft
is the easiest way). Such constructs should be rewritten anyway, for
purely stylistic reasons.

This new feature, like most, will make the parser ever so slightly
slower. The delta is tiny and not worth mentioning.

And it will make the parser a little bit more complicated; however,
there are already many special cases and complications in the parser.
One more is not a big deal. The philosophy of ruby's syntax overall is
to make the parser complicated if it makes life easier for the user. I
think this change at least ought to be considered under that
criterion.

Now if you want to argue that Jan's proposal is esthetically
unpleasing, I won't really disagree. But just leave it at that. I hate
it when people try to throw up a lot of rhetorical chaff when their
real, and only valid, objection amounts to a subjective judgment call.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: swapping regex libraries
Next: what about allowing to specify, which end belongs to which start?