- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Scala Meeting report, 2009-10-27
Wed, 2009-10-28, 19:18
We are currently publishing, as an experiment, a summary of each of the
weekly meetings of the Scala Core Team.
This information is made available as a service to the community. It is by
necessity rather brief and gives only a rough approximation of the main
points of discussions explored during each meeting; it should not be taken
as a source of reliable information, nor as a record of concrete or firm
decisions, nor as anything other than a record of a simple discussion.
The summary that follows is primarily intended for Scala contributors and
maintainers. If you are not a contributor to the Scala system, the
information below is unlikely to be very useful to you, and you might lack
some of the necessary background to make sense of all the discussion items.
We do not have enough people on the team to be able to write a more
complete record, and we might also not have the resources to discuss every
point in detail afterwards. Nevertheless, we hope that this record, cursory
as it is, is better than nothing.
------------------------------------------------------------------------------
Report from the Scala Core Team meeting, 2009-10-27:
People attending the meeting: Martin, Iulian, Philipp, Alex, Phil, Hubert,
Eugene, Tiark, Lukas, Adriaan, Gilles.
Topics discussed:
* Current work:
- Progress on Parallel Arrays
- More work on Vectors and other collections
- Fixed a nasty bug with illegal cyclic references
- Scaladoc is working, including for package objects and other weird
stuff, etc. Interface still needs to be improved.
- A specialized SID is coming up
- Fixed various bugs
- Rewritten the classpath handling logic in the compiler
- Type-constructor inference has been committed to trunk
* Scala on .Net:
- IKVM is being used to run the Scala compiler on .net (IKVM provides a
Java standard library and runtime in .net) to provide debug information.
This is the first step in bootstrapping the Scala compiler on .net. After
that, IKVM can be dropped and a pure .net version of Scala can branch.
* SLS:
- Change in the specification: in-package members have higher priority
than imported ones.
- Worries are expressed that this is suboptimal for dependency managers
as it requires recompiling whole packages more often.
* scala.Zero:
- Paul added scala.Zero. It may be useful, argue some. Other disagree
and worry it promotes code that is too overloaded. Can we see some use
cases? Is its structure right? Maybe it should better be understood before
entering the main library.
- Martin will discuss further with Paul.
* Serialization:
- Many classes in the new collection library are not serializable, which
must change. Someone needs to do it, but who? We don't have the skills at
LAMP, Adriaan will ask the community for contributions.
* Enumerations:
- Ticket #2111 asks for a reflection-fuelled über-version of
Enumeration. We think the proposal is a tad too complicated. Instead, we
propose using reflection is normal enumeration to give the name of the
field to each enumeration value.
* Package Objects in scala.collection.
Miles wanted to write something like:
val a: Array[Int] = List(1, 2, 3).map(_ + 1)(breakOut)
Adriaan proposes the following implementation for breakOut:
package scala
package object collection {
import scala.collection.generic.{CanBuild, CanBuildFrom}
def breakOut[From, T, To](implicit b : CanBuild[T, To]) =
new CanBuildFrom[From, T, To] {
def apply(from: From) = b.apply() ; def apply() = b.apply()
}
}
- Some collection classes, such as streams and vectors, so far only work
with their own builders and ignore the builder factory argument. Supporting
break-out builders will require changing these classes to include a
fallback mechanism for generic builders, which might in some cases not be
desirable (e.g. for single element appends on vectors it could be a
performance hit). Adriaan and Tiark argue that for cases like this,
documenting the current behavior is enough. Martin would like to see
runtime builder checks in `dangerous` places. Tiark will change vectors to
include checks in methods likely to be used with break out (`map`,
`flatMap`, `++`, etc).
- Putting breakOut into the collection object seems the most logical
place, however `ant quick.lib` fails.
* Move some core library classes:
- Some scala package classes could be moved to more precise packages.
For example in math.
- Also FunctionX and TupleX should be autogenerated and invisible in
Scaladoc.
- Also, why are some annotations in scala, other in scala.annotation?
- We'll leave them there, but Martin will speak to Paul about it.
* 2.7.7:
- Two bugs reported against 2.7.7.RC2: #2530 and #2515.
- The latter may be fixed in 2.7.8, which will likely be handled by the
Lift community. It is also fixed in 2.8 trunk.
- We want 2.7.7 out. The final version will be out as soon as Toni gets
better.
* 2.8 beta:
- Still considering a candidate next week
Wed, 2009-10-28, 22:07
#2
Re: Scala Meeting report, 2009-10-27
Hi Jorge,
Thanks for this work!
We plan to have a first internal test candidate available in a week,
so that Lift and other tools can be tested against it. If all goes
well, we plan to have a public beta in about three weeks.
So if you could finish the review i about a week or 10 days from now,
it would be most helpful!
Cheers
Wed, 2009-10-28, 22:37
#3
Re: Scala Meeting report, 2009-10-27
On Wed, Oct 28, 2009 at 2:02 PM, martin odersky <martin.odersky@epfl.ch> wrote:
Hi Jorge,
Thanks for this work!
We plan to have a first internal test candidate available in a week,
so that Lift and other tools can be tested against it.
Martin,
I've got two issues in Lift that I'm blocking on. I've posted these issues/questions to the Scala list, but have not heard any reply:
- Set64 seems have disappeared from enumerations. Was this intentional? Can it be undone?
- Wildcards in self-types seems not to work. Is this intentional?
Thanks,
David
If all goes
well, we plan to have a public beta in about three weeks.
So if you could finish the review i about a week or 10 days from now,
it would be most helpful!
Cheers
Wed, 2009-10-28, 22:47
#4
Re: Scala Meeting report, 2009-10-27
On Wed, Oct 28, 2009 at 10:30 PM, David Pollak
wrote:
>
>
> On Wed, Oct 28, 2009 at 2:02 PM, martin odersky
> wrote:
>>
>> Hi Jorge,
>>
>> Thanks for this work!
>>
>> We plan to have a first internal test candidate available in a week,
>> so that Lift and other tools can be tested against it.
>
> Martin,
>
> I've got two issues in Lift that I'm blocking on. I've posted these
> issues/questions to the Scala list, but have not heard any reply:
>
> Set64 seems have disappeared from enumerations. Was this intentional? Can
> it be undone?
It was certainly intentional. I did not know it was used by people
outside. The recommended way now is to use Bitset. We could
re-instantiate and deprecate Set64 in Enumeration.
I'd be happy if someone else did it, though.
> Wildcards in self-types seems not to work. Is this intentional?
>
No that looks like a bug. Do we have a ticket for this?
Cheers
Wed, 2009-10-28, 22:57
#5
Re: Scala Meeting report, 2009-10-27
On Wed, Oct 28, 2009 at 2:40 PM, martin odersky <martin.odersky@epfl.ch> wrote:
On Wed, Oct 28, 2009 at 10:30 PM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
>
>
> On Wed, Oct 28, 2009 at 2:02 PM, martin odersky <martin.odersky@epfl.ch>
> wrote:
>>
>> Hi Jorge,
>>
>> Thanks for this work!
>>
>> We plan to have a first internal test candidate available in a week,
>> so that Lift and other tools can be tested against it.
>
> Martin,
>
> I've got two issues in Lift that I'm blocking on. I've posted these
> issues/questions to the Scala list, but have not heard any reply:
>
> Set64 seems have disappeared from enumerations. Was this intentional? Can
> it be undone?
It was certainly intentional. I did not know it was used by people
outside. The recommended way now is to use Bitset. We could
re-instantiate and deprecate Set64 in Enumeration.
I'd be happy if someone else did it, though.
No worries. It'll take me less time to change Lift. ;-)
> Wildcards in self-types seems not to work. Is this intentional?
>
No that looks like a bug. Do we have a ticket for this?
I'll do a ticket-search for it tonight or tomorrow.
Cheers
Fri, 2009-10-30, 01:17
#6
Re: Scala Meeting report, 2009-10-27
On Wed, Oct 28, 2009 at 2:53 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:
On Wed, Oct 28, 2009 at 2:40 PM, martin odersky <martin.odersky@epfl.ch> wrote:
On Wed, Oct 28, 2009 at 10:30 PM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
>
>
> On Wed, Oct 28, 2009 at 2:02 PM, martin odersky <martin.odersky@epfl.ch>
> wrote:
>>
>> Hi Jorge,
>>
>> Thanks for this work!
>>
>> We plan to have a first internal test candidate available in a week,
>> so that Lift and other tools can be tested against it.
>
> Martin,
>
> I've got two issues in Lift that I'm blocking on. I've posted these
> issues/questions to the Scala list, but have not heard any reply:
>
> Set64 seems have disappeared from enumerations. Was this intentional? Can
> it be undone?
It was certainly intentional. I did not know it was used by people
outside. The recommended way now is to use Bitset. We could
re-instantiate and deprecate Set64 in Enumeration.
I'd be happy if someone else did it, though.
No worries. It'll take me less time to change Lift. ;-)
> Wildcards in self-types seems not to work. Is this intentional?
>
No that looks like a bug. Do we have a ticket for this?
You do now ;-)
http://lampsvn.epfl.ch/trac/scala/ticket/2545
I'll do a ticket-search for it tonight or tomorrow.
Cheers
Mon, 2009-11-02, 17:57
#7
Re: Scala Meeting report, 2009-10-27
Hi David,
2545 should be fixed now. Let me know if anything else comes up.
Cheers
Tue, 2009-11-03, 00:27
#8
Re: Scala Meeting report, 2009-10-27
On Mon, Nov 2, 2009 at 9:53 AM, martin odersky <martin.odersky@epfl.ch> wrote:
Hi David,
2545 should be fixed now. Let me know if anything else comes up.
I'll work on it tomorrow (after the code migrates to scala-tools.org)
Cheers
All,
I've completed about 3/4 of a review of the current state and the history of deprecated methods in 2.8. So far, most of the deprecations are ok, but there are some that have been deprecated since <=2.6.0 (and I'll argue should be removed) and some that were added in 2.8 but are now deprecated (and I'll argue should also be removed). I'd like for this removal process to be completed before the beta candidate is released, especially for methods added in 2.8 and subsequently deprecated, as it might be harder to remove them if there's even a semi-sanctioned release of Scala that contains them.
When I finish the review I'll share it with this list. It's just a spreadsheet that lists each deprecated method, when it was added to the standard library, when it was deprecated, and any additional considerations. I estimate it will take me about 2-3 more hours of work to finish this. This review will not include a patch, but hopefully such a patch would be easy to come up with once an appropriate policy for deprecated methods is decided on.
My question is, when should I have this review finished by such that a policy could be agreed upon and a patch devised before the release of the 2.8 beta candidate?
Thanks,
--j
On Wed, Oct 28, 2009 at 11:18 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote: