Scala Meeting report, 2009-11-10

Regarding a Scala-specific version of hashCode, has a Hash[T] typeclass been considered? It could use the new context-bound feature, and might be better than a method on Any or Predef.

--j

On Wed, Nov 11, 2009 at 2:53 PM, Antonio Cunei <antonio [dot] cunei [at] epfl [dot] ch> wrote:

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-11-10:

People attending the meeting: Donna, Alex, Eugene, Hubert, Martin, Iulian,
Philipp, Lukas, Gilles, Toni, Adriaan.

Topics discussed:

* Current work:
 - scaladoc plugin is complete.
 - added zipped to collections.
 - fixed various bugs related to structural types:
   - type rules for structural types with this.type or type parameters
are tighter.
   - structural method dispatch works with new arrays.
 - package objects fixes.
 - fixed various bugs related to optimised.
 - now type inference treats numeric types specially:
   - List(1, 1L): List[Long].
   - Weak conformance, which allows such rules, is used by if, try,
match, method arguments.
 - fixed a couple of bugs with build manager.
 - work on Visual studio integration package for Scala.

* Scala 2.8 beta candidate release:
 - deprecated warnings: not worrying for the candidate, should be fixed
for the beta.
 - hash/equals: new, fast equality is available. New hash code isn't but
is "strictly better" so that anything that works with the current hash
code will also work with the new one.
 - linked lists: are still missing. We need them in the candidate. We'll
prepare them now.
 - zipped/zip: TupleN (for N= 2,3 -- for now) provides zipped and zip.
Example use:
     scala> (List(1,2,3), List("a", "b", "c")).zipped map {(i, s) => i + s}
     res0: List[java.lang.String] = List(1a, 2b, 3c)
     scala> (List(1,2,3), List("a", "b", "c")).zip
     res1: List[(Int, java.lang.String)] = List((1,a), (2,b), (3,c))
 - structural method dispatch: is much improved.
 - eclipse: our own experience is still a bit rough. Miles asks us not to
wait for him. He hopes to have something in time for the beta, but a
series of nasty Eclipse bugs prevented him of making as much progress as
he had hoped, and Eclipse won't be ready for testing when the beta
candidate goes out.
 - As soon as linked list is ready, we'll prepare a release candidate and
we'll send it out, hopefully by Thursday or so.

* SVN post-commit script:
 - The script described in #2466 caused spurious messages in some
tickets. We'll keep the script disabled for now, we'll revive it once it
has been modified appropriately.

* Equality & Hash codes
 - Martin commited a new version of equals. Which is fast and inlined
when comparing equality on references. The slow path, which must go
through another method, and a series of instance-of tests, is used
whenever the equality may be on Number of Character.
 - We may loose the current property that a.equals(b) --- when a is a
value type, and b a user-provided, number-like, custom class --- is run
as if it were b.equals(a). This allows the user-provided number class to
provide a suitable equality method. It appears that this property isn't
used in library classes (such as BigInt), and it will probably go with
the new collection library.
 - Martin wants to have a Scala-specific version of hashCode, called
hash, or hashOf, that does the Right Thing (tm). Scala collections would
use hash instead of hashCode.
 - The hash method could be a method in Predef, or could be a method of
Any. We'll have in Predef for 2.8.

* Partial function:
 - isDefinedAt was requested to be available on Function1 (and always
return true), not just on PartialFunction. Basically, this would mean
that Function1 be considered as a total function, which isn't true:
Function1 is the type of both total and partial functions.
 - There would also be a performance price to pay in terms of
compilation; see
http://article.gmane.org/gmane.comp.lang.scala.internals/2078
 - We will keep things as they are.

On Thu, Nov 12, 2009 at 2:54 AM, Jorge Ortiz wrote:
> Regarding a Scala-specific version of hashCode, has a Hash[T] typeclass been
> considered? It could use the new context-bound feature, and might be better
> than a method on Any or Predef.
>
I think we want to maintain universal hashing, it's too much part of
the Java culture.
So I don't see a role for a Hash[T] class.

I believe hash should not be represented as a proper method of Any,
because of the risk that it conflicts with other methods or fields
named `hash' in user code. `hash' is quite a common name.

An advantage of using hash as a static method somewhere is that we can
use overloading to specialize for fast cases on known types.

We could also add hash in a `pimp my library' fashion to Any,
analogous to what's done with the String concatenation +. In fact, we
could add hash to StringAdd, probably after renaming StringAdd to
something more generic. Not quite sure it's worth it, yet.

So, the choices are:

1. put hash(x) in Predef, overload for speed

2. put hash(x) in a util object, say, scala.util.Hashing, and have it
be called from
a pimp-my-library method hash, so that x.hash would call
scala.util.Hashing.hash(x),
except if hash is already defined for x. In the latter case there
would always be the
fallback to scala.util.Hashing.hash(x), and that fallback could
also be used for speed.

In favor of (1) is that it's simpler. In favor of (2) is that it looks
slightly more natural to write
x.hash instead of hash(x), so you could do that if you do not care for speed.

I have a slight tendency to pick (1). What's your opinion?

Cheers