quality of error messages

[Markus]

The problem, as with all such systems, is that you are now looking
at something the compiler does not. That's the main reason why salient
structure systems such as python's measurably reduce programmer errors:
if you use them you are perforce seeing what the compiler sees, no more,
no less.

Remember the old adage: "Don't get suckered in by comments; read
the code"

-- Markus

P.S. Again, for the record, I am NOT advocating salience for ruby.

 

[Charles Hixson]

But is that an argument against labeling end markers, or an argument in favor of allowing Ruby to optionally recognize them? I agree that it's a true argument, I just consider it better than nothing.

The problem, as with all such systems, is that you are now looking
at something the compiler does not. That's the main reason why salient
structure systems such as python's measurably reduce programmer errors:
if you use them you are perforce seeing what the compiler sees, no more,
no less.

Remember the old adage: "Don't get suckered in by comments; read
the code"

-- Markus

P.S. Again, for the record, I am NOT advocating salience for ruby.

On Fri, 2004-10-08 at 12:13, Charles Hixson wrote:

...

 

[Joachim Wuttke]

The compiler should complain about incorrectly labeled "end" markers,
but not about missing markers.

If code contains markers the compiler will use them to produce more
precise error messages. If there are no such markers, the compiler
will behave as of now.

Which means that optional "end" markers could be introduced into Ruby's
syntax without any need for a new compiler flag: the syntax change will
have no effect except for code that effectively uses the markers.

- Joachim

Charles wrote

But is that an argument against labeling end markers, or an argument in
favor of allowing Ruby to optionally recognize them? [...]

The problem, as with all such systems, is that you are now looking
at something the compiler does not. That's the main reason why salient
structure systems such as python's measurably reduce programmer errors:
if you use them you are perforce seeing what the compiler sees, no more,
no less. [...]

 

[Markus]

The problem, as with all such systems, is that you are now looking

But is that an argument against labeling end markers, or an argument
in favor of allowing Ruby to optionally recognize them? I agree that
it's a true argument, I just consider it better than nothing.

So (summarizing my previous posts on this thread):

* It isn't possible to give useful hints about the location of an
unclosed structure with out using "out of band" information that
the compiler presently does not use. Ruby is not being
intentionally obtuse in its error reporting; it simply does not
know, and can not know, what construct was left open in
general. It can't even guess.
* Therefore if we want better information about the source of
"missing end" errors, we will have to let the compiler use
information it does not presently have
* This is (IMHO) not worth breaking any existing code at all.
* A guess could be made by looking at the indentation (see
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115641 for the details) provided
* that we took into account of the fact that most people
claim to use the salience rules but actually do
pair-matching
* No warnings should be generated (the information should
only be reported in case of an actual error)
* Augmenting 'end' (optionally) with a structure keyword and a
name might be possible. It would certainly provide enough
information, but may or may not be implementable
* Having the compiler "read comments" is a Bad Idea.
* I would support any of the ideas that 1) would work and 2) are
not Bad Ideas.
* I will argue for the truth, even if in doing so I undermine my
own prejudices. No strike that. _Especially_ if it will
undermine my prejudices.

Does that answer your question?

-- Markus

 

[Kristof Bastiaensen]

If a program could guide where I look that would be nice. Therefore also
an external program or an xemacs plugin would be nice to me.

And just to clarify: This is in no way urgent or very important to me, I
just liked the idea

Here is a simple emacs function that does the job:

(defun ruby-check-ends ()
(interactive)
(let (loose-end)
(save-excursion
(goto-char (point-min))
(while (and (not loose-end)
(re-search-forward "^[ \t]*\\(end\\)[ \t\n]" nil t))
(goto-char (match-beginning 1))
(if (not (eq (current-column) (ruby-calculate-indent)))
(setq loose-end (point)))
(forward-char)))
(cond (loose-end
(goto-char loose-end)
(message "indentation of end is not correct")))))

It may not work correctly if you use a different style then the
one emacs is set up to, but you will probably use this for your code
anyway.

Regards,
Kristof

 

[Brian Schröder]

If a program could guide where I look that would be nice. Therefore also
an external program or an xemacs plugin would be nice to me.

And just to clarify: This is in no way urgent or very important to me, I
just liked the idea

Here is a simple emacs function that does the job:

