Comments on Programming Scala

Comment on 'Value Types'

2009-07-21T02:09:43-07:00

Value Types

The attempt method will evaluate the call-by-value parameter operation and return its Boolean result, wrapped in a Right or any Throwable that is caught, wrapped in a Left. The script produces this output.

the "call-by-name" parameter
— Dirk_K (2009-07-21 02:09:43)

Comment on 'Variance Under Inheritance'

2009-07-12T22:06:26-07:00

Variance Under Inheritance

Finally, we come to the point of this example. In line #6, we pass in a function that is “willing” to accept a CSuper and “promises” to return a CSub. That is, this function is type inferred to be Function1[CSuper,CSub]. In effect, it widens the allowed instances by accepting a supertype. Keep in mind that it will never actually be passed a CSuper by useF, only a C. However, since it can accept a wider set of instances, it will work fine if it only gets C instances.

will fix. Thanks!
— deanwampler (2009-07-12 22:06:26)

Comment on 'Variance Under Inheritance'

2009-07-10T14:19:05-07:00

Variance Under Inheritance

I think you mean to say, 'In line #6' instead of 'In line #5'.
— sixblackbeans (2009-07-10 14:19:05)

Comment on 'Chapter 12. The Scala Type System'

2009-07-01T15:12:11-07:00

Chapter 12. The Scala Type System

Scala is a statically-typed language. Its type system is one of the most sophisticated in any programming language, in part because it combines comprehensive ideas from functional programming and object-oriented programming. The type system tries to be logically comprehensive, complete, and consistent. It exceeds limitations in Java’s type system while containing innovations which appear in Scala for the first time.

Fixed the "its". Will consider the 2nd comment. thx.
— deanwampler (2009-07-01 15:12:11)

Comment on 'Type Bounds'

2009-07-01T14:27:33-07:00

Type Bounds

The underscore ‘_’ is used for existential types, which we’ll cover below, in the section called “Existential Types”.

I'm pretty sure you're right; the underscore only applies to existential types. will fix.
— deanwampler (2009-07-01 14:27:33)

Comment on 'Type Bounds'

2009-07-01T13:07:39-07:00

Type Bounds

A view is an implicit value of function type that converts a type A to B. The function has the type A => B or (=> A) => B (recall that (=> A) is a by-name parameter). An in-scope implicit method with the same signature can also be used as a view, e.g., an implicit method imported from an object. The term view conveys the sense of having a view from one type (A) to another type (B).

Thanks. Forgot to mention the implicit keyword (for both in-scope methods and function values), etc.
— deanwampler (2009-07-01 13:07:39)

Comment on 'Type Bounds'

2009-07-01T12:47:18-07:00

Type Bounds

The new list of type List[Any], since Any is the closest common supertype of String and Double. We started with a list of Strings, so A was String. Then we prepended a Double, so the compiler inferred B to be Any, the closest (and only) common supertype.

will fix.
— deanwampler (2009-07-01 12:47:18)

Comment on 'Type Bounds'

2009-07-01T12:46:23-07:00

Type Bounds

The :: method can prepend an object of a different type from A, the type of the elements in the original list. The compiler will infer the closest common supertype for A and the parameter x. It will use that supertype as B. Here’s an example that prepends a different type of object on a list.

"Closest" is the work I'm going with...
— deanwampler (2009-07-01 12:46:23)

Comment on 'Type Bounds'

2009-07-01T12:45:42-07:00

Type Bounds

I'm planning to change "parser" to "compiler" globally.

You're right that I picked the word "greatest" to have the opposite sense of the up/down sense of sub/super. Will fix.
— deanwampler (2009-07-01 12:45:42)

Comment on 'Type Bounds'

2009-07-01T12:44:00-07:00

Type Bounds

These bounds are called upper type bounds, following the de facto convention that diagrams of type hierarchies put subtypes below their supertypes. We followed this convention in the diagram shown in the section called “The Scala Type Hierarchy” in Chapter 7, The Scala Object System.

That's pretty much what I meant...
— deanwampler (2009-07-01 12:44:00)

Comment on 'Chapter 12. The Scala Type System'

2009-07-01T09:49:28-07:00

Chapter 12. The Scala Type System

Suggest "... because it comprehensively combines ..."
— acruise (2009-07-01 09:49:28)

Comment on 'Chapter 12. The Scala Type System'

2009-07-01T09:48:56-07:00

Chapter 12. The Scala Type System

"Its" type system. :)
— acruise (2009-07-01 09:48:56)

Comment on 'Type Bounds'

2009-07-01T09:41:23-07:00

Type Bounds

The underscore ‘_’ is used for existential types, which we’ll cover below, in the section called “Existential Types”.

I'm not sure if this is right. I think the _ is only used in the case of existential types (where it expands to a forSome clause). Are you sure it's also used in pattern matching? You may well be right, but it might be worth checking.
— hellige (2009-07-01 09:41:23)

Comment on 'Variance Under Inheritance'

2009-07-01T09:12:25-07:00

Variance Under Inheritance

The last line, #5, does not compile because we are attempting to use a covariant argument in a contravariant position. We’re also attempting to use a contravariant return value where only covariant values are allowed.

Good suggestion. That is a clearer example. Will change.
— deanwampler (2009-07-01 09:12:25)

Comment on 'Type Bounds'

2009-07-01T08:57:15-07:00

Type Bounds

Both function values and methods must be marked "implicit" in order to be considered as views, right? Or maybe this has changed? If so, I'd say "A view is a value of function type marked 'implicit' that..." and "An in-scope method with the same signature and the 'implicit' qualifier is also a view."
— hellige (2009-07-01 08:57:15)

