quality of error messages

[Yukihiro Matsumoto]

Hi,

In message "Re: Ruby Directions (was Re: quality of error messages)"

|> 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.)

As much as float zero objects (0.0) are not literally the same object.

matz.

 

[trans. (T. Onoma)]

15:46 PM, trans. wrote:
| > 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.)

They will be when I'm through with them

My lib has really turned out quite nice. I'll share it soon. I still have a
few more methods to write --unfortunately I have to rewrite every Enumerable
method just b/c my new #each method takes an argument

T.

 

[trans. (T. Onoma)]

On Monday 11 October 2004 10:35 pm, Yukihiro Matsumoto wrote:
| Hi,
|
| In message "Re: Ruby Directions (was Re: quality of error messages)"
|
| on Tue, 12 Oct 2004 11:29:59 +0900, 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.)
|
| As much as float zero objects (0.0) are not literally the same object.

Does this somehow necessitate that they could not be?

T.

 

[Markus]

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.

For what it's worth, I agree. The original impetus for the "free
form operator patch" was an attempt to find a way to let people who
wanted things to work "their way" to be able to do so without relegating
them to a syntactic ghetto, in the hopes that this would reduce the
pressure for semantic changes in the core classes. I am presently
supporting over 20,000 lines of ruby code, and changes in the core
classes can be...time consuming.

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.

I wonder: would you find the "free form operator" idea more
palatable if it were not quite so "free form". For example, if there
was some sort of rule imposed on user defined operators like:

Any operator "___" not ending in '=' automatically defines a
companion assignment operator "__=" such that "x __= y" means "x
= x __ y"?

There might have to be tweaking of this rule, or codicils, to
assure consistency and backwards compatibility. But my real question
is, in general, would more structure please you? (And again, this is
all hypothetical--I am more interested in learning your thoughts than in
trying to sell you a feature you do not want.)

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.


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.

I will try and make it more useful; do you by any chance have a
feeling of how/when you write flush-left code? I am already ignoring
comment lines, since many people write them flush left. Do you
generally only do one line this way? Are they generally print/puts/p
statements?

In other words, is there anything that could be simply detected
(because I would like the code to remain small, fast, and simple) that
would let me detect what you do as "normal" and not consider it for
mention in the diagnostic message?

-- Markus

 

[Randy W. Sims]

I will try and make it more useful; do you by any chance have a
feeling of how/when you write flush-left code? I am already ignoring
comment lines, since many people write them flush left. Do you
generally only do one line this way? Are they generally print/puts/p
statements?

In other words, is there anything that could be simply detected
(because I would like the code to remain small, fast, and simple) that
would let me detect what you do as "normal" and not consider it for
mention in the diagnostic message?

I do this also. Basically, anything not an end marker that is _flush_
left can be ignored for the purpose of "finding the end".

Randy.

PS: I still like the other idea (end [(module|class|def) [<NAME>]])
better. =)

 

[Markus]

I do this also. Basically, anything not an end marker that is _flush_
left can be ignored for the purpose of "finding the end".

Sounds reasonable at first glance. Thanks.

PS: I still like the other idea (end [(module|class|def) [<NAME>]])
better. =)

I have not been able to assure myself that this could be done
without breaking anything (or at least, be done by me). I can see how
to do it, but I am just rusty enough on the guts of LR(1)/LALR(1)
parsers to be uneasy with the potential for conflicts.

Would you like me to pursue the idea? (With the caveat that my
experiments are for our enlightenment, and not meant to be
shaping/forcing ruby's development in any way that it does not wish to
go.)

-- Markus

 

[Hal Fulton]

PS: I still like the other idea (end [(module|class|def) [<NAME>]])
better. =)

I have not been able to assure myself that this could be done
without breaking anything (or at least, be done by me). I can see how
to do it, but I am just rusty enough on the guts of LR(1)/LALR(1)
parsers to be uneasy with the potential for conflicts.