(defun ruby-check-ends ()
(interactive)
(let (loose-end)
(save-excursion
(goto-char (point-min))
(while (and (not loose-end)
(re-search-forward "^[ \t]*\\(end\\)[ \t\n]" nil t))
(goto-char (match-beginning 1))
(if (not (eq (current-column) (ruby-calculate-indent)))
(setq loose-end (point)))
(forward-char)))
(cond (loose-end
(goto-char loose-end)
(message "indentation of end is not correct")))))

It may not work correctly if you use a different style then the
one emacs is set up to, but you will probably use this for your code
anyway.

Regards,
Kristof

Nicely done! I added it to my init.el. And again I learned a bit more elisp.

regards,

Brian

 

[Austin Ziegler]

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.

I don't find it readable at all.

-austin

 

[Jamis Buck]

I don't find it readable at all.

I completely, 100%, in every way, concur with Austin. I detest any
attempt to enforce an arbitrary indentation style upon me. It's why I
chucked Python just months after first learning about it. But that's
just my opinion.

- Jamis

 

[Markus]

That said, it really doesn't hurt as bad as you'd think it would,

I completely, 100%, in every way, concur with Austin. I detest any
attempt to enforce an arbitrary indentation style upon me.

No one is trying to enforce anything on anyone here. No one is
even trying to make you eat green eggs and ham.

I had just been trying to explain (in response, as I recall, to a
question of some sort) how people who use python (and other
salient-structure languages) see the world; they aren't brain damaged
mutants (at least in my opinion), nor are they enslaved masses being
"forced" to use python.

Some people actually like it, and their reasons are fairly
explicable, just as the reasons for liking (say) perl or smalltalk or
lisp or ruby or forth or...well, you get the point. There's no harm
that I can see in trying to understand someone else's perspective, even
if you don't share it.

-- Markus

 

[Jamis Buck]

Some people actually like it, and their reasons are fairly
explicable, just as the reasons for liking (say) perl or smalltalk or
lisp or ruby or forth or...well, you get the point. There's no harm
that I can see in trying to understand someone else's perspective, even
if you don't share it.

I understand that people like that approach. I don't begrudge them that.
But they use Python because they like that approach, and I don't use
Python because I don't like that approach. Like Austin, I do not find
that it adds readability to the code--I actually feel that it detracts
from the readability.

But that's my opinion. I'm not out to change Python, and I don't think
Python users are, as you said, "brain damaged mutants." I also do not
think anyone is forcing them to use Python. They use Python because it
fits their preferred coding style.

It does not fit mine.

I simply get touchy when people start suggesting that perhaps Ruby ought
to adopt such a style. My apologies if I ruffled any feathers.

- Jamis

 

[Markus]

I simply get touchy when people start suggesting that perhaps Ruby ought

to adopt such a style.

No one that (I heard) suggested such a thing. We were talking
about how one might use the information implicit in people's normal
indentation style (whatever they choose) to guess the location of a
missing 'end'--which the present compiler typically reports as a 'parse
error' at the end of the file.

For what it's worth, I have an experimental patch (yes, in fact I
am a glutton for punishment) that does very well at finding ends I've
deleted from arbitrary ruby code. It doesn't rely on any particular
indentation style (it would "work" even if you indented at random, but
it's hints would likely be no more helpful than the present message) and
doesn't do anything if there are no missing ends.

If you are interested, it can be found via

http://blade.nagaokaut.ac.jp/ruby/ruby-core/3486

Note that it doesn't impose anything on anybody. All it does is add a
few possibly helpful line numbers to an otherwise terse error message.

My apologies if I ruffled any feathers.

No worries. I'm just trying to dampen the extreme polarization
that seems to happen when people react to an excerpt from a more
involved discussion.

-- Markus

 

[Austin Ziegler]

I think that you don't have to enforce any particular indentation style or
amount of space on each line - only that it is consistent between begin and
end.

No, no, no, and NO!

When I am writing code, I will often do:

class Foo
def bar
: # some code here
p baz # a tracer to help me find a difficult bug
: # more code here
end
end

Your suggestion would force me to indent the tracer -- which I have
*purposefully* overridden the auto-formatting by vim to insert --
which leads me to the same idiocy that keeps me from Python as a first
point.

Tracer code is too useful to be bound by people who don't use editors
that help them write their code through use of automatic indentation
and/or folding.

This whole indentation-count idea is dumb.

-austin

 

[Brian Schröder]

No, no, no, and NO!

When I am writing code, I will often do:

class Foo
def bar
: # some code here
p baz # a tracer to help me find a difficult bug
: # more code here
end
end

Your suggestion would force me to indent the tracer -- which I have
*purposefully* overridden the auto-formatting by vim to insert --
which leads me to the same idiocy that keeps me from Python as a first
point.

Tracer code is too useful to be bound by people who don't use editors
that help them write their code through use of automatic indentation
and/or folding.

This whole indentation-count idea is dumb.

-austin

What are you fearing? No one proposed that the above code should:
1) not work anymore
2) produce warning messages

