From: Charles Hixson Date: 2004-10-09T04:13:00+09:00 Subject: Re: quality of error messages markus@reality.com wrote: >On Fri, 8 Oct 2004, Austin Ziegler wrote: > > > >>On Thu, 7 Oct 2004 07:39:04 +0900, Markus wrote: >> >> >>>On Wed, 2004-10-06 at 15:19, Joachim Wuttke wrote: >>> >>> >>>>Thank you, Brian. >>>>This is quite a convincing example: I count not less than eight >>>>places where the "end" could be missing. >>>>Just for curiosity: why didn't Ruby borrow indentation semantics >>>>from Python ? >>>> >>>> >>> Now there's an RCR I'd support. Heck, I'd even volunteer to code >>>it! >>> >>> >>I think you'll find more people who don't want such an abomination. >> >>Python's indentation is the number one thing that prevents me from >>even considering using that language, because it forces me to work in >>a stupid manner (e.g., *its* manner), rather than adapting to my >>manner. >> >> > > *laugh* I supose the reason I like the abomination is I learned to >indent back in the days of salient structure (before the matching-pairs >abomination took over the world). To me (and by extension, all right >thinking people), python's indentation seems perfectly natural. I suppose >it's all a matter of what abomination you grew up with. > That said, it really doesn't hurt as bad as you'd think it would, >since the main thing people differ on is where to put the closing token >(e.g., does the "end" or "}" go at the indentation of the enclosed block >or the inclosing block) and that issue vanishes if you don't have closing >tokens. I suspect that (if warned) most rubiests would find: > > class My_class > attr_reader :an_atribute > def initialize a1,a2 > @an_attribute = a1 > @counter = 0 > @limit = a2 > def feed_the_lion food > raise "Roar" unless food.respond_to? :digestible_by > raise "Grrr" unless food.digestible_by self > digest food > > waffle = My_class.new :fred,14 > >perfectly readable (and writable) without all the syntactic clutter/noise. >Required when you _don't_ pay attention to white space. Further, it's >well established that when there is discord between them people >(including long time lispers) will "read the indentation" and ignore the >punctuation regardless, so it reduces a significant source of bugs to >have the language look at the same features of the source code as the >person did. About the only measured downside (IIRC) is that it increases >the error rate when people are typing in code from a printed source. That >doesn't happen nearly as much as it used to. > > BTW, I am _not_ trying to push this change; I'm just trying to >explain why I would not object to it, and suspect that many others would >find it more palatable than they might think. > > -- Markus > For that sample, you are correct, but when blocks get a bit more complex it fails. Miserably in my opinion. Even when programming in Python I typically add an end statement, e.g. class My_class: def __init__(self, a1,a2): self.an_attribute = a1 self.counter = 0 self.limit = a2 #end __init__ def feed_the_lion(self, food): raise "Roar" unless food.respond_to? :digestible_by raise "Grrr" unless food.digestible_by self digest food #end feed_the_lion #end class My_class waffle = My_class.new :fred,14 Note this is an incomplete conversion. Also note that I don't just use end statements, I label them. (Also note that I couldn't decide whether or not waffle was a member of My_class just by looking at it. It required noticing that it was an instantiation of the class. (Which I couldn't remember how to do in Python.) I guess that I got my block conventions from Ada. (Fortran was rather....vague about them, except for not before column 6 and not after column 72.) My personal convention about when to use {} and when to use do..end is: If it's within a single line, use {}. Otherwise tend to prefer do..end This isn't a strong convention, but I try to not depend on relative binding power (partially because I can never remember the exact precedence order).