Scala Language

On Wed, Dec 7, 2011 at 2:40 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Wed, Dec 7, 2011 at 11:32 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
> I don't know why I should have to bother repeating the type information if
> all I want to do is forward parameters to A's constructor.

Because A could have more than one one-argument constructor.

That is a problem because...?

(Actually the shadow does not know, that's the problem.)

I'm going to take one last swing at this and then wash my hands of it
forever. If I'm the only guy who thinks this is wrong, well it won't
be the first time that's happened. Your silence will tell me all I
need.

I understand the idea behind use cases, and I understand the idea
behind *hiding* the actual methods when a use case is present.
However, use cases are broken in ways that have nothing to do with
displaying a false type signature, and the lack of documentation for
the actual methods makes the issue critical, in my opinion.

Please refer to https://issues.scala-lang.org/browse/SI-5287 for details.

See methods foreach and map on Range for examples of broken documentation.

body p { margin-bottom: 0cm; margin-top: 0pt; }

Hi,

Currently, methods like ++ are considered complex:

def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

One reason is the list of implicit arguments. Someone looking at the scaladoc, or IDE completion, needs to figure what it means, what is the role of CanBuildFrom, etc.

Call for Participation
======================

14th International Symposium on
Practical Aspects of Declarative Languages (PADL 2012)

http://research.microsoft.com/~crusso/padl12

Philadelphia, Pennsylvania, USA, January 23-24, 2012
Co-located with ACM POPL'12

You are cordially invited to PADL'12. PADL is a forum for researchers
and practitioners to present original work emphasizing novel
applications and implementation techniques for all forms of
declarative concepts, including functional, logic and
constraints.

scala -versionScala code runner version 2.9.1.final -- Copyright 2002-2011, LAMP/EPFL
1. scala> val a = List(1,2,3)

a: List[Int] = List(1, 2, 3)

2. scala> val b = List(4,5,6)

b: List[Int] = List(4, 5, 6)

3. scala> a zip b

res18: List[(Int, Int)] = List((1,4), (2,5), (3,6))

4. scala> a.zip(b)

res19: List[(Int, Int)] = List((1,4), (2,5), (3,6))

5. scala> a.zip(b) ++ List((9, 10))

Hi all,
I am trying to implement forward lists. I was inspired by some Haskell code found here : http://files.codersbase.com/thesistalk.pdf (page 20). Here is how I want to use/create forward lists : 
class F [A, B] (a : A, b : B)object F { def apply [A, B] (a : A, b : B) = new F (a, b)}
F ("a", 1) :>: F (1, 'a') :>: Nil // is correct and should have type : ForwardList [F, String, Char] F ("a", 1) :>: F ("b", 2) :>: Nil // should not compile, type error : adding an element to a ForwardList [F, String, Int] should be of type F [_, String]

Hi,

it is not my blog, but I guess some information doesn't hurt:
http://hacking-scala.posterous.com/new-features-in-scala-210

Are there any other resources (slides/videos) of Scala-related stuff available?

Bye,

Simon