what was proposed is:
if there is a missing end, produce the message:
"missing a closing end. Your indentation suggests that the missing end
could belong to 'def bar' on line 234."

So I see nobody forcing anything upon you.

No reason to CRY OUT LOUD.

Brian Schröder

 

[Markus]

No, no, no, and NO!

Austin. Pause. Take a deep breath. Let it out slowly. You are
misunderstanding what has been discussed, and what has been
implemented. There is no need for panic.

What people are suggesting is a way to help them find missing
'end's in their code. At present, the error message is not particularly
helpful. It gives no indication of where the problem might be. So what
we have done is prototyped a way to guess where the error might be,
based on common patterns of indentation. That is all.

* It does not enforce, coerce, mandate, or even recommend any
particular indentation style.
* It does not alter the interpretation of any ruby program.
* It does not generate any messages unless the program fails to
parse, and only then in the case where a missing 'end' or '}' is
likely. In that case, all it does is add a list of line numbers
to the message (as warnings) indicating a small number of places
where the error might be.

When I am writing code, I will often do:

class Foo
def bar
: # some code here
p baz # a tracer to help me find a difficult bug
: # more code here
end
end

And you may freely continue to do so. No one is saying otherwise.

Your suggestion would force me to indent the tracer -- which I have
*purposefully* overridden the auto-formatting by vim to insert --
which leads me to the same idiocy that keeps me from Python as a first
point.

There are several interesting points to discuss here, but I fear
to raise them lest I upset you further. Perhaps later, once your main
concerns have been addressed.

Tracer code is too useful to be bound by people who don't use editors
that help them write their code through use of automatic indentation
and/or folding.

If you are using automation tools to help you write code presumably
you have other, better ways of localizing missing 'end's. So you would
never even see the warnings. If you (or others who code like you) would
like the messages to be helpful to them as well, I suspect there may be
a simple heuristic or two that would handle it. The indentation-reader
uses a _very_ loose definition of salience already, to accommodate the
wide range of styles found in the code I looked at.

This whole indentation-count idea is dumb.

I agree that the idea you are reacting to may be is dumb, or at
least ill advised in this context. But that is not the idea under
discussion. If possible, I would be interested in hearing your thoughts
on the actual idea, which is laid out here:

http://blade.nagaokaut.ac.jp/ruby/ruby-core/3486

(including a link to my first attempt at implementing such as system).

-- Markus

 

[Hal Fulton]

No, no, no, and NO!

Are you still ticked off after your system crash?

[snip re tracers etc.]

This whole indentation-count idea is dumb.

I sympathize with both sides. Like you, I "flush left" my debug lines
(fighting vim to do so, and hating the idea of coding without being
able to do such).

I typically don't leave those in long, however. YMMV.

But the whole discussion here has nothing to do with enforcing a
coding style -- it's just a heuristic that would be invoked ONLY in
the case of a missing closing delimiter, and I hope ONLY when a
high level of warnings were turned on.

And by the way, an extra line of code or two could probably allow the
insertion of rogue left-justified lines. But that's beside the point.

The only goal discussed here afaik is: How could we get an error message
like:

Probable missing 'end' line 123

instead of:

Syntax error line 896

at end of file, hundreds of lines away from the error.


Hal

 

[Austin Ziegler]

Are you still ticked off after your system crash?

I'm annoyed that I haven't been able to do any Ruby coding for the
last week But I'm also finding these "let's change Ruby into
something else" discussions rather annoying with some of the proposed
directions.

1) Ranges: I have used the fact of 1...2 including 1.99 but not 2.0 in
the past. I don't think that this is something I want to change. I
would like to be able to have mutable ranges (including the ability to
make a range exclusive or inclusive after creation), but I think that
the syntax for ranges is right and consistent for 98% of all users of
Ruby.
2) Operators: I want += to be still automatically defined when I
define +. I agree with Matz about user precedence, although I think
that having a couple of fixed precedence values (instead of one) is
acceptable, to allow for things like := having a reasonably high
precedence.
3) This. I don't think that what has been suggested will be all that
useful. I have encountered a few of these missing "end" issues, and
with the folding that is in the vim-ruby package offered by the
community, I have rarely found that it takes me longer than five
minutes to fix this issue.

