- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Collection changes
Sun, 2009-10-18, 13:01
I committed a new collection library to trunk which implements the
proposed changes to Range and filter.
It was very easy to do and did not break any of our code, so I
fasttracked the commit. If you try it out and have problems with it,
please let me know!
Another minor change that was done previously was to rename the
destructive prepend methods on buffers from +: and ++: to +=: and
++=:, keeping with the scheme that destructive symbolic operations are
marked with an equals sign.
The old method forms are kept as deprecated.
Thereare two more renamings I still intend to do:
1. BuilderFactory will be renamed to CanTransform (with some
permutation of its type parameters), in order to be friendler to error
messages.
2. Vector in all its forms will be renamed to IndexedSeq. This frees
up the name Vector for an optimized Vector implementation. We believe
this has the potential to give better performance for these vectors,
as the VM would have more precise type info for them.
These renamings need no deprecation as they only affect constructs
that are new in 2.8.
Cheers
Mon, 2009-10-19, 08:27
#2
Re: Collection changes
On Sun, Oct 18, 2009 at 9:59 PM, Paul Phillips wrote:
> On Sun, Oct 18, 2009 at 01:19:12PM +0200, martin odersky wrote:
>> I committed a new collection library to trunk which implements the
>> proposed changes to Range and filter. It was very easy to do and did
>> not break any of our code, so I fasttracked the commit. If you try it
>> out and have problems with it, please let me know!
>
> As long as we're messing with filter, can you comment on:
>
> http://lampsvn.epfl.ch/trac/scala/ticket/1336
> "filter incorrectly optimized away"
>
> You can see my assessment in there (twice unfortunately thanks to an
> overly rememberful browser and overly absent-minded browser operator).
> Do you agree that this should compile without a filter method defined,
> and if so, do you have a thought on the best way to address that. I'm
> of the opinion this is another case of the parser working too hard to
> the detriment of what can be done in later phases -- in other words that
> inserting nme.CHECK_IF_REFUTABLE_STRING is not likely to be the most
> robust approach.
>
Yes, you are right. The current approach is something of a can of
worms, but it is a major undertaking to change it. We can't do for
expression expansion after type checking, because type checking relies
on expansion. The only feasible way is probably to do expansion during
type checking, similar to eta expansion. But we'd have to be very
careful not to blow up the type checker even further, it is
complicated enough.
Cheers
On Sun, Oct 18, 2009 at 01:19:12PM +0200, martin odersky wrote:
> I committed a new collection library to trunk which implements the
> proposed changes to Range and filter. It was very easy to do and did
> not break any of our code, so I fasttracked the commit. If you try it
> out and have problems with it, please let me know!
As long as we're messing with filter, can you comment on:
http://lampsvn.epfl.ch/trac/scala/ticket/1336
"filter incorrectly optimized away"
You can see my assessment in there (twice unfortunately thanks to an
overly rememberful browser and overly absent-minded browser operator).
Do you agree that this should compile without a filter method defined,
and if so, do you have a thought on the best way to address that. I'm
of the opinion this is another case of the parser working too hard to
the detriment of what can be done in later phases -- in other words that
inserting nme.CHECK_IF_REFUTABLE_STRING is not likely to be the most
robust approach.