Unsigned integer data types

the general idea is to introduce 4 new data types corresponding to the unsigned integers

motivation is mainly coming from Scala.js and the hope is that this will resolve some Scala.js weirdness along with the fact that there is currently no way to represent a type of value unsigned integer from javascript point of view

@dickwall asks what the size of the implementation will be. @sjrd has two approaches at the moment:

One is to limit compiler changes as much as possible

this would lead to a “one line” change

the change would also prevent optimization where things are boxed at runtime (which is very close to the compiler), all other changes are library based

main drawback is performance for equality is impacted. For the simple implementation so far investigated, it’s about a 3 x hit on performance @odersky thinks that’s a show stopper, but @sjrd points out that they are still working on this

problem is Scala Number is a class, AnyVals can’t extend classes, which is why we have to mangle with boxes at runtime

The second option is to change the compiler

Actions:

@dickwall put this into public review for a month - let people comment on the SLIP/add suggestions

Implicits in for comprehensions/pattern matches SIP tracking

@som-snytt has code that looks like it works and does what this SLIP says it should

the next question is is this good enough? Does this need to be taken further? The issue is that now implicits can behave differently in for comprehensions than outside. The committee are concerned about corner cases and would like Scala’s features to be consistent

it’s decided that this needs to be extended to a general pattern, and @odersky is keen on that work being done

@SethTisue doesn’t know what the likelihood of @som-snytt taking the rest of this work on - the for comprehension might be the only version that he has time for. If he doesn’t have time, then hopefully the community will be able to help

Open question:

@odersky in Dotty, want to enforce that every implicit has an explicitly given type because it’s very confusing that implicits get lost due to the order of local type inference

how will that work in a for? The natural thing would be for an implicit not to have a result type.. will we have to enforce that?

Actions:

@SethTisue to post instructions on the SLIP PR on how to use a specific Scala build so people can try out the current implementation

JSON AST, Scala standard library, and the SLIP process

A SLIP proposing a standard JSON AST deviated quickly from the purpose of the SLIP and started a long discussion about what should and should not be in a Scala standard library. This and other discussions seem to really stem from the fact that it isn’t clear what should go where in the Scala ecosystem.

@odersky has since created a document on this topic called “What should go into the standard library” (link above) which proposes a new structure for Scala and it’s libraries. Comments are invited.

The document proposes a solution similar to Haskell:

a “core”: which consists only what the compiler needs and not more (@odersky thinks for Scala this should be explained slightly)

a “platform”: can vary and be much bigger. The platform would be maintained by a different set of people from the core (and have it’s own committee), it would be handled by the people who contribute modules to the platform

@odersky thinks this would be a good model for us as well - the SLIP/SIP committee would look after the core and language, leave the platform to those who work on the platform. The SLIP committee would probably need to jumpstart the platform process in the beginning, but would like to hand over it’s running to the community as soon as possible

Conversation over the proposal:

@dickwall points out there is scope to have the “EPFL Scala platform” as well as other platforms, including more functional ones

suggests we borrow from Ubuntu model with “umbrella dependencies” that you bring in letting you group things. Haskell has this too - where you can use different platforms

idea behind the SLIP process is was to get library developers to work together, not to work on things just for the standard library. It sounds like this process would achieve that

users would also know they are going to get a certain quality of library

core is very large, bringing it down would be very hard to migrate things out. Think we are a long way from being able to do this (although that doesn’t mean we shouldn’t aim for it)

likes the idea of a platform, but the thing that’s hard is the Scala namespace… the idea that the platform can have some stuff in the Scala namespace and some stuff that’s not, that’s a challenge

The JSON AST discussions raised a good question: should we create a shared platform library and make it good, or should we create a good library and make that a platform library later? People had good points for both sides of this argument

once you say something is in the Scala namespace, then you’re saying it’s going to be the thing because it’s been blessed in some way. We say there is one platform, but if there are things in another namespace (eg Akka) those have a fundamentally different status than something in Scala namespace

typically (eg in Python), maintainers maintain their module (not everything) make micro decisions about that module, but have larger committee who decides what’s in or out or when there is going to be a new version or there is a difference of opinion they deal with that

does @odersky see it like that? Would there be a gatekeeper - if so will that keep this from taking off?

there is a contradiction saying platform maintainers should decide what goes into the Scala namespace and the wish to have several platforms

if you want the best part to be something different and you have Several groups of people organizing platforms, everyone in these groups will decide what to put in “their” Scala namespace and that’s not the point of a namespace

@heathermiller assume other platforms (other than the Scala.org platform) would have to use another namespace

@odersky Scala namespace really just another module in the platform that exits to be general and a common base

Actions:

@dickwall created new issue to track this: https://github.com/scala/slip/issues/31

The community should read @odersky’s document and let the SLIP know their thoughts/questions/comments

@odersky suggests for the issue of “bless and then make good” vs “good and then bless” we could adopt a package alias to bless things and bring them into the Scala namespace and solve the naming problem

Actions:

SLIP give a number (28)

AOB

Sadly, @dickwall is to step aside from the committee meetings but will continue to help with some of the process work. This is @dickwall’s last committee meeting