I sympathize with both sides. Like you, I "flush left" my debug lines
(fighting vim to do so, and hating the idea of coding without being
able to do such).

I typically don't leave those in long, however. YMMV.

Me, either.

I think that there are possibilities here, though, now that it's been
explained that this is something to show up only in an error
condition.

-austin

 

[David A. Black]

Hi --

I'm annoyed that I haven't been able to do any Ruby coding for the
last week But I'm also finding these "let's change Ruby into
something else" discussions rather annoying with some of the proposed
directions.

1) Ranges: I have used the fact of 1...2 including 1.99 but not 2.0 in
the past. I don't think that this is something I want to change. I
would like to be able to have mutable ranges (including the ability to
make a range exclusive or inclusive after creation), but I think that
the syntax for ranges is right and consistent for 98% of all users of
Ruby.

With all the recent talk about ranges (much, but not all, of which
I've read), I've been trying to put my finger on why I find the idea
of a mutable Range sort of paradoxical. I'm far from having any kind
of sound theoretical grounding or rationale... but anyway:

I think of a range as kind of a fact. For example: (0..10) is "the
fact of being between 0 and 10, inclusive". In which case, changing
*that fact* -- e.g., having "the fact of being between 0 and 10"
*itself* become "the fact of being between 6 and 12" -- makes no
sense. I guess I think of ranges almost more like numbers; it would
make sense to me if (0..10) were literally the same object everywhere
it appeared.

Anyway, all very speculative, but kind of interesting (to me at least



David

 

[trans. (T. Onoma)]

On Monday 11 October 2004 09:32 pm, David A. Black wrote:
| With all the recent talk about ranges (much, but not all, of which
| I've read), I've been trying to put my finger on why I find the idea
| of a mutable Range sort of paradoxical. I'm far from having any kind
| of sound theoretical grounding or rationale... but anyway:
|
| I think of a range as kind of a fact. For example: (0..10) is "the
| fact of being between 0 and 10, inclusive". In which case, changing
| *that fact* -- e.g., having "the fact of being between 0 and 10"
| *itself* become "the fact of being between 6 and 12" -- makes no
| sense. I guess I think of ranges almost more like numbers; it would
| make sense to me if (0..10) were literally the same object everywhere
| it appeared.
|
| Anyway, all very speculative, but kind of interesting (to me at least

I've been in the trenches with Ranges for the last couple of days. I didn't
grasp the above fact on my own, but when you brought it up originally it made
instant sense to me. An Interval (what Ruby calls a Range) is defined solely
by its sentinels and their exclusivity. So 0..10 is always the same 0..10,
just as 10 is always the same 10. It's a Multiton --a Singleton based on
multiple parameters.

T.

 

[Gavin Sinclair]

With all the recent talk about ranges (much, but not all, of which
I've read), I've been trying to put my finger on why I find the idea
of a mutable Range sort of paradoxical. I'm far from having any kind
of sound theoretical grounding or rationale... but anyway:

I think of a range as kind of a fact. For example: (0..10) is "the
fact of being between 0 and 10, inclusive". In which case, changing
*that fact* -- e.g., having "the fact of being between 0 and 10"
*itself* become "the fact of being between 6 and 12" -- makes no
sense. I guess I think of ranges almost more like numbers; it would
make sense to me if (0..10) were literally the same object everywhere
it appeared.

I agree, David, FWIW, but one doesn't even need to go that far in
justifying immutability. Many things are "value objects" by design
choice. A Name object, for instance: first, middle, last. If you're
working with a system that uses Name objects, they're likely to be
immutable by design. A customer changes their name? Create a new
object.

Some things are best treated "just like a number". Ranges are one of
them (they're just two numbers and a flag, after all). Some say
strings should be immutable as well, and I think it's a justifiable
position.

Gavin

 

[Gavin Sinclair]

So 0..10 is always the same 0..10, just as 10 is always the same 10.
It's a Multiton --a Singleton based on multiple parameters.

Not literally the same object, though. (At least I doubt it.)

Gavin