- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Stacks: 2.7.x vs. 2.8
Sun, 2009-06-21, 15:36
Hi,
I noticed just now that indexing (via apply()) on stacks in 2.7 selects
stack elements relative to the bottom of the stack (which, by the way,
forces the stack to be reversed fir each call to apply()) while 2.8
interprets the index passed to apply() as an index relative to the top
of the stack. In my opinion, 2.8's way is superior both in its
interpretation of the apply() index and in terms of the implementation,
which then need not reverse the stack to find n-th element. (Presumably
it is most common when one needs indexed access to a stack, that it is
relative to the top, not the bottom.)
Aside from the fact that I prefer the 2.8 semantics but feel some
trepidation about switching to trunk, I'm wondering how many such
incompatible changes are present in the 2.8 collections?
It's good that in the 2.8 code there's a documentation comment that
makes explicit how it interprets the argument to apply(). (Which is not
the case in the 2.7.5 code where I had to read the source and then
confirm my somewhat astonished understanding with an experiment to find
out how it worked there.) But it makes me wonder how many other
incompatible changes there might be and how much of my 2.7 code will
need to be adjusted when ported to 2.8.
Will there be (/ is there) a detailed list of incompatible changes in
the 2.8 release? Could there be a ScalaDoc marker (akin to @deprecated)
that would alert readers of the ScalaDoc docs to such changes?
Randall Schulz
Sun, 2009-06-21, 17:17
#2
Re: Stacks: 2.7.x vs. 2.8
On Sunday June 21 2009, martin odersky wrote:
> On Sun, Jun 21, 2009 at 4:36 PM, wrote:
> > Hi,
> >
> > I noticed just now that indexing (via apply()) on stacks in 2.7
> > selects stack elements relative to the bottom of the stack (which,
> > by the way, forces the stack to be reversed fir each call to
> > apply()) while 2.8 interprets the index passed to apply() as an
> > index relative to the top of the stack. ...
> >
> > ... I'm wondering how many such incompatible
> > changes are present in the 2.8 collections?
>
> Hopefully not too much. Stacks were utterly broken. I just can't
> believe that anyone based a serious application on them. Bitsets were
> a bit in the same boat. I think those were the two main areas where I
> had to change things in incompatible ways.
OK, that's reassuring. Extrapolating from a sample of one is
ill-advised, of course.
> Cheers
>
Sun, 2009-06-21, 17:27
#3
Re: Stacks: 2.7.x vs. 2.8
On Sun, Jun 21, 2009 at 1:03 PM, martin odersky <martin.odersky@epfl.ch> wrote:
The lib scala.util.automata made use of Bitsets. I wonder if there was any functional impact on it (ie, it broke), or just performance.
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
On Sun, Jun 21, 2009 at 4:36 PM, Randall R Schulz<rschulz@sonic.net> wrote:
> Hi,
>
> I noticed just now that indexing (via apply()) on stacks in 2.7 selects
> stack elements relative to the bottom of the stack (which, by the way,
> forces the stack to be reversed fir each call to apply()) while 2.8
> interprets the index passed to apply() as an index relative to the top
> of the stack. In my opinion, 2.8's way is superior both in its
> interpretation of the apply() index and in terms of the implementation,
> which then need not reverse the stack to find n-th element. (Presumably
> it is most common when one needs indexed access to a stack, that it is
> relative to the top, not the bottom.)
>
> Aside from the fact that I prefer the 2.8 semantics but feel some
> trepidation about switching to trunk, I'm wondering how many such
> incompatible changes are present in the 2.8 collections?
>
Hopefully not too much. Stacks were utterly broken. I just can't
believe that anyone based a serious application on them. Bitsets were
a bit in the same boat. I think those were the two main areas where I
had to change things in incompatible ways.
The lib scala.util.automata made use of Bitsets. I wonder if there was any functional impact on it (ie, it broke), or just performance.
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
Sun, 2009-06-21, 18:57
#4
Re: Stacks: 2.7.x vs. 2.8
On Sun, Jun 21, 2009 at 6:21 PM, Daniel Sobral wrote:
> On Sun, Jun 21, 2009 at 1:03 PM, martin odersky
> wrote:
>>
>> On Sun, Jun 21, 2009 at 4:36 PM, Randall R Schulz
>> wrote:
>> > Hi,
>> >
>> > I noticed just now that indexing (via apply()) on stacks in 2.7 selects
>> > stack elements relative to the bottom of the stack (which, by the way,
>> > forces the stack to be reversed fir each call to apply()) while 2.8
>> > interprets the index passed to apply() as an index relative to the top
>> > of the stack. In my opinion, 2.8's way is superior both in its
>> > interpretation of the apply() index and in terms of the implementation,
>> > which then need not reverse the stack to find n-th element. (Presumably
>> > it is most common when one needs indexed access to a stack, that it is
>> > relative to the top, not the bottom.)
>> >
>> > Aside from the fact that I prefer the 2.8 semantics but feel some
>> > trepidation about switching to trunk, I'm wondering how many such
>> > incompatible changes are present in the 2.8 collections?
>> >
>> Hopefully not too much. Stacks were utterly broken. I just can't
>> believe that anyone based a serious application on them. Bitsets were
>> a bit in the same boat. I think those were the two main areas where I
>> had to change things in incompatible ways.
>
> The lib scala.util.automata made use of Bitsets. I wonder if there was any
> functional impact on it (ie, it broke), or just performance.
>
Did you notice problems wrt to performance or functionality? I did rewrite the
parts of automata that dealt with bitsets. I might have gotten it
wrong, of course, so it would be good to know about any problems you
might have encountered.
Cheers
Sun, 2009-06-21, 23:47
#5
Re: Stacks: 2.7.x vs. 2.8
On Sun, Jun 21, 2009 at 2:42 PM, martin odersky <martin.odersky@epfl.ch> wrote:
I haven't tried the automata stuff in 2.8. I only used in 2.7.3 for an experiment, and I recalled it used Bitsets.
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
On Sun, Jun 21, 2009 at 6:21 PM, Daniel Sobral<dcsobral@gmail.com> wrote:
> On Sun, Jun 21, 2009 at 1:03 PM, martin odersky <martin.odersky@epfl.ch>
> wrote:
>>
>> On Sun, Jun 21, 2009 at 4:36 PM, Randall R Schulz<rschulz@sonic.net>
>> wrote:
>> > Hi,
>> >
>> > I noticed just now that indexing (via apply()) on stacks in 2.7 selects
>> > stack elements relative to the bottom of the stack (which, by the way,
>> > forces the stack to be reversed fir each call to apply()) while 2.8
>> > interprets the index passed to apply() as an index relative to the top
>> > of the stack. In my opinion, 2.8's way is superior both in its
>> > interpretation of the apply() index and in terms of the implementation,
>> > which then need not reverse the stack to find n-th element. (Presumably
>> > it is most common when one needs indexed access to a stack, that it is
>> > relative to the top, not the bottom.)
>> >
>> > Aside from the fact that I prefer the 2.8 semantics but feel some
>> > trepidation about switching to trunk, I'm wondering how many such
>> > incompatible changes are present in the 2.8 collections?
>> >
>> Hopefully not too much. Stacks were utterly broken. I just can't
>> believe that anyone based a serious application on them. Bitsets were
>> a bit in the same boat. I think those were the two main areas where I
>> had to change things in incompatible ways.
>
> The lib scala.util.automata made use of Bitsets. I wonder if there was any
> functional impact on it (ie, it broke), or just performance.
>
Did you notice problems wrt to performance or functionality? I did rewrite the
parts of automata that dealt with bitsets. I might have gotten it
wrong, of course, so it would be good to know about any problems you
might have encountered.
I haven't tried the automata stuff in 2.8. I only used in 2.7.3 for an experiment, and I recalled it used Bitsets.
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
On Sun, Jun 21, 2009 at 4:36 PM, Randall R Schulz wrote:
> Hi,
>
> I noticed just now that indexing (via apply()) on stacks in 2.7 selects
> stack elements relative to the bottom of the stack (which, by the way,
> forces the stack to be reversed fir each call to apply()) while 2.8
> interprets the index passed to apply() as an index relative to the top
> of the stack. In my opinion, 2.8's way is superior both in its
> interpretation of the apply() index and in terms of the implementation,
> which then need not reverse the stack to find n-th element. (Presumably
> it is most common when one needs indexed access to a stack, that it is
> relative to the top, not the bottom.)
>
> Aside from the fact that I prefer the 2.8 semantics but feel some
> trepidation about switching to trunk, I'm wondering how many such
> incompatible changes are present in the 2.8 collections?
>
Hopefully not too much. Stacks were utterly broken. I just can't
believe that anyone based a serious application on them. Bitsets were
a bit in the same boat. I think those were the two main areas where I
had to change things in incompatible ways.
Cheers