Would you like me to pursue the idea? (With the caveat that my
experiments are for our enlightenment, and not meant to be
shaping/forcing ruby's development in any way that it does not wish to
go.)

I believe this would be a step into history. IIRC Ruby used to have such
end markers (before the 'if' modifier and such were added).

Of course, sometimes a return to former practices is good... but there
might be syntax complications.


Hal

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Ruby Directions (was Re: quality of error messages)"

|| |Not literally the same object, though. (At least I doubt it.)
||
|| As much as float zero objects (0.0) are not literally the same object.
|
|Does this somehow necessitate that they could not be?

I meant being different object should be no problem to be immutable
values.

matz.

 

[Mark Hubbart]

No, no, no, and NO!
Yikes!

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.

Well, no, it wouldn't. In my original suggestion:
1. it was only a warning; you wouldn't be *forced* to comply with it.
2. the warning would be at a more highly defined warning level: level
3, which currently doesn't exist. So the warning would never show up
unless you run your code at that warning level.
3. I didn't directly specify this, but I intended that it would only
check indentation levels for block ends. So that puts statement would
be ignored even still.

I would shrink in horror at the thought of supporting a change that
would enforce indentation standards on other rubyists. I violate mine
often enough myself, whenever I feel that it makes my code more
readable.

Regardless, I realize now that the exact thing I proposed would not be
the best way of doing it. I described what was in my mind at the time,
knowing full well that there was likely something wrong with the idea.
I am quite interested in the much more mature ideas that I've seen
later on in this thread.

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.

Well, I guess that we will all have different opinions on this, but I
find myself tracking down "missing end" bugs often enough that I kinda
like the idea. As long as it only complains when there's a missing end


cheers,
Mark

 

[Robert Klemme]

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.

Regardless of whether Ranges should rather be immutable or not, I plead
for sticking with the current immutability. The reason is simply that a
change of mutability of a class is a major change, which is likely to
break a lot of code. Everybody that relied on a Range being immutable and
thus stored an instance as member of his own classes might recognize the
range suddenly changed when it's no longer immutable.

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.

Personally I prefer the approach Matz has taken with Ruby strings because
of my experience with Java strings. It can be a major performance
drawback if you have to create a new string for every change that you do
to a string (yes, I know there is StringBuffer, but too many methods just
return a String); and in some cases your memory might not even suffice.

My 0.02 EUR...

Kind regards

robert

 

[Randy W. Sims]

PS: I still like the other idea (end [(module|class|def) [<NAME>]])
better. =)

I have not been able to assure myself that this could be done
without breaking anything (or at least, be done by me). I can see how
to do it, but I am just rusty enough on the guts of LR(1)/LALR(1)
parsers to be uneasy with the potential for conflicts.

Would you like me to pursue the idea? (With the caveat that my
experiments are for our enlightenment, and not meant to be
shaping/forcing ruby's development in any way that it does not wish to
go.)

Yeah. I'm toying around, taking a brief look at parse.y. I know a lot of
the theory of lexing/parsing. I've hand crafted small itsy-bitsy toy
lexer/parsers. But I'm mostly ignorant of what I'm looking at here.

I was thinking, focusing soley on class defs for the moment, that at the
start of a class definition it should be possible to store the class
name (cname?). Then at the close accept a optional 'class' keyword
following end, and then an optional identifier which must match the
stored cname. But I have no idea how to implement that at the moment.

I guess I should be reading the bison manual...

Randy.

 

[Gavin Sinclair]

Personally I prefer the approach Matz has taken with Ruby strings because
of my experience with Java strings. It can be a major performance
drawback if you have to create a new string for every change that you do
to a string (yes, I know there is StringBuffer, but too many methods just
return a String); and in some cases your memory might not even suffice.

I'm not weighing in here, but I think the purpose of Java's immutable
strings was to somehow improve performance. The gutlessness of Java's
string library compared with Ruby's is bound to change the equation,
though.

