Scala Debate

More relaxed discussions: questions and suggestions on Scala's future, discussions that start elsewhere become but become too specific, topics that are not of general interest.

An idea for reducing typeclass-related boilerplate

Hi all,

Just have an idea how to make code which uses typeclasses better.
Consider an example:

def sum[T : Integral](list: List[T]): T = {

Naive proposal du jour: Extractor error messages

Let's say you've written an extractor that works beautifully, but when it fails, you'd like to return extra information about why it failed.  While the standard pattern matching idiom leaves no place for such information to escape, I think it'd be neat if it could be included in any MatchError that might be generated.
Here's an example that I wrote just now; it tests whether the scrutinee Map is a super-Map of some predefined Map:

Deadline Extension: The Third Scala Workshop

We've already received a fair number of submissions (thank you!), but have decided to give those who need a bit more time the opportunity to finish their papers.

If you'd still like to submit a paper to the academic track of Scala Days, aka the "Scala Workshop,"
- submit an abstract by Wednesday 18 Jan at 9AM CET on http://www.easychair.org/conferences/?conf=days2012  (this will allow us to get the review process going)

The state of Scala optional

From what I've figured out from github you, Paul and Jamie, seem to be
the main contributors of the Scala `optional` library. What's the
current state of it? Is there a 2.9.1 build published somewhere?

Scala alphanumeric identifiers and '$' character

From Programming in Scala section 6.10 (Page 151):

------------------
Identifiers in user programs should not contain '$' character, even
though it will compile; if they do this might lead to name clashes
with identifiers generated by Scala compiler.
------------------

I am sure it's a reason for this, but why not prevent use of the '$'
character in alphanumeric identifiers?

martin's post on ycombinator

Hey everyone,

Was wondering if people had seen Martin's post [1] in response to
the "new" complexity blog post [2]?

I am sympathetic to Martin's point that the collections might not be
arbitrarily extensible (they certainly aren't in many other languages).

However, I'm not sure that taking away things like implicit conversion
will address many of the problems brought up later in the original post
(e.g. the sortBy failure) since this is code that doesn't look like
it's trying to do anything fancy.

Potential solution for Scala 2.9.x dexopt failing

There is an article on Android Developers Blog about using multiple
DEX files in a single APK...if there was a way we could integrate the
procedure into SBT then we could completely avoid ProGuard!

Here's the article: http://android-developers.blogspot.com/2011/07/custom-class-loading-in-d...

Java to Scala conversion

Hi.

I am not sure if this is the right forum for this post, so forgive me, if it isn't.

I just published a tool called Scalagen on GitHub : https://github.com/mysema/scalagen

Scalagen aims to convert Java to Scala sources. It is inspired by Jatran, but aims to be more modular and focusing more on idiomatic Scala than 100 % compilable code.

The results are to be seen as a starting point for a Java to Scala conversion effort, not as the final result.

The latest release contains a working Maven plugin, but SBT integration might be added in the future.

Br,
Timo Westkämper
Syndicate content

Copyright © 2013 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland