The Artima Developer Community
Sponsored Link

Weblogs Forum
The Myth Makers 1: Scala's "Type Types"

13 replies on 1 page. Most recent reply: Dec 19, 2008 11:54 AM by James Iry

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 13 replies on 1 page
Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

The Myth Makers 1: Scala's "Type Types" (View in Weblogs)
Posted: Dec 18, 2008 11:06 AM
Reply to this message Reply
Summary
Busting some myths that have sprung up around Scala.
Advertisement

2008 has seen a lot of activity around Scala. All major IDEs now have working Scala plugins. A complete Scala tutorial and reference book was published and several others are in the pipeline. Scala is used in popular environments and frameworks, and is being adopted by more and more professional programmers in organizations like Twitter, Sony Imageworks, and Nature, along with many others.

It's also a sign of growing momentum that well-known commentators like Ted Neward, Daniel Spiewak and the JavaPosse have covered Scala in depth. Other bloggers have argued more from the outside, without really getting into Scala all that deeply. I find the latter also useful, because it shows how Scala is perceived in other parts of the programming community. But sometimes, initial misconceptions can create myths which stand in the way of deeper understanding.

So, as an effort of engaging in the debate, let me address in a series of blog posts some of the myths that have sprung up in the last months around and about Scala. I'll start with a post by Steve Yegge. Like many of Steve's blogs, this one is quite funny, but that does not make it true.

Steve (in his own words) "disses" Scala as "Frankenstein's Monster" because "there are type types, and type type types". (Don't ask me what that means!) In fact, it seems he took a look at the Scala Language Specification, and found its systematic use of types intimidating. I can sympathize with that. A specification is not a tutorial. Its purpose is to give compiler writers some common ground on which to base their implementations. This is not just a theoretical nicety: the implementation of JetBrains' Scala compiler for IntelliJ makes essential use of the language specification; that's how they can match our standard Scala compiler pretty closely. The other purpose of a specification is that "language lawyers" - people who know the language deeply - can resolve issues of differing interpretations. Both groups of people value precision over extensive prose. Scala's way of achieving precision in the spec is to be rather formal and to express all aspects of compile-time knowledge as types. That's a notational trick which let us keep the Scala spec within 150 pages - compared to, for instance, the 600 pages of the Java Language Specification.

The way a spec is written has nothing to do with the experience of programmers. Programmers generally find Scala's type system helpful in a sophisticated way. It's smart enough to infer many type annotations that Java programmers have to write. It's flexible enough to let them express APIs any way they like. And it's pragmatic enough to offer easy access to dynamic typing where required. In fact Scala's types get out of the way so much that Scala was invited to be a contender in last JavaOne's Script Bowl, which is normally a shootout for scripting languages.

But Steve's rant was not really about technical issues anyway. He makes it clear that this is just one move in a match between statically and dynamically typed languages. He seems to see this as something like a rugby match (or rather football match in the US), where to score you need just one player who makes it to the ground line. Steve's on the dynamically typed side, pushing Rhino as the Next Big Language. Java is the 800-Pound Gorilla on the statically typed side. Steve thinks he has Java covered, because its type system makes it an easy target. Then out of left field comes another statically typed language that's much more nimble and agile. So he needs to do a quick dash to block it. If he can't get at the programming experience, it must be the complexity of the specification. This is a bit like saying you should stay away from cars with antilock braking systems because the internal workings of such systems are sophisticated!

Not quite surprisingly, a number of other bloggers have taken Steve's rather lighthearted jokes as the truth without bothering to check the details too much and then have added their own myths to it. I'll write about some of them in the next weeks.


Daniel Spiewak

Posts: 2
Nickname: 56153
Registered: Jun, 2008

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 18, 2008 12:42 PM
Reply to this message Reply
I'm going to guess that Steve's "type types" are probably a reference to higher kinds. At least, that's what they *should* be. Type type types, while an interesting thought, are just absurd in the context of Scala.

Personally, I think that Scala's official spec is one of the most well-written of any language (including Charles Nutter's semi-official Ruby spec wiki). One of the frustrating things about Scala is when you start learning the more advanced features (think "requires"), the amount of available material goes to zero. However, the spec is always there, providing a helpful (if condensed) description of what's going on under the surface. Usually, between the spec and the REPL, I'm able to understand just about any language feature within an hour or so.

