what about allowing to specify, which end belongs to which start?
in [Ruby]
|
Prev: what about allowing to specify, which end belongs to which start?
Next: [ANN] sqlite3-ruby 1.3.1 Released
From: Robert Klemme on 9 Jul 2010 17:08 On 09.07.2010 21:17, Ryan Davis wrote: > > On Jul 9, 2010, at 12:05 , Jan Lelis wrote: > >> 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. >> >> 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 Not to forget about end:case, end:class, end:module... >> If you specify it, and it does not match, the compiler throws an >> error. Of course, you can always omit it to have the normal The compiler as it is today will throw an error anyway. >> behaviour, but you are encouraged to often "document", which end >> belongs to which block (and you do yourself a favour in these >> nested situations). I think "encouraged" is the wrong word. Your extension would _force_ the user to use this idiom (which I personally find too verbose). Also, your solution does not help if you nest the same type of control flow statement. If you want to document nesting you can do that today already (and some people actually do it). But I agree with Ryan here: >> What do you think about it? > I think if you have so many ends that you need to extend the syntax > then you're doing something wrong to begin with (no pun). I try to > make all my methods short when I can, and I use judicious use of > extra returns to separate code into paragraphs to further help. I > think this type of syntax extension would further encourage large bad > codes. Plus, editors with auto indentation and code completion usually help. I personally have made it a habit to always write the opening and closing construct before I fill in the body. That way you can work pretty well even if your editor does not have fancy features. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Robert Klemme on 11 Jul 2010 04:38 On 10.07.2010 17:54, Caleb Clausen wrote: > 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. 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 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. > 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 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 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.... :-) Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Robert Klemme on 11 Jul 2010 07:57 On 11.07.2010 13:37, Jan Lelis wrote: > 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: .... and much less typeable on my keyboard (German). > 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. The whole concept is dissatisfying to me. :-) Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Robert Klemme on 11 Jul 2010 08:00
On 11.07.2010 13:32, Caleb Clausen wrote: > 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. 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. > 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. Let's hear what others say. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ |