quality of error messages

[Mikael Brockman]

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)

...

 

[Markus]

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.

I'm not sure I understand your point; could you provide an example
of how this might happen? Specifically, how code that did not attempt
to modify something would be affected if it became, in theory, possible
to modify it. Or am I misunderstanding?

-- Markus

 

[gabriele renzi]

Alexander Kellett ha scritto:

i can't imagine many cases where its less performant in fact.

well, given my little usage of java and python, it seem that everywhere
you use string composition (even simple sum), they tell you to use a
StringBuffer/StringIO or something that is, in fact, a mutable string

 

[gabriele renzi]

Robert Klemme ha scritto:

Unfortunately they didn't provide a unsynchronized
StringBuffer though...

I think in 1.5 they addressed this with StringBuilder, but I may be
remembering it wrong

 

[Robert Klemme]

I'm not sure I understand your point; could you provide an example
of how this might happen? Specifically, how code that did not attempt
to modify something would be affected if it became, in theory, possible
to modify it. Or am I misunderstanding?

class Demo < Struct.newrange)
def show
range.each {|val| puts val}
end
end

r = 1..10
d = Demo.new r
d.show
# modify r in place
d.show

In this scenario the second "d.show" will unexpectedly print something
else if r could be modified in place.

Kind regards

robert

 

[Randy W. Sims]

Hi!

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

In any mailing-list you can look at the full headers for any message for
this info:

...
List-Id: ruby-talk.ruby-lang.org
List-Software: fml [fml 4.0.3 release (20011202/4.0.3)]
List-Post: <mailto:[email protected]>
List-Owner: <mailto:[email protected]>
List-Help: <mailto:[email protected]?body=help>
List-Unsubscribe: <mailto:[email protected]?body=unsubscribe>
...

 

[Markus]

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

The odd thing is, all you are generally getting with them is a bit
of syntactic sugar. Consider the relationship between:

s = gsub(p,v)
s.gsub!(p,v)

i = i + k
i += k

Unless you have lent a friend a reference to s and are using it to send
secret messages, you aren't really depending on the mutability of
strings so much as the modifability of variables.

-- Markus

 

[Austin Ziegler]

The odd thing is, all you are generally getting with them is a bit
of syntactic sugar. Consider the relationship between:

s = gsub(p,v)
s.gsub!(p,v)

i = i + k
i += k

Unless you have lent a friend a reference to s and are using it to send
secret messages, you aren't really depending on the mutability of
strings so much as the modifability of variables.

The two aren't equivalent. In fact, the following holds true in Ruby:

def gsub(search, replace)
self.dup.gsub!(search, replace)
end

So String#gsub! isn't at all equivalent to i += k, because:

s = t = "foo"
s.gsub!(/$/, "t") # => "foot"
puts t # => "foot"

I know that I use String#<< quite a bit, which means that nearly
everything that I do depends on the mutability of Strings. (Well, to
be more accurate, I use #<< quite a bit, and assume that it will Do
The Right Thing, which means that I depend on the mutability of
Strings).

-austin

 

[Markus]

class Demo < Struct.newrange)
def show
range.each {|val| puts val}
end
end

r = 1..10
d = Demo.new r
d.show
# modify r in place
d.show

In this scenario the second "d.show" will unexpectedly print something
else if r could be modified in place.

But the point is, if the code _does_not_ attempt to modify the
range now, it won't magically realize if ranges became mutable and
suddenly start modifying them.

Yes, if ranges were to become mutable (and note, I am NOT arguing
that they should) it would permit a new class of bugs to be written.
But it wouldn't break existing, functional code. You may be correct,
that the example you gave was a serious problem, but then I would expect
you to argue that strings should be immutable too. And arrays. And
hashes. And then we wouldn't be talking about ruby any more.

-- Markus

 

[Markus]

The two aren't equivalent. In fact, the following holds true in Ruby:

def gsub(search, replace)
self.dup.gsub!(search, replace)
end

So String#gsub! isn't at all equivalent to i += k, because:

s = t = "foo"
s.gsub!(/$/, "t") # => "foot"
puts t # => "foot"

That's exactly what I meant by the phrase "Unless you have lent a
friend a reference to s and are using it to send secret messages" -- t,
in this case, being s's friend. My point was that:

s = t = "foo"

isn't all that common. It's as likely when it does happen that the user
(especially the nuby) is expecting it to behave like "s = (t =
"foo").dup -- in other words, the whole reason they are assigning to
both s and t is so that they will have "two copies" of the string.