Regarding the dig against Scala's type system, in some sense I can see where he is coming from. Don't get me wrong, I *love* Scala's type system and the way it's beautiful complexity interacts to prove correctness in a more comprehensive way, but that's not to say that it doesn't have its warts. A good example of this would be attempting the following using the parser combinator framework:


def method = "def" ~> name ~ formals ^^ { (n, f) =>
...
}


This doesn't compile. For 10 bonus points, can anyone explain why? (hint: think implicit conversions)

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 18, 2008 2:11 PM
Reply to this message Reply
I'm not sure I understand. Should this not be:

def method: Parser[Unit] = "def" ~> name ~ formals ^^ { case n ~ f => ... }

?

(For non-insiders: these are parser combinators, which implement the first stage of a compiler. There's a library
in Scala that helps with this task, defining combinators like ~, ~>, and ^^ which build basic parsers. It's explained in one of the last chapters of Programming in Scala.)

Brad Siemssen

Posts: 1
Nickname: siemssen
Registered: Dec, 2008

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 18, 2008 3:32 PM
Reply to this message Reply
I think what Steve is getting at is something I've noticed trying to pick up Scala myself. When I pick up a language, I often read the language spec. I really like to know what is going on. When picking up Java, I read it's spec, I only really understood Ruby after I'd read up on Ruby internals, that document how MRI actually works. It is only when I deeply understand what is going on under the covers that I feel comfortable using a language.

I've never used a strongly typed language like Haskell, or ML, and when I look through the Scala language spec, I'm confused. Even reading through the tutorials when I run into things like the co-variant and contra-variant types specifiers for generic code, I'm lost. Moreover I don't see how type variance helps in design. I'm sure it plays a big role, but I just don't understand it enough to use it.

I'm left feeling that until I can wrap my head around the type things, I can't use Scala as anything other than Java with different syntax, and I don't need Java with different syntax. But its more than just a different syntax, there are the Scala special libraries that I can't understand because I can't get my head around the type system. And while Scala has a very clean syntax, that can be used for scripting, I haven't seen that the Scala regular expression support and string interpolation facilities compare in any favorable way to Ruby so I don't end up using Scala for those tasks. The examples of Scala scripting that I've seen depend on taking advantage of the advanced type system, or use libraries that take advantage of the type system in interesting ways. But I don't understand the type system, so I don't put Scala to use in those interesting way for my small scripting needs.

Scala as a scripting language would be much more believable if there were good tutorials showing how to use whatever regex goodies Scala has, and demonstrating how to interact with the filesystem in decent ways, and some string interpolation mechanism.

The net effect is that Scala is a language I really want to like. But I don't understand well enough to use.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 18, 2008 4:02 PM
Reply to this message Reply
> I'm left feeling that until I can wrap my head around the
> type things, I can't use Scala as anything other than Java
> with different syntax, and I don't need Java with
> different syntax. But its more than just a different
> syntax, there are the Scala special libraries that I can't
> understand because I can't get my head around the type
> system. And while Scala has a very clean syntax, that can
> be used for scripting, I haven't seen that the Scala
> regular expression support and string interpolation
> facilities compare in any favorable way to Ruby so I don't
> end up using Scala for those tasks. The examples of Scala
> scripting that I've seen depend on taking advantage of the
> advanced type system, or use libraries that take advantage
> of the type system in interesting ways. But I don't
> understand the type system, so I don't put Scala to use in
> those interesting way for my small scripting needs.
>
> Scala as a scripting language would be much more
> believable if there were good tutorials showing how to use
> whatever regex goodies Scala has, and demonstrating how to
> interact with the filesystem in decent ways, and some
> string interpolation mechanism.
>
> The net effect is that Scala is a language I really want
> to like. But I don't understand well enough to use.

Many years ago I had a similar issue when learning PERL: There was no clear spec, and I didn't understand many aspects of the language at first. However, it was around that time that Larry Wall's Camel book came out, and that really helped me use the language productively. Java, though, I learned mostly from the specs (including the VM spec), as well as the API docs, which are mostly pretty good.

Now that the Programming in Scala book is out, I think that book will have a similar role in the Scala world to what the Camel book had in the PERL world: It explains the key concepts in the context of lots of excellent code examples, something the spec (and even ScalaDoc) don't do.

James Iry

Posts: 85
Nickname: jiry
Registered: Nov, 2007

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 18, 2008 4:05 PM
Reply to this message Reply
Brad, The Java Language Specification, Third Edition uses the word "variance" 7 times (all in this context), "covariant" 6 times, and "contravariant" 1 time.

Language specifications use terms of art that are meaningful to compiler designers not necessarily terms familiar to new users of the language.

Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 18, 2008 5:30 PM
Reply to this message Reply
> I've never used a strongly typed language like Haskell, or
> ML, and when I look through the Scala language spec, I'm
> confused. Even reading through the tutorials when I run
> into things like the co-variant and contra-variant types
> specifiers for generic code, I'm lost. Moreover I don't
> see how type variance helps in design. I'm sure it plays a
> big role, but I just don't understand it enough to use
> it.
>
When I started helping with the Scala book project, I didn't have a complete understanding of how Java's wildcard types worked. The reason is that I had found it hard to understand, but also I had found that I didn't really need to completely understand wildcards to use Java for the most part. As I was working on the book, though, I realized I'd need to get a handle on this stuff. So that's when I finally took a deep breath and dove into understanding Java's wildcards.

I have found that Scala's declaration site variance is much easier to understand and work with than Java's wildcard (use-site variance) approach, but I still found contravariance to be non-intuitive. Nonvariant and covariant types made sense on the surface. Nonvariant says an Array[String] is not a subtype (or supertype) of Array[Object]. Covariant says a List[String] is a subtype of List[Object]. But contravariance is weird. It says, that a Matcher[Object] is a subtype of Matcher[String]. When I was editing the variance stuff in the book, I added in a concrete example of contravariance, to try and help explain it.

I have ended up using contravariance in practice once so far, in ScalaTest's matchers (which haven't been released as yet). But contravariance was useful in that case because it lets users of my API combine matchers with boolean expressions in very flexible ways, and the types always come out right. That said, users of ScalaTest's matchers won't really need to understand contravariance. They can just combine matchers in boolean expressions and it will work. So there's a lot of client programming you can do with Scala without actually fully comprehending how variance works. When you want to design a library, though, a more sophisticated knowledge of Scala's type system comes in handy.