Comment on 'Variance Under Inheritance'

2009-07-01T08:51:32-07:00

Variance Under Inheritance

Class List is declared List[+A], which means that List[String] is a subclass of List[AnyRef], so Lists are covariant in the type parameter A. (When a type like List has only one covariant type parameter, you’ll often hear the shorthand expression “Lists are covariant” and similarly for types with a single contravariant type parameter.)

Good point, and your right that the next example makes the point. Will clarify.
— deanwampler (2009-07-01 08:51:32)

Comment on 'Type Bounds'

2009-07-01T08:47:41-07:00

Type Bounds

Here, too, least rather than greatest.
— hellige (2009-07-01 08:47:41)

Comment on 'Type Bounds'

2009-07-01T08:47:11-07:00

Type Bounds

Don't say "parser": the parser is not the type-checker, and I think it's needlessly confusing. Just say "the compiler will infer..."

Also, this should be the "least common supertype," not the greatest. The greatest common supertype is always Any.
— hellige (2009-07-01 08:47:11)

Comment on 'Understanding Parameterized Types'

2009-07-01T08:36:22-07:00

Understanding Parameterized Types

Sometimes, a parameterized type like List is called a type constructor, because it is used to create specific types. For example, List is the type constructor for List[String] and List[Int], which are different types. (Although they are actually implemented with the same byte code due to type erasure.) In fact, it’s more accurate to say that all traits and classes are type constructors. Those without type parameters are effectively zero-argument, parameterized types.

Will follow up with you. Not sure I agree, but I could be wrong. Has happened in the past ;)
— deanwampler (2009-07-01 08:36:22)

Comment on 'Reflecting on Types'

2009-07-01T08:34:44-07:00

Reflecting on Types

x.isInstanceOf[T] will return true if the instance x is of type T. However, this test is subject to type erasure. For example, List(3.14159).isInstanceOf[List[String]] will return true, because the type parameter of List is lost at the byte code level. However, you’ll get an “unchecked” warning from the compiler.

Good idea. will add...
— deanwampler (2009-07-01 08:34:44)

Comment on 'Reflecting on Types'

2009-07-01T08:30:23-07:00

Reflecting on Types

Note that these methods are only available on subtypes of AnyRef.

That's probably true, although "C.class" won't compile in Scala. What I just noticed however, is that classOf[C] and c.getClass return slightly different things: scala> classOf[C] res0: java.lang.Class[C] = class C

scala> c.getClass res1: java.lang.Class[_] = class C

scala> C.class :1: error: identifier expected but 'class' found. C.class

Will need to comment that...
— deanwampler (2009-07-01 08:30:23)

Comment on 'Type Bounds'

2009-07-01T08:29:56-07:00

Type Bounds

Not to mention the fact that "sub-" and "super-" imply a vertical ordering... ;)
— hellige (2009-07-01 08:29:56)

Comment on 'Variance Under Inheritance'

2009-07-01T08:25:20-07:00

Variance Under Inheritance

I find the last few paragraphs somewhat confusing. The talk about "substituting the supertype" and so on sort of seems to imply substituting a value of that type, which is not what you mean. Also, the setup with the applyFunc function adds extra complication. I think it might be clearer if you just show a series of assignments: val f: C => C = (x:C) => c val f2: C => C = (x:CSuper) => cSub val f3: C => C = (x:CSub) => c // illegal This focuses on the essentials, which to me at least, makes it clearer.

The following paragraphs are much clearer and give a good intuition.
— hellige (2009-07-01 08:25:20)

Comment on 'Variance Under Inheritance'

2009-06-30T15:03:26-07:00

Variance Under Inheritance

The traits FunctionN, for N equals 0 to 22, are used by Scala to implement function values as true objects. Let’s pick Function1 as a representative example. It is declared trait Function1[-T, +R].

Example of my last comment. Given what you've said so far, I don't know what to say: is Function1 covariant or contravariant? I'm confused! Of course the answer is it's contravariant in T and covariant in R...
— hellige (2009-06-30 15:03:26)

Comment on 'Variance Under Inheritance'

2009-06-30T15:01:36-07:00

Variance Under Inheritance

I would explicitly state that it doesn't really make sense to say that a type by itself is co/contra-variant: it only makes sense to say that it is covariant with respect to a particular parameter. Then I'd note that sometimes we're sloppy for types with one parameter (like List) and we just say "List is covariant" rather than "List is covariant in its only parameter".

I realize that it sounds stuffy and pedantic, but I think it's better to be clear and explicit: this stuff is confusing enough already!
— hellige (2009-06-30 15:01:36)

Comment on 'Understanding Parameterized Types'

2009-06-30T14:54:20-07:00

Understanding Parameterized Types

This terminology seems off to me. I would instead say that "List" is a type constructor, because it is used to create specific types. I don't know of any specific jargon for a declaration like "List[+A]", it's just a regular type declaration that happens to declare a type with an argument.

In fact, technically, Int is usually regarded as a type constructor as well, so I find this whole thing a little confused. In any case I don't think it matches standard usage. Feel free to email me if you like.
— hellige (2009-06-30 14:54:20)

Comment on 'Reflecting on Types'

2009-06-30T14:44:01-07:00

Reflecting on Types

Maybe worth mentioning that it will also issue a warning...
— hellige (2009-06-30 14:44:01)

Comment on 'Reflecting on Types'

2009-06-30T14:42:43-07:00

Reflecting on Types

Note that these methods are only available on subtypes of AnyRef.

Actually isn't it rather that classOf[C] == C.class?
— hellige (2009-06-30 14:42:43)