I know that I use String#<< quite a bit, which means that nearly
everything that I do depends on the mutability of Strings. (Well, to
be more accurate, I use #<< quite a bit, and assume that it will Do
The Right Thing, which means that I depend on the mutability of
Strings).

Sure. For that matter, I do as well.

*smile* So are you wanting Integer to be mutable too?

-- Markus (a.k.a. "the devils advocate")

 

[Robert Klemme]

But the point is, if the code _does_not_ attempt to modify the
range now, it won't magically realize if ranges became mutable and
suddenly start modifying them.

Yes, if ranges were to become mutable (and note, I am NOT arguing
that they should) it would permit a new class of bugs to be written.
But it wouldn't break existing, functional code.

That's not true: Assume class Demo sits in some kind of lib. Demo need
not be modified to be broken. It's sufficient that Demo was written
relying on the immutability of Range. Now after Ranges have come mutable,
someone writes code that uses Demo in the way I presented above and
suddenly breaks Demo. Of course you *could* distribute a new version of
the lib, but considering the latency between that and the point in time
where people do in fact update their copy there's much room for bugs.
Also, since Range is such a basic class, efforts to harden all libs that
use it against newly introduced mutability would quite high.

You may be correct,
that the example you gave was a serious problem, but then I would expect
you to argue that strings should be immutable too. And arrays. And
hashes.

Nope, You can freeze Strings, Arrays and Hashes which is a good compromize
between performance and immutability IMHO. I regard it better suited to
Ruby as C's "const", which is quite a complex beast and makes it difficult
to get right.

And then we wouldn't be talking about ruby any more.

Maybe, maybe not.

Kind regards

robert

 

[Robert Klemme]

The odd thing is, all you are generally getting with them is a bit
of syntactic sugar. Consider the relationship between:

s = gsub(p,v)
s.gsub!(p,v)

i = i + k
i += k

It's not only sugar. It's different semantics and different performance
(see the other post with the benchmark). There are enough circumstances
where you don't know whether someone else still holds a reference to an
instance at hand. As an example, that's the reason why Strings when used
as Hash keys are duped and frozen if they are not yet frozen.

Kind regards

robert

 

[Markus]

It's not only sugar. It's different semantics and different performance
(see the other post with the benchmark). There are enough circumstances
where you don't know whether someone else still holds a reference to an
instance at hand. As an example, that's the reason why Strings when used
as Hash keys are duped and frozen if they are not yet frozen.

Kind regards

robert

In your previous response to this same post you at least included
the rest of my statement:

Unless you have lent a friend a reference to s and are using it to
send secret messages, you aren't really depending on the mutability
of strings so much as the modifability of variables.

In my response I further clarified my point, that most users of
gusb! use it not because they want the modification to affect some other
reference to the same string, but simply as a shorthand. Instead of
trying yet again, to clarify a point that we both obviously understand,
I will address a more interesting point:

Why do you keep taking my remarks out of context to "rebut" them?

-- Markus

 

[Charles Hixson]

Hi --

...

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

I tend to think of ranges being rather like the bounds on a definite
integral (not that I ever liked those...).
Someone else anaogized them to a bounded arithmetic series (quite
reasonable). There's all the theory you could want, if you just pick the
right analogy. (An arithmetic series wouldn't include the space between
the members, and integral would...but both of those include the end-point.)