One other related thing that's in Scala's type system is called "existential types". This one is primarily in there so that Scala can talk about Java's wildcard types, raw types, and (at runtime) erased types. I actually find Scala's existential types pretty easy to understand, easier to understand than Java's wildcard types, even though they cover much the same ground. But what I do find hard sometimes is the mapping from Scala's existential types to Java's wildcards. I.e., when I'm calling into a Java API from Scala, I sometimes need to specify an existential type where in Java I'd need to specify a wildcard. I get that wrong sometimes, and the compiler lets me know. I've always been able to fix it though with a little tweaking. It just occurred to me now that a cheat sheet showing the mapping between different Java wildcards and Scala existentials would be helpful.

> I'm left feeling that until I can wrap my head around the
> type things, I can't use Scala as anything other than Java
> with different syntax, and I don't need Java with
> different syntax. But its more than just a different
> syntax, there are the Scala special libraries that I can't
> understand because I can't get my head around the type
> system. And while Scala has a very clean syntax, that can
> be used for scripting, I haven't seen that the Scala
> regular expression support and string interpolation
> facilities compare in any favorable way to Ruby so I don't
> end up using Scala for those tasks. The examples of Scala
> scripting that I've seen depend on taking advantage of the
> advanced type system, or use libraries that take advantage
> of the type system in interesting ways. But I don't
> understand the type system, so I don't put Scala to use in
> those interesting way for my small scripting needs.
>
> Scala as a scripting language would be much more
> believable if there were good tutorials showing how to use
> whatever regex goodies Scala has, and demonstrating how to
> interact with the filesystem in decent ways, and some
> string interpolation mechanism.
>
I tell people that Ruby and Python are at heard scripting languages that to some extent scale up to applications and systems. And that Scala is at heart a systems language that to some extent scales down to scripting. One of the reasons I say that is the absence of regular expression literals in Scala. I always kind of wished Scala would have regular expression literals instead of XML literals, but things are the way they are. And it isn't that verbose to get a regex in Scala:


"a*b".r


That's not too bad, but Scala's regex stuff uses Java's behind the scenes, so it has the same backslash problem that Java has. So in Java (and Scala) if you want to say \d*b to match any number of digits followed by a b, you need to double up the backslash. So in Scala you'd say:


"\\d*b".r


To get around that in Scala, though, you can use a raw string literal, which is a triple-quoted string:


"""\d*b""".r


It's still not as pretty as regular expression literals in Ruby or Python or Perl, but it's better than the options in Java at least.