Perhaps there are some uses of strings for which immutability makes
performance sense, and some uses for which it doesn't. I couldn't be
bothered thinking about it

Considering the occasional usage of value objects, I can see why
immutable strings would be conceptually nice (sometimes). I also
think tuples (essentially arrays that are fixed on creation) would be
nice to have in the language, for the same reason. Neither is a big
deal, though.

Cheers,
Gavin

 

[Alexander Kellett]

Perhaps there are some uses of strings for which immutability makes
performance sense, and some uses for which it doesn't. I couldn't be
bothered thinking about it

i can't imagine many cases where its less performant in fact.
immutable strings with cow are obviously far faster for copying
than mutable strings and as with most systems its the copy /
construction of strings rather than the iteration that takes
the time i'd say its logical that they should be immutable.
(if you look at the most common c/c++ programs (excepting apps
using trolltech's qt which solves the problem fairly neatly)
you'll see that strcpy and memory allocation take up a huge
chunk of execution time)

still... for coding, i love slice! / gsub! etc. they are
amazingly useful constructs. i can't imagine living without
them

mvg,
Alex

 

[Robert Klemme]

i can't imagine many cases where its less performant in fact.
immutable strings with cow are obviously far faster for copying
than mutable strings

First of all you can have mutable strings with cow, too. In fact, Ruby
Strings do just that. And if they do, mutable Strings are better
performance wise if you want to do inplace modification. Consider

s = s.gsub(/x/, 'u')

vs.

s.gsub!(/x/, 'u')

The first is slower because of the new String instance:

15:58:47 [ruby]: ruby stringperf.rb
user system total real
gsub! 3.282000 0.000000 3.282000 ( 3.322000)
gsub 3.343000 0.000000 3.343000 ( 3.329000)
15:58:56 [ruby]: cat stringperf.rb
require 'benchmark'
include Benchmark

N = 10000
sample = ("foulx" * 100).freeze

bm(20) do |b|
b.report("gsub!") do
N.times do
s = sample.dup
s.gsub!(/x/, 'u')
end
end

b.report("gsub") do
N.times do
s = sample.dup
s = s.gsub(/x/, 'u')
end
end
end

and as with most systems its the copy /
construction of strings rather than the iteration that takes
the time i'd say its logical that they should be immutable.

As I said, this totally depends on the use case. There are pros and cons
to both.

(if you look at the most common c/c++ programs (excepting apps
using trolltech's qt which solves the problem fairly neatly)
you'll see that strcpy and memory allocation take up a huge
chunk of execution time)

still... for coding, i love slice! / gsub! etc. they are
amazingly useful constructs. i can't imagine living without
them

You see?

Kind regards

robert

 

[Curt Hibbs]

i can't imagine many cases where its less performant in fact.
immutable strings with cow are obviously far faster for copying
than mutable strings and as with most systems its the copy /
construction of strings rather than the iteration that takes
the time i'd say its logical that they should be immutable.

Many years ago I attended a Java User's Group meeting in San Francisco where
the speaker was Mr. Java -- James Gosling, himself. This was back when the
JUG only attracted about 20 people, so it was a very intimate encounter.

During this meeting, James directly addressed the issue of immutable
strings. The true story is that the original Java had mutable strings.
However, the java integration with the netscape browser had an obscure bug
in string handling. They were unable to solve the problem before the
shipping deadline, and ended up "solving" it by making strings immutable.
James finally stated that it was (at that time) the one decision that he
most regretted.

Curt

 

[Edgardo Hames]

Personally I prefer the approach Matz has taken with Ruby strings because
of my experience with Java strings. It can be a major performance
drawback if you have to create a new string for every change that you do
to a string (yes, I know there is StringBuffer, but too many methods just
return a String); and in some cases your memory might not even suffice.

I found this article which debunks some myths about Java performance.
Urban performance legend #3: Immutable objects are bad for performance

http://www-128.ibm.com/developerworks/java/library/j-jtp04223.html?ca=dgr-lnxw07-obg-JavaMyths

Kind Regards,
Ed

 

[Robert Klemme]

Many years ago I attended a Java User's Group meeting in San Francisco where
the speaker was Mr. Java -- James Gosling, himself. This was back when the
JUG only attracted about 20 people, so it was a very intimate encounter.

During this meeting, James directly addressed the issue of immutable
strings. The true story is that the original Java had mutable strings.
However, the java integration with the netscape browser had an obscure bug
in string handling. They were unable to solve the problem before the
shipping deadline, and ended up "solving" it by making strings immutable.
James finally stated that it was (at that time) the one decision that he
most regretted.

Oha... Sounds a bit like an urban legend (aka, folklore), but as it seems
to come straight from the source, it has a certain amount of credibility.
To add to this: they made all StringBuffer methods synchronized which
makes you pay the sync overhead all the time without necessity. They did
the same to Vector and Hashable, but there they got wiser with ArrayList
and HashMap. Unfortunately they didn't provide a unsynchronized
StringBuffer though...

Regards

robert

 

[Robert Klemme]

I found this article which debunks some myths about Java performance.
Urban performance legend #3: Immutable objects are bad for performance

http://www-128.ibm.com/developerworks/java/library/j-jtp04223.html?ca=dgr-lnxw07-obg-JavaMyths

Well, Brian debunks the myth that immutables are *always* bad for
performance. But he clearly states that it depends on the application at
hand. You can believe me that I did quite some benchmarking and there are
really cases where immutables are bad for performance. And those cases
are by far not esoteric.

Kind regards

robert

 

[Linus Holmlund Hotmail]

Hi!

I am just wondering how I can unsubscribe from this list, since I want to
use another mail address.

/Linus

 

[Markus]

PS: I still like the other idea (end [(module|class|def) [<NAME>]])
better. =)

I have not been able to assure myself that this could be done
without breaking anything (or at least, be done by me). I can see how
to do it, but I am just rusty enough on the guts of LR(1)/LALR(1)
parsers to be uneasy with the potential for conflicts.

Would you like me to pursue the idea? (With the caveat that my
experiments are for our enlightenment, and not meant to be
shaping/forcing ruby's development in any way that it does not wish to
go.)

Yeah. I'm toying around, taking a brief look at parse.y. I know a lot of
the theory of lexing/parsing. I've hand crafted small itsy-bitsy toy
lexer/parsers. But I'm mostly ignorant of what I'm looking at here.

I was thinking, focusing soley on class defs for the moment, that at the
start of a class definition it should be possible to store the class
name (cname?). Then at the close accept a optional 'class' keyword
following end, and then an optional identifier which must match the
stored cname. But I have no idea how to implement that at the moment.

I guess I should be reading the bison manual...

I realized in my sleep (yes, I literally do program in my sleep)
that the reason I wasn't able to prove from the grammar that the
original for of this feature would not conflict was that the assumption
was false. It would conflict. Specifically (from my dream, but
identifiers changed to protect my subconscious):

class Flork
def self.blork
#computation to return true
#if and only if subclass needs
#to respond to :blork
end
end

class Florkette << Flork
def blork
#code to blork a Florkette
end if
blork
end

is legitimate code that directly conflicts with the proposed syntax.
There are several ways to do this.

You could (as was proposed later on the thread) restrict the
tagging to named entities, but I haven't been able to work out that that
is conflict free either.

-- Markus

P.S. "info Bison" has some GNU-clear examples. You don't need to retain
too much external information, since the parse tree of a reasonable
grammar will have most of the parse tree nodes available near where you
need them.

Specifically, you can find the name of a class or function in the
grammar rule (probably something like $2.id) (IIRC, YMMV).