Personally I feel that an arithmetic series representation would be the
best analogy (i.e., the most useful one), and that there are good
practical grounds for NOT including the end point (index 0 is the 1st
element of an array...so a range of 0..length is quite useful, provided
the end point isn't included). But if it's an arithmetic series then
the spaces between the points shouldn't be considered to be a part of
the series. OTOH, it's just a LOT easier to check if 0 <= i < length
than it is to compare for each member, and the main use is as array
indicies, which are integer.

I think the built-in parts of the language need to work together
smoothly, and the current range does that properly and efficiently.
Intervals (i.e., ranges with a constant increment of non-unity) would be
an occasionally useful extension that would assist in working with
n-dimensioned arrays (not matricies). The more generalized forms should
be defined in (library?) classes. (Should Ruby come with "batteries
included"? The decision seems to be no, use ruby-gems or the rpa. That
works for me. But they should also be available on CD for those without
an internet connection. A large tarball would suffice, so that you'd
just need to find someone who HAD an internet connection and a CD burner.)

 

[trans. (T. Onoma)]

On Wednesday 13 October 2004 03:46 pm, Charles Hixson wrote:
| I think the built-in parts of the language need to work together
| smoothly, and the current range does that properly and efficiently.  

But in fact, much of the discussion has been about how Range behavior is NOT
"proper" nor efficient.

T.

 

[Austin Ziegler]

On Wednesday 13 October 2004 03:46 pm, Charles Hixson wrote:
| I think the built-in parts of the language need to work together
| smoothly, and the current range does that properly and efficiently.
But in fact, much of the discussion has been about how Range behavior is NOT
"proper" nor efficient.

And I, for one, disagree with people who say that Range behaviour is wrong.

I use both the discrete and continuous behaviours of Ranges. I use
both the inclusive and exclusive forms of Ranges. Never in the same
context, but Matz has suggested that is not likely to be enough reason
to have separate classes (I count four: ContinuousInclusiveRange,
ContinuousExclusiveRange, DiscreteInclusiveRange,
DiscreteExclusiveRange).

I find absolutely nothing surprising about the current behaviour of
ranges: they act both continuous and discrete, depending on how you
use them. There are a couple of issues: it is not possible to do:

(0..5).step(0.25)
(0...5).step(0.25)

This would make it possible to deal with non-integer discrete ranges.
Is *that* worth doing, perhaps? I think so.

It doesn't, however, mean that Ranges are fundamentally broken.

-austin

 

[trans. (T. Onoma)]

00:46 +0900, trans. (T. Onoma)
|
| > On Wednesday 13 October 2004 03:46 pm, Charles Hixson wrote:
| > | I think the built-in parts of the language need to work together
| > | smoothly, and the current range does that properly and efficiently.
| >
| > But in fact, much of the discussion has been about how Range behavior is
| > NOT "proper" nor efficient.
|
| And I, for one, disagree with people who say that Range behaviour is wrong.

"wrong" is relative. Obviously Range is very usable _as is_. That doesn't mean
there is nothing wrong with it.

- #member? is *very* slow
- #member? can cause infinite loop
- #include? != #member? (so not exactly Enumerable)
- can't use case statement as membership check, one inclusion check
- #irregular optimization of Numerics, so it doesn't always
behave consistently (try creating an even integer class)
- Does not offer exclude_begin

This is off the top of my head. I'm sure we've covered a few others, too.

| [snip]
|
| I find absolutely nothing surprising about the current behaviour of
| ranges: they act both continuous and discrete, depending on how you
| use them. There are a couple of issues: it is not possible to do:
|
| (0..5).step(0.25)
| (0...5).step(0.25)
|
| This would make it possible to deal with non-integer discrete ranges.
| Is *that* worth doing, perhaps? I think so.

In fact, my modified Range class does this handedly using #each, as well as
dividing the range up into any equal divisions, also using #each --so all
Enumerable methods work with it, as well as #to_a.

| It doesn't, however, mean that Ranges are fundamentally broken.

No one ever said that. We've simply been exploring how Range might be made
more consitant, useful and efficient.

T.

 

[Robert Klemme]

In your previous response to this same post you at least included
the rest of my statement:


In my response I further clarified my point, that most users of
gusb! use it not because they want the modification to affect some other
reference to the same string, but simply as a shorthand. Instead of
trying yet again, to clarify a point that we both obviously understand,
I will address a more interesting point:

Why do you keep taking my remarks out of context to "rebut" them?

-- Markus

I don't consider the difference between "s.gsub!(...)" and "s =
s.gsub(...)" syntactic sugar - even in cases where one thinks or knows
that the reference was not leaked. So although some bit of context was
missing there was no distortion since I disagree with the syntactic sugar
thesis for *all* cases.

Sadly enough, I get the feeling we're talking across each other. I regret
that.

robert

 

[Markus]

I don't consider the difference between "s.gsub!(...)" and "s =
s.gsub(...)" syntactic sugar - even in cases where one thinks or knows
that the reference was not leaked. So although some bit of context was
missing there was no distortion since I disagree with the syntactic sugar
thesis for *all* cases.

Sadly enough, I get the feeling we're talking across each other. I regret
that.

So do I. I'm willing to try to correct the problem if you are.

I did not saying that "it is only syntactic sugar" and certainly
not "for *all* cases" which seems to be the point with which you are
disagreeing.

I said that, in most cases "all the programmer was getting out of
it" was syntactic sugar*; in other words, that although there are
semantic differences most of the code written using gsub! (note: "most",
not "all") does not rely on them.

It was a minor point, perhaps, but I thought it was interesting in
the (now long lost) original context.

-- Markus


* And, as I previously conceded, some performance advantage--though I
still maintain that distinguishing two forms that are semantically
equivalent for your purposes based on presumed/measured performance
differences is not wise in the long run.