As much as I liked Ruby and Python for scripting, and I had used both in the past, I started using Scala for scripting tasks about a year ago. It is good enough for scripting, and it allows me to use the same language for scripting that I use for systems. It also gives me the productivity benefits of static typing when I'm writing scripts, such as deterministic refactoring. But the main reason I started using it was so that I didn't have to remember two languages anymore. (Except that we also still program a lot in Java, so I still need to know two languages.)

> The net effect is that Scala is a language I really want
> to like. But I don't understand well enough to use.
>
Hopefully the book will help.

Daniel Spiewak

Posts: 2
Nickname: 56153
Registered: Jun, 2008

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 18, 2008 5:47 PM
Reply to this message Reply
> I'm not sure I understand. Should this not be:
>
> def method: Parser[Unit] = "def" ~> name ~ formals ^^ {
> { case n ~ f => ... }

Certainly, that would work. However, the ImplicitConversions trait offers a nicer syntax in the implicit flattenn methods:


implicit def flatten2 [A, B, C](f : (A, B) => C) : (~[A, B]) => C

Kaustuv Chaudhuri

Posts: 2
Nickname: kaustuv
Registered: Dec, 2008

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 18, 2008 7:06 PM
Reply to this message Reply
> This is a bit like saying you should stay away from cars with antilock braking systems because the internal workings of such systems are sophisticated!

With due respect, and at the risk of stating a common and obvious fact, or of being perceived as an ally of Mr. Yegge, let me recall that a (static) type system should be seen as a syntactic discipline for enforcing levels of abstraction. A language with a complicated (or sophisticated, if you prefer) type system may validly be criticized for having more potential inconsistencies than one with a comparably simpler type system, and therefore more chances of undermining its raison d'ĂȘtre. Scala, having one of the most complex type systems of any language, promises much and has therefore much to defend. A language like Rhino, with an essentially non-existent static type system, promises little and defends little.

To use your motoring metaphor, one might take a skeptical view of the promises of freedom and safety offered by an anti-lock braking system, with admittedly complex (or sophisticated) internal mechanisms, when one already knows how to lay tracks, build fences to keep them out of the reach of casual intruders, and run a steam locomotive on them. (Some readers will surely have noted that a braking system is a runtime check, while a type system is more akin to the department of transportation that promises that licensed drivers will not crash their cars.)

James Iry

Posts: 85
Nickname: jiry
Registered: Nov, 2007

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 18, 2008 8:16 PM
Reply to this message Reply
> at the risk of stating a common and
> obvious fact, let me recall that a (static) type system should be
> seen as a syntactic discipline for enforcing levels of
> abstraction.

It's not common, obvious, nor a fact. A static type system may or may not enforce abstraction. BitC, for instance, is a language with a rich static type system where the author's goal is explicitly to allow users to prescribe details of representation.

Pierce's definition of type system is still about the best: "A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute."

The only quibble I have is his requirement for tractability.

> A language with a complicated (or
> sophisticated, if you prefer) type system may validly be
> criticized for having more potential inconsistencies than

It can and should be criticized for actual inconsistencies. It is reasonable to be suspicious of complexity, but criticizing for potential inconsistencies makes no sense.

> system is a runtime check, while a type system is more
> akin to the department of transportation that promises
> that licensed drivers will not crash their cars.)

Different levels of metaphor. The original metaphor was comparing anti-lock brakes to non-anti-lock brakes. The metaphor was about the complexity involved in even specifying such a beast vs the complexity of using it. It had nothing to do with the dynamic vs static discussion. Please don't drag in that hoary debate.

Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 18, 2008 8:44 PM
Reply to this message Reply
> > This is a bit like saying you should stay away from
> cars with antilock braking systems because the internal
> workings of such systems are sophisticated!

>
> With due respect, and at the risk of stating a common and
> obvious fact, or of being perceived as an ally of Mr.
> Yegge, let me recall that a (static) type system should be
> seen as a syntactic discipline for enforcing levels of
> abstraction. A language with a complicated (or
> sophisticated, if you prefer) type system may validly be
> criticized for having more potential inconsistencies than
> one with a comparably simpler type system, and therefore
> more chances of undermining its raison d'ĂȘtre.
> Scala, having one of the most complex type systems of any
> language, promises much and has therefore much to defend.
> A language like Rhino, with an essentially non-existent
> static type system, promises little and defends little.
>
> To use your motoring metaphor, one might take a skeptical
> view of the promises of freedom and safety offered by an
> anti-lock braking system, with admittedly complex (or
> sophisticated) internal mechanisms, when one already knows
> how to lay tracks, build fences to keep them out of the
> reach of casual intruders, and run a steam locomotive on
> them. (Some readers will surely have noted that a braking
> system is a runtime check, while a type system is more
> akin to the department of transportation that promises
> that licensed drivers will not crash their cars.)
>
I think metaphors are getting mixed here. What I imagined Martin was referring to metaphorically as being sophisticated on the inside is the Scala compiler, not the type system. The Scala compiler is indeed sophisticated, and writing it is a complicated, difficult task. The specification is written very formally to facilitate multiple implementors of language tools such as compilers (or for example JetBrains' compiler front-end for the IntelliJ Scala plugin) to be able to create tools that faithfully and consistently parse valid Scala programs and reject invalid ones.

Scala's type system can be called complicated in the sense of having many different interconnected parts, but to what extent is is complicated in the sense of not easy to analyze or understand? That kind of complexity is in the eye of the beholder, but is also influenced by the way in which people try and learn about the type system. Martin's point I think is that the Scala language specification was not at all intended as a good way to learn about Scala's type system. It's goal was something quite different. The goal of the book, by contrast, was to make it as easy as possible to learn Scala including its type system.

For what it's worth, my experience learning Scala's type system was:

- plain old (nominal) types: easy, same as Java

- type parameterization: also easy, same as Java, but with square brackets instead of angle brackets. I felt square brackets looked a lot nicer, and probably was therefore easier to read, too.

- function types: functions in Scala have nominal types like anything else, with a type parameter for the result type and one each for the parameter types. But there's also a shorthand syntax. Instead of Function1[String, Int], for example, you can say String => Int. The latter is actually easier to read, but when combined with an assignment such as "val a: String => Int = something I find it can sometimes be non-obvious at first glance how to parse it.

- traits: traits were quite easy for me to understand and use. They are exactly like classes except they can't (currently) take constructor parameters and the meaning of super is different inside them. Mixing in multiple traits is straightforward, as it is like implementing multiple interfaces in Java, except traits can have concrete method implementations and real fields. Self types inside traits was something new, but made sense and was quite easy to grok, and are quite powerful.

- singleton objects: these were also quite easy to get, as they are really just a shorthand for the Gang of Four singleton pattern, and can also be seen a more object-oriented way to do statics. The type of a singleton object is its name followed by ".type". Almost never need to use that, but it is pretty straightforward and easy to understand. The SingletonObject.type refers to a synthetically generated class name for the singleton object, which has dollar signs in its name in bytecodes.

- variance: As I mentioned earlier, I found nonvariance and contravariance quite intuitive, but contravariance to be counterintuitive. That latter one took a bit of study, but with a bit of study it made sense. It wasn't that difficult. Variance also includes the concept of upper and lower bounds, which made sense to me. I found the concept of upper and lower bounds easy, but I still have trouble remembering which symbol goes to which: >: means lower bounds; <: means upper bounds. Maybe a good mnemonic is that the one that looks like a smiley face is on uppers.

- view bounds: I did find implicit parameters a bit mysterious at first, but once it I saw good examples of its use I realized what it was for and found it quite sensible. View bounds is a shorthand for a very powerful use of implicit parameters. Its symbol is <%. So it looks like upper bounds except with a percent sign instead of a colon. It is similar conceptually to upper bounds too, except instead of a requirement that something is a subtype, it means something must be implicitly convertible to a type. I think this one can be tricky to learn and understand, so we worked hard on the example in the book to make it as easy to learn as possible. I have used it in ScalaTest and it was very helpful at making the library easier to use.

- existential types: this one's in there primarily for compatibility with Java. Even though one of the things it's supposed to do is enable expression of wildcard types, I found it pretty easy to understand. An existential type says that a type exists, but I don't know exactly what it is. I may know something about it, such that it is a subtype of some other type, and the way that is written is pretty readable. As I mentioned before, what I've found difficult is knowing how to write the Scala existential type that maps to particular a Java wildcard types. There's a shorthand for existential types that involves underscores, but I also found this pretty intuitive. The underscore is Scala is used for a number of different things, but generally stands for something that's left out. In this case, it's a type that's left out, and I found it quite easy to read.

- structural types: this one was also quite easy for me to understand. It is basically compile-time checked duck typing. The syntax is pretty obvious too. I've used it in ScalaTest, and it helped make the API much easier to write and use. Sometimes duck typing is exactly what's needed.

- higher-kinded types: I've never used it to my knowledge. It's syntax is so natural, though, that I may have used it without realizing that's what I was using. This one is not covered in the book. Martin is planning to reimplement Scala's collections library using higher-kinded types for the next release, and says it will eliminate code duplication in the collections library implementation.

- path-dependent types: this one I found a bit mysterious at first. I'm still not sure I appreciate fully its potential uses, but the mechanics of it is quite straightforward. A "path" is some way to get to an object at runtime, and the type at the end is a type defined inside that object's class. So a path dependent type to an inner class instance would be a different type for each different outer class. One place it is used in Scala is in the Enumeration library class.

- abstract types: Scala classes can have type members as well as field and method members, and like fields and methods, they can be abstract. This actually all made sense to me, and seemed quite consistent. What is still not clear to me is how to explain when to use type parameters versus abstract type members. (The book is fairly silent on that subject.) There's some overlap between them, but there are differences also. One difference is you can't use variance with abstract types, just with type parameters. With more experience designing libraries I expect I'll discover more insights, but for now I generally reach first for type parameters.

- type inference: This was also quite easy. The compile will generally infer types where you think it can infer types. On rare occasions you may get a compiler error that clearly says it can't infer the type, and you just fill it in.

That's all I can think of that could be called "Scala's type system". As you can see there are a lot of pieces to it. But with a few exceptions I found most of the pieces to be quite easy to learn and understand. So the challenge in learning it is probably more in how many different pieces there are to learn than in the difficulty of the individual pieces themselves.

Jesper Nordenberg

Posts: 29
Nickname: megagurka
Registered: Dec, 2007

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 19, 2008 3:57 AM
Reply to this message Reply
Bill, I agree that the Scala type system is quite intuitive and logical. The weak spot IMO is the type inference algorithm, which sometimes will bite you and infer some weird type. At times it's also not as powerful as you would like it to be (for example when using implicit parameters). Compared to a functional language like Haskell the Scala type inference more unpredictable and less powerful, which probably is a consequence of subtyping.

Kaustuv Chaudhuri

Posts: 2
Nickname: kaustuv
Registered: Dec, 2008

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 19, 2008 5:52 AM
Reply to this message Reply
> As you can see there are a lot of pieces to it. But with a few exceptions I found most of the pieces to be quite easy to learn and understand. So the challenge in learning it is probably more in how many different pieces there are to learn than in the difficulty of the individual pieces themselves.

I don't doubt that the Scala type system is easy to learn and understand for day to day programming.

My earlier comment was pointing out that a type system with a lot of pieces is more likely to have unforseen cracks or treacherous corners. As James Iry quotes from Pierce above, a type system (or, more precisely, a typing derivation) is to be seen as a proof of the absence of runtime errors. A type system had therefore better be sound, by which I mean that there is a formal and machine-checked proof of its soundness, not merely the lack of known counterexamples. (I use "sound" here informally in the sense of type preservation + progress.)

Given the state of the art of such proofs for real languages, such as the Twelf-checked proof of the soundness of the Harper-Stone semantics for a substantial fragment of Standard ML, I am optimistic that a similar process can be successfully applied for Scala. It would still be a remarkable accomplishment given how much more complex the Scala type system is than Standard ML's.

More on topic, I find the most reprehensible statement in Steve Yegge's rant to be the following mischaracterization of the need for statically checked type systems:

> "Well, dynamic languages, you know, suck, because they don't have static types."

He should have had said, instead:

> "Well, dynamic languages, you know, suck, because they don't have static reasoning."

James Iry

Posts: 85
Nickname: jiry
Registered: Nov, 2007

Re: The Myth Makers 1: Scala's "Type Types" Posted: Dec 19, 2008 11:54 AM
Reply to this message Reply
> a type system (or, more precisely, a typing derivation) is to be seen as a proof of the absence of runtime errors.

A typing derivative is a proof of the absence of CERTAIN runtime errors. It's an important distinction. Without that qualifier it sounds like static typing proponents think that static typing will catch everything.

> A type system had therefore better be sound, by which I mean that there is a formal and machine-checked proof of its soundness,

Work is ongoing on formalized semantics. The first paper on the subject was A Core Calculus for Scala Typing http://infoscience.epfl.ch/record/95716 . It's by no means a complete treatment, but it shows that the LAMP guys share your desire.

Flat View: This topic has 13 replies on 1 page
Topic: Java Posse Roundup 2009 Registration Open Previous Topic   Next Topic Topic: Google Adwords: Stick with


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us