Comments on Programming Scala

Comment on 'Inferring Type Information'

2009-08-05T16:00:15-07:00

Inferring Type Information

Running this script returns the following error.

You also forgot to change the comment text. It still refers to the "joiner" example above.
— derekmahar (2009-08-05 16:00:15)

Comment on 'Inferring Type Information'

2009-07-26T16:25:05-07:00

Inferring Type Information

By the way, where did that () come from that was printed before we fixed the bug? It is actually the real name of the singleton instance of the Unit type! (This name is a functional programming convention.)

When the return type of a method is inferred and you don’t use an equals sign

Implies that the return type can be specified without an equals sign as

def two():Int { 2 }

which is incorrect, results in a compile error
— maddalab (2009-07-26 16:25:05)

Comment on 'Inferring Type Information'

2009-07-26T14:27:36-07:00

Inferring Type Information

Since the second joiner method calls the first, it requires an explicit String return type. It should look like this.

Some where along the way you went from a method that has an argument of List[String] to a method that has an var age String*

Code def joiner(strings: List[String]) = joiner(strings, " ")

Compiler Errors def joiner(strings: String*) = joiner(strings.toList)
— maddalab (2009-07-26 14:27:36)

Comment on 'Method Declarations'

2009-07-26T13:39:28-07:00

Method Declarations

Why is this useful? First, if you choose good names for the method arguments, then your calls to those methods document each argument with a name. For example, compare the two lines with comments #1 and #2. In the first line, it may not be obvious what the second, " " argument is for. In the second case, we supply the name separator, which suggests the purpose of the argument.

Dope, Spoke to soon, Sorry about that
— maddalab (2009-07-26 13:39:28)

Comment on 'Method Declarations'

2009-07-26T13:38:17-07:00

Method Declarations

Example should include

StringUtils.joiner(separator="|", strings=List("Programming", "Scala"))

with named argument one could avoid positional arguments entirely
— maddalab (2009-07-26 13:38:17)

Comment on 'Organizing Code in Files and Namespaces'

2009-07-14T19:51:51-07:00

Organizing Code in Files and Namespaces

The following example defines a class MyClass in a package com.example.mypkg using the conventional Java syntax.

Might be nice to indicate that Java syntax also works the Java way: it applies to whole file, it has to come first, etc. At first I wasn't certain if it worked more like the Ruby private keyword, where the package would apply until you declared another.
— jrduncans (2009-07-14 19:51:51)

Comment on 'Importing Types and Their Members'

2009-07-14T09:24:43-07:00

Importing Types and Their Members

There’s one other important thing to know about imports; they are relative. The following imports are all the same.

This paragraph is confusing. It would be fine to note, that it's not relative in a way e. g. hrefs are relative, but instead "a package reference starting in a name p will be looked up in the closest enclosing scope that defines a member named p." (Scala Language Reference p. 118)
— hotdog (2009-07-14 09:24:43)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-07-14T05:08:55-07:00

Option, Some, and None: Avoiding nulls

The contains method is also defined for Map. It returns true if the map contains a value for the specified key. The getValue method is intended to be an internal method that retrieves the value from the underlying storage, whatever it is.

Some is a case class, so the new keyword is unnecessary. If you just don't want to get into that yet, it does make sense to leave it in.
— GatesDA (2009-07-14 05:08:55)

Comment on 'Organizing Code in Files and Namespaces'

2009-07-12T19:00:06-07:00

Organizing Code in Files and Namespaces

Scala adopts the package concept that Java uses for namespaces, but Scala offers a more flexible syntax. Just as file names don’t have to match the type names, the package structure does not have to match the directory structure. So, you can define packages in files independent of their “physical” location.

We get into this later on.
— deanwampler (2009-07-12 19:00:06)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-07-12T18:59:46-07:00

Option, Some, and None: Avoiding nulls

We also show the alternative method, getOrElse, in the last two println statements. This method returns either the value in the Option, if it is a Some instance, or it returns the second argument we passed to getOrElse, if it is a None instance. In other words, the second argument to getOrElse functions as the default return value.

Will improve the wording. thanks.
— deanwampler (2009-07-12 18:59:46)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-07-12T18:57:35-07:00

Option, Some, and None: Avoiding nulls

Most languages have a special keyword or object that’s assigned to reference variables when there’s nothing else for them to refer to. In Java, this is null; in Ruby, it’s nil. In Java, null is a keyword, not an object, and thus it’s illegal to call any methods on it. But this is a confusing choice on the language designer’s part. Why return a keyword when the programmer expects an object?

Yes. I didn't mean to imply it wasn't ;)
— deanwampler (2009-07-12 18:57:35)

Comment on 'Tuples'

2009-07-12T18:56:51-07:00

Tuples

Running this script with scala produces the following output.

True. I went for the "dumber", but slightly clearer approach here.
— deanwampler (2009-07-12 18:56:51)

Comment on 'Literals'

2009-07-12T18:55:29-07:00

Literals

Copy and paste these strings into the scala interpreter. Do the same for the previous string examples. How are they interpreted differently?

Thanks. Will fix.
— deanwampler (2009-07-12 18:55:29)

Comment on 'Inferring Type Information'

2009-07-12T18:53:41-07:00

Inferring Type Information

Why did the second command print () instead of 4? Look carefully at what the scala interpreter said the first command returned, double (Int)Unit. We defined a method named double that takes an Int argument and returns Unit. The method doesn’t return an Int as we would expect.

Right, absent minded typing... changing to void.
— deanwampler (2009-07-12 18:53:41)

Comment on 'Inferring Type Information'

2009-07-12T18:47:52-07:00

Inferring Type Information

Another way to prevent these problems is to always declare return types for methods, especially when defining methods for a public API. Let’s revisit our StringUtil example and see why explicit declarations are a good idea (adapted from [Smith2009a]).

Fixed.
— deanwampler (2009-07-12 18:47:52)

Comment on 'Inferring Type Information'

2009-07-12T18:41:05-07:00

Inferring Type Information

Running this script returns the following error.

Thanks. changed the example, but not the text. Doh!
— deanwampler (2009-07-12 18:41:05)

Comment on 'Inferring Type Information'

2009-07-12T18:40:47-07:00

Inferring Type Information

We intended for makeList to return a List[String], but when strings.length equals zero, we returned List(0), incorrectly “assuming” that this expression is the correct way to create an empty list. In fact, we returned a List[Int] with one element, 0. We should have returned List(). Since the else expression returns a List[String], the result of strings.toList, the inferred return type for the method is the closest common super type of List[Int] and List[String], which is List[Any]. Note that the compilation error doesn’t occur in the function definition. We only see it when we attempt to assign the value returned from makeList to a List[String] variable.

Thanks. See my previous comment reply...
— deanwampler (2009-07-12 18:40:47)

Comment on 'Inferring Type Information'

2009-07-12T18:34:44-07:00

Inferring Type Information

The two joiner methods concatenate a List of strings together. The first method also takes an argument for the separator string. The second method calls the first with a “default” separator of a single space.

Doh. You're right. I changed the example and didn't update the text. Will fix. Thanks.
— deanwampler (2009-07-12 18:34:44)

Comment on 'Method Declarations'

2009-07-12T18:31:20-07:00

Method Declarations

The second method calls itself recursively, passing an accumulator parameter, where the result of the calculation is “accumulated”. Note that we return the accumulated value when the counter i reaches 1. (We’re ignoring invalid negative integers. The function actually returns 1 for i < 0.) After the definition of the nested method, factorial calls it with the passed-in value i and the initial accumulator value of 1.

Will fix these. Thanks.
— deanwampler (2009-07-12 18:31:20)

Comment on 'Method Declarations'

2009-07-12T18:29:20-07:00

Method Declarations

OptionalUserProfileInfo represents all the “optional” user profile data in your next Web 2.0, social networking site. It defines default values for all its fields. The script creates instances with zero or more named parameters. The order of those parameters is arbitrary.

Thanks. We caught and fixed that one.
— deanwampler (2009-07-12 18:29:20)

Comment on 'Method Declarations'

2009-07-12T18:27:33-07:00

Method Declarations

We said “optional argument lists”, meaning more than one. Scala lets you define more than one argument list for a method. This is required for currying methods, which we’ll discuss in the section called “Currying” in Chapter 8, Functional Programming in Scala. It is also very useful for defining your own domain-specific languages (DSLs), as we’ll see in Chapter 11, Domain-Specific Languages in Scala. Note that each argument list is surrounded by parentheses and the arguments are separated by commas.

Will fix.
— deanwampler (2009-07-12 18:27:33)

Comment on 'Variable Declarations'

2009-07-12T18:26:42-07:00

Variable Declarations

Scala also requires you to initialize a var when it is declared. You can assign a new value to a var as often as you want. Again, to be precise, the stockPrice reference can be changed to point to a different Double object (e.g., 10.). In this case, the object that stockPrice refers to can’t be changed, because Doubles in Scala are immutable.

Adding "in Scala" -> "... Doubles in Scala are immutable." Not a complete explanation, but a reasonable change at this late date and it implies that Doubles are immutable by design in Scala.
— deanwampler (2009-07-12 18:26:42)

Comment on 'Inferring Type Information'

2009-07-11T10:46:48-07:00

Inferring Type Information

Isn't it more common to make the comparison of Unit to Void?
— jwolski (2009-07-11 10:46:48)

Comment on 'Inferring Type Information'

2009-07-11T10:37:48-07:00

Inferring Type Information

The code listing (method-overloaded-return-script.scala) seems out of sync with the text: (1) the second joiner is taking a list of strings (2) the first joiner doesn't have a default value for separator (which doesn't match the "def joiner(strings: String*) = joiner(strings.toList)" below
— myee (2009-07-11 10:37:48)

Comment on 'Organizing Code in Files and Namespaces'

2009-07-10T03:24:08-07:00

Organizing Code in Files and Namespaces

Maybe it should be mentioned here that when you compile a file with a package definition in it, the scalac compiler creates a sibdirectory and puts the .class files in it (I don't think that javac does the same ).
— bieffe (2009-07-10 03:24:08)

Comment on 'Inferring Type Information'

2009-07-09T15:42:43-07:00

Inferring Type Information

Recall from Chapter 1 that Scala uses square brackets ([…]) for generic type parameters. We specify Map[Integer, String] on the left-hand side of the equals sign. (We are sticking with Java types for the example.) On the right-hand side, we instantiate the actual type we want, a HashMap, but we don’t have to repeat the type parameters.

@Tim, fair point. I was sticking with Java types, since that's how I started out in this bit. Should say as much
— deanwampler (2009-07-09 15:42:43)

Comment on 'Semicolons'

2009-07-09T15:39:46-07:00

Semicolons

You might wonder why you don’t need curly braces ({…}) around the two statements after the case … => line. You can put them in if you want, but the compiler knows when you’ve reached the end of the “block” when it finds the next case clause or the curly brace (}) that ends the enclosing block for all the case clauses.

Most people leave them out when they can. Will consider adding more verbage about that.
— deanwampler (2009-07-09 15:39:46)

Comment on 'Variable Declarations'

2009-07-09T15:16:33-07:00

Variable Declarations

...or explain briefly why Doubles are immutable.
— derekmahar (2009-07-09 15:16:33)

Comment on 'Variable Declarations'

2009-07-09T14:40:55-07:00

Variable Declarations

Scala allows you to decide whether a variable is immutable (read-only) or not (read-write) when you declare it. An immutable “variable” is declared with the keyword val (think value object).

@Marek: I think the variable is actually immutable. The variable is the reference cell which refers to the object and the name is the identifier assigned to this cell. I agree with you that the name associated with the variable never changes (though you can create aliases using other references), so the name is immutable. I also agree with you that the object to which the variable refers is mutable. However, I disagree that the variable contents, which is a reference to the object and not the object itself is mutable. The "val" keyword applies to the variable, not to the name or the object.
— derekmahar (2009-07-09 14:40:55)

Comment on 'Method Declarations'

2009-07-09T10:08:38-07:00

Method Declarations

"The function actually return 1" => "The function actually returns 1" "the accumulator value of 1" => "an initial accumulator value of 1"
— GatesDA (2009-07-09 10:08:38)

Comment on 'Inferring Type Information'

2009-07-09T07:52:45-07:00

Inferring Type Information

The sentence "We intended for makeList to return a List[String], but the case 0 expression actually returns a List[Int]" mentions a "case 0" which does not exist, the example above contains an if-clause. Seems to me as if the example has changed. I would propose to use the comment "#1" in the example (which isn't referred to for any reason) and write instead "We intended for makeList to return a List[String], but the if-clause marked with "#1" actually returns a List[Int]".
— Marius (2009-07-09 07:52:45)

Comment on 'Method Declarations'

2009-07-06T05:56:04-07:00

Method Declarations

personalWebSite: String = OptionalUserProfileInfo.UnknownWebSite)
instead of? personalWebSite = OptionalUserProfileInfo.UnknownWebSite)

Haven't tried this on the scala 2.8 shell.
— parthm (2009-07-06 05:56:04)

Comment on 'Semicolons'

2009-07-06T05:37:59-07:00

Semicolons

Is there a style recommendation on using or not using braces with case that can be put in here? The preferred approach by the scala community.
— parthm (2009-07-06 05:37:59)

Comment on 'Tuples'

2009-06-23T10:17:42-07:00

Tuples

Scala, supports tuples, a grouping of two or more items, usually created with the literal syntax of a comma-separated list of the items inside parentheses, e.g., (x1, x2, …). The types of the x_i elements are unrelated to each other, you can mix and match types. These literal “groupings” are instantiated as scala.TupleN instances, where the N is the number of items in the tuple. The Scala API defines separate TupleN classes for N between 1 and 22, inclusive. Tuple instances are immutable, first-class values, so you can assign them to variables, pass them as values, and return them from methods.

Apparently, this: :5: error: value Tuple23 is not a member of package scala
— diathesis (2009-06-23 10:17:42)

Comment on 'Tuples'

2009-06-23T10:15:50-07:00

Tuples

What happens if you declare a tuple of size > 22?
— diathesis (2009-06-23 10:15:50)

Comment on 'Tuples'

2009-06-23T10:14:49-07:00

Tuples

You say "two or more items" at first, then "N between 1 and 22, inclusive". It would be nice to reconcile these statements. Does Scala not have the (1,) syntax for a single-element tuple?

Also, you say "first-class" as if it's of extreme importance, but we newbie readers have no idea what you're talking about. Either leave it out to be dealt with later, or give us a hint as to what the alternative would be.
— TimMacEachern (2009-06-23 10:14:49)

Comment on 'Literals'

2009-06-23T10:09:26-07:00

Literals

Floating point literals are expressions with zero or more digits, followed by a period ., followed by zero or more digits. If there are no digits before the period, i.e., the number is less than 1.0, then there must be one or more digits after the period. For Float literals, append the F or f character at the end of the literal. Otherwise, a Double is assumed. You can optionally append a D or d for a Double.

"are expresses" should presumably be "are expressed"
— diathesis (2009-06-23 10:09:26)

Comment on 'Literals'

2009-06-23T09:56:29-07:00

Literals

expresses => expressed
— TimMacEachern (2009-06-23 09:56:29)

Comment on 'Literals'

2009-06-23T09:53:40-07:00

Literals

Integer literals can be expresses in decimal, hexadecimal, or octal. The details are summarized in Table 2.1, “Integer literals.”.

expresses => expressed
— TimMacEachern (2009-06-23 09:53:40)

Comment on 'Inferring Type Information'

2009-06-23T09:40:05-07:00

Inferring Type Information

Actually, for this particular script, an alternative fix is to remove the return keyword from the line. It is not needed for the code to work properly, but it illustrates our point.

Seems like a discussion as to why a return requires type annotation would be useful.
— diathesis (2009-06-23 09:40:05)

Comment on 'Inferring Type Information'

2009-06-23T08:53:46-07:00

Inferring Type Information

You didn't have a StringUtil example, you had a NameUtil example.
— TimMacEachern (2009-06-23 08:53:46)

Comment on 'Inferring Type Information'

2009-06-23T08:45:33-07:00

Inferring Type Information

So now the reader is wondering: "Why's he using Int in one place and Integer in another?"
— TimMacEachern (2009-06-23 08:45:33)

Comment on 'Variable Declarations'

2009-06-23T08:28:08-07:00

Variable Declarations

Perhaps it would be better to say: "In this case, the value inherent in the object that stockPrice refers to can't be changed...".
— TimMacEachern (2009-06-23 08:28:08)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-06-20T07:39:44-07:00

Option, Some, and None: Avoiding nulls

'the argument we passed to getOrElse'? Don't get the last sentence.
— robcd (2009-06-20 07:39:44)

Comment on 'Literals'

2009-06-20T06:43:59-07:00

Literals

Copy and paste these strings into the scala interpreter. Do the same for the previous string examples. How are they interpreted differently?

Copy and paste
— robcd (2009-06-20 06:43:59)

Comment on 'Inferring Type Information'

2009-06-20T06:10:11-07:00

Inferring Type Information

Running this script returns the following error.

Did you copy-and-paste the previous example, by any chance?
— robcd (2009-06-20 06:10:11)

Comment on 'Method Declarations'

2009-06-19T09:16:27-07:00

Method Declarations

"each argument is" => "each argument list is"
— bfollek (2009-06-19 09:16:27)

Comment on 'Variable Declarations'

2009-06-19T09:10:24-07:00

Variable Declarations

Scala encourages you to use immutable values whenever possible. As we will see, this promotes better object-oriented design and it is consistent with the principles of “pure” functional programming. It may take some getting used to, but you’ll find a newfound confidence in your code when it is written in an immutable style.

In the Notes that follows:

"the referred to object is mutability" should be "the object referred to is mutable"
— bfollek (2009-06-19 09:10:24)

Comment on 'Tuples'

2009-06-14T14:33:57-07:00

Tuples

Running this script with scala produces the following output.

stay DRY: You can avoid repeating the "print the X item" statements using some cute loop like this

(1 to tupleator.productArity).map((i:Int)=>"Print item number "+i+": "+tupleator.productElement(i-1)).foreach(println(_))
— javiervegeas (2009-06-14 14:33:57)

Comment on 'Organizing Code in Files and Namespaces'

2009-06-10T01:24:03-07:00

Organizing Code in Files and Namespaces

... those files (declaring the same package) even dont have to reside in the same directory but could be spread all over the directory structure.
— magle (2009-06-10 01:24:03)

Comment on 'Tuples'

2009-06-09T08:35:07-07:00

Tuples

The tupleator method simply returns a “3-tuple” with the input arguments. The first statement that uses this method assigns the returned tuple to a single variable t. The next four statements print t in various ways. The first print statement calls Tuple3.toString, which wraps parentheses around the item list. The following three statements print each item in t separately. The expression t._N retrieves the N item, starting at 1, not 0 (this choice follows functional programming conventions).

ups ... forget my last comment!

Just saw, that it's already there :o)
— magle (2009-06-09 08:35:07)

Comment on 'Tuples'

2009-06-09T08:26:08-07:00

Tuples

Maybe it's a bit early here (concerning Pattern), but using t._N isn't considered good style imho. You could instead use Pattern Matching when declaring your tuple variables like this:

val (myFirstItem, mySecondItem, myThirdItem) = tupleator("Hello", 1, 2.3)

Now you could refer to each item using the given identifier separately, like

println("Print the first item: " + myFirstItem ) println("Print the second item: " + mySecondItem ) println("Print the third item: " + myThirdItem )
— magle (2009-06-09 08:26:08)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-06-09T03:38:59-07:00

Option, Some, and None: Avoiding nulls

Actually nil is an object in Ruby (instance of NilClass).
— Martin_Suesskraut (2009-06-09 03:38:59)

Comment on 'Literals'

2009-06-09T01:49:09-07:00

Literals

For Long literals, it is necessary to append the L or l character at the end of the literal. Otherwise, an Int is used. The valid values for an integer literal are bounded by the type of the variable to which the value will be assigned. Table 2.2, “Ranges of allowed values for integer literals (boundaries are inclusive).” defines the limits, which are inclusive.

There is a dot within the last sentence (behind "inclusive)")
— Martin_Suesskraut (2009-06-09 01:49:09)

Comment on 'Inferring Type Information'

2009-06-09T00:54:41-07:00

Inferring Type Information

What happened? When the client was compiled, StringUtil.toCollection returned an Array. Then toCollection was changed to return List. In both versions, the method return value was inferred. Therefore, client should have been recompiled, too.

Shouldn't the comma between "scala" and "collection" be a dot?
— Martin_Suesskraut (2009-06-09 00:54:41)

Comment on 'Abstract Types And Parameterized Types'

2009-06-07T18:09:09-07:00

Abstract Types And Parameterized Types

Scala supports another type abstraction mechanism called abstract types, used in many functional programming languages, such as Haskell. Abstract types were also considered for inclusion in Java when generics were adopted. We want to introduce them now, because you’ll see many examples of them before we dive into their details in Chapter 12, The Scala Type System. For a very detailed comparison of these two mechanisms, see [Bruce1998].

Right. Will fix.
— deanwampler (2009-06-07 18:09:09)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-06-07T18:08:47-07:00

Option, Some, and None: Avoiding nulls

The convenient -> syntax for defining name-value pairs to initialize a Map will be discussed in the section called “The Predef Object” in Chapter 7, The Scala Object System. For now, we want to focus on the two groups of println statements, where we show what happens when you retrieve the values from the map. If you run this script with the scala command, you’ll get the following output.

Sorry. Now fixed.
— deanwampler (2009-06-07 18:08:47)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-06-07T18:08:34-07:00

Option, Some, and None: Avoiding nulls

To be more consistent with the goal of making everything an object, as well as to conform with functional programming conventions, Scala encourages you to use the Option type for variables and function return values when they may or may not refer to a value. When there is no value, use None, an object that is a subclass of Option. When there is a value, use Some, which wraps the value. Some is also a subclass of Option.

No problem. Thanks for going to the trouble...
— deanwampler (2009-06-07 18:08:34)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-06-07T18:08:17-07:00

Option, Some, and None: Avoiding nulls

We’ll discuss the standard type hierarchy for Scala in the section called “The Scala Type Hierarchy” in Chapter 7, The Scala Object System. However, three useful classes to understand now are the Option class and its two subclasses, Some and None.

@Tobias, an unfortunate production error that has been fixed. Sorry. @Parth, we're working on putting numbers in the print version.
— deanwampler (2009-06-07 18:08:17)

Comment on 'Literals'

2009-06-07T18:07:32-07:00

Literals

A symbol literal is a single quote ', followed by a letter, followed by zero or more digits and letters. Note that an expression like '1 is invalid, because the compiler thinks it is an incomplete character literal.

@Ariel. Right. Will clarify. @Parth. Will add a bit more on when they are typically used.
— deanwampler (2009-06-07 18:07:32)

Comment on 'Inferring Type Information'

2009-06-07T18:05:55-07:00

Inferring Type Information

Note the equals sign before the body of double. Now, the output says we have defined double to return an Int and the second command does what we expect it to do.

Good point. Will add a paragraph for it.
— deanwampler (2009-06-07 18:05:55)

Comment on 'Inferring Type Information'

2009-06-07T18:04:27-07:00

Inferring Type Information

Bug. will fix. Thanks!
— deanwampler (2009-06-07 18:04:27)

Comment on 'Inferring Type Information'

2009-06-07T18:04:07-07:00

Inferring Type Information

If you compile these files with scala, you can run the client as follows.

Reworking the example to remove this use of tuples.
— deanwampler (2009-06-07 18:04:07)

Comment on 'Inferring Type Information'

2009-06-07T18:03:37-07:00

Inferring Type Information

Pure functional languages like Haskell (see, e.g., [O'Sullivan2009]) use type inference algorithms like Hindley-Milner (see [Spiewak2008] for an easily digested explanation). Code written in these languages require type annotations less often than in Scala, because Scala’s type inference algorithm has to support object-oriented typing as well as functional typing. So, Scala requires more type annotations than languages like Haskell. Here is a summary of the rules for when explicit type annotations are required in Scala.

Rewording
— deanwampler (2009-06-07 18:03:37)

Comment on 'Inferring Type Information'

2009-06-04T14:40:54-07:00

Inferring Type Information

The toCollection method splits a string on spaces and returns an Array containing the substrings. The return type is inferred, which is a potential problem, as we will see. The method is somewhat contrived, but it will illustrate our point. Here is a client of StringUtil that uses this method.

I came up with a much simpler example.
— deanwampler (2009-06-04 14:40:54)

Comment on 'Inferring Type Information'

2009-06-04T14:15:06-07:00

Inferring Type Information

I'm considering a different example that doesn't require these features that haven't been discussed yet. Concerning numbers and labels, we already do that with some of the larger examples. We are evaluating the balance between too many labeled examples and too few.
— deanwampler (2009-06-04 14:15:06)

Comment on 'Inferring Type Information'

2009-06-04T11:44:11-07:00

Inferring Type Information

Running this script gives you the following error.

Doh! Thanks.
— deanwampler (2009-06-04 11:44:11)

Comment on 'Inferring Type Information'

2009-06-04T11:42:18-07:00

Inferring Type Information

Let’s look at examples where explicit declarations of method return types are required. In the following script, the upCase method has a conditional return statement for zero-length strings.

Actually, you aren't required to declare the return type. for example, implicit def int2String(i:Int) = i.toString works fine. However, it's actually a good idea to add the return type annotation anyway to avoid some potential subtle bugs when the method is refined over time.
— deanwampler (2009-06-04 11:42:18)

Comment on 'Inferring Type Information'

2009-06-04T11:33:54-07:00

Inferring Type Information

Thanks. will fix.
— deanwampler (2009-06-04 11:33:54)

Comment on 'Inferring Type Information'

2009-06-04T11:31:08-07:00

Inferring Type Information

Scala supports type inference (see, for example, [TypeInference] and [Pierce2002]). The language’s compiler can discern quite a bit of type information from the context, without explicit type annotations. Here’s the same declaration rewritten in Scala, with inferred type information.

We've been using the term parser, but yes, it's the compiler. Plan to fix.
— deanwampler (2009-06-04 11:31:08)

Comment on 'Method Declarations'

2009-06-04T11:29:54-07:00

Method Declarations

Good point. Expanded this section to discuss it.
— deanwampler (2009-06-04 11:29:54)

Comment on 'Method Declarations'

2009-06-03T14:36:35-07:00

Method Declarations

If a method body has more than one expression, you must surround it with curly braces {…}. You can omit the braces if the method body has just one expression.

Yes, ti should be expression. Thanks.
— deanwampler (2009-06-03 14:36:35)

Comment on 'Method Declarations'

2009-06-10T05:44:16-07:00

Method Declarations

We saw several examples in Chapter 1, Zero to Sixty: Introducing Scala of how to define methods, which are functions that are members of a class. Method definitions start with the def keyword, followed by optional argument lists, a colon character ‘:’ and the return type of the method, an equals sign ‘=’, and finally the method body. Methods are implicitly declared “abstract” if you leave off the equals sign and method body. The enclosing type is then itself abstract. We’ll discuss abstract types in more detail in Chapter 5, Basic Object-Oriented Programming in Scala.

Will fix.
— deanwampler (2009-06-10 05:44:16)

Comment on 'Variable Declarations'

2009-06-03T12:38:14-07:00

Variable Declarations

Scala allows you to decide whether a variable is immutable (read-only) or not (read-write) when you declare it. An immutable “variable” is declared with the keyword val (think value object).

@Reid, I think the most recent drafts use "inference" (my bad...)

@Marek. Yes, it should be more clear. I'll fix.
— deanwampler (2009-06-03 12:38:14)

Comment on 'Semicolons'

2009-06-03T12:37:07-07:00

Semicolons

You may have already noticed that there were very few semicolons in the code examples in the previous chapter. You can use semicolons to separate statements and expressions, as in Java, C, PHP, and similar languages. In most cases, though, Scala behaves like many scripting languages in treating the end of the line as the end of a statement or an expression. When a statement or expression is too long for one line, Scala can usually infer when you are continuing on to the next line, as shown in this example.

We didn't say it explicitly, but yes, anything optional tends to get left out ;) I'm not sure why the JS community prefers to have the semicolons after statements.
— deanwampler (2009-06-03 12:37:07)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-06-01T22:23:20-07:00

Option, Some, and None: Avoiding nulls

Oops. Sorry ... the above comment from me was premature.
— parthm (2009-06-01 22:23:20)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-06-01T22:21:26-07:00

Option, Some, and None: Avoiding nulls

It may be good to have a small example here. This kind of approach is used only in some languages like Haskell (type Maybe) and showing example code will help understand the use better.

scala> var x: Option[Int] = Some(1) x: Option[Int] = Some(1)

scala> var y: Option[Int] = None
y: Option[Int] = None

scala> def foo(z: Option[Int]) = { | z match {
| case Some(v) => v
| case None => -1
| } | } foo: (Option[Int])Int

scala> foo(x) res10: Int = 1

scala> foo(y) res11: Int = -1
— parthm (2009-06-01 22:21:26)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-06-01T22:14:02-07:00

Option, Some, and None: Avoiding nulls

The chapter/section number might be useful for "The Scala Type Hierarchy". Especially from the print copy.
— parthm (2009-06-01 22:14:02)

Comment on 'Literals'

2009-06-01T21:53:28-07:00

Literals

It may be good to mention what Symbols are used for in Scala. Coming form Lisp I understand Symbols (assuming its the same in Scala) but cant really understand their use in Scala. If this is discussed in a later chapter/section maybe a pointer to it can be put.
— parthm (2009-06-01 21:53:28)

Comment on 'Inferring Type Information'

2009-06-01T21:21:59-07:00

Inferring Type Information

It would be good to mention that the (string).r notation used above is the regex notation and creates a scala.util.matching.Regex
— parthm (2009-06-01 21:21:59)

Comment on 'Inferring Type Information'

2009-06-01T21:19:39-07:00

Inferring Type Information

If you compile these files with scala, you can run the client as follows.

It would be good to have a short note on the kv._1, kv._2 notation used above for people don't know about accessing scala tuples
— parthm (2009-06-01 21:19:39)

Comment on 'Inferring Type Information'

2009-06-01T21:15:24-07:00

Inferring Type Information

As Lists haven't been discussed in some detail at this point, 'head :: tail' pattern matching and Nil usage in the above example may be difficult to understand for someone who doesn't know about it already. Maybe a short note on that can be added.

Also, is addition numbers to code listings (Listing. N) planned?
— parthm (2009-06-01 21:15:24)

Comment on 'Inferring Type Information'

2009-06-01T21:02:37-07:00

Inferring Type Information

Running this script gives you the following error.

In the printlns, upper should be upCase
— parthm (2009-06-01 21:02:37)

Comment on 'Inferring Type Information'

2009-06-01T21:01:26-07:00

Inferring Type Information

On the first line we specify Map[Int, String]

You probably mean Map[Integer, String] above.
— parthm (2009-06-01 21:01:26)

Comment on 'Abstract Types And Parameterized Types'

2009-05-30T14:36:39-07:00

Abstract Types And Parameterized Types

Generics were added to Java in version 5.0, which was released in 2004, not in the late 90's.
— chifazo (2009-05-30 14:36:39)

Comment on 'Literals'

2009-05-30T13:38:31-07:00

Literals

Instead of saying: "because the parser thinks it is an incomplete integer literal", I think it should say: "because the parser thinks it is an incomplete character literal"
— chifazo (2009-05-30 13:38:31)

Comment on 'Literals'

2009-05-30T13:28:01-07:00

Literals

According to this definition, a single period "." would be a valid floating point literal. There must be at least one digit before or after the period.
— chifazo (2009-05-30 13:28:01)

Comment on 'Inferring Type Information'

2009-05-29T06:43:08-07:00

Inferring Type Information

Note the equals sign before the body of double. Now, the output says we have defined double to return an Int and the second command does what we expect it to do.

You may could mention the reason way methods without an equals sign always leads to return type Unit: Methods offering an equals sign are considered as functions which always return a value when called. Methods without an equals sign are considered as procedures which (only) produce some side effects. That said, those methods don't return any value and hence offer a return type Unit.
— magle (2009-05-29 06:43:08)

Comment on 'Method Declarations'

2009-05-26T02:58:35-07:00

Method Declarations

The nested method declares the same parameter name 'i' as the surrounding method, thus shadowing the parameter of the surrounding method. I'm not sure if this is done in full purpose here, since you're otherwise able to refer to the parameterlist of the surrounding method within the body of the nested method. May be better to use a different parameter name for the nested method even for the sake of clarity.
— magle (2009-05-26 02:58:35)

Comment on 'Inferring Type Information'

2009-05-25T11:06:09-07:00

Inferring Type Information

Wouldn't be "square" a more appropriate method name? Or def double(i: Int) = { 2 * i }

— battisti (2009-05-25 11:06:09)

Comment on 'Variable Declarations'

2009-05-24T15:41:20-07:00

Variable Declarations

Scala allows you to decide whether a variable is immutable (read-only) or not (read-write) when you declare it. An immutable “variable” is declared with the keyword val (think value object).

val only means that a variable cannot be re-assigned, therefore val a = new Array[Int](3) is still a mutable variable. I think the paragraph above should explain that it is the name that cannot be reassigned, not that the object bound to it becomes read-only in some magic way.
— Leonidas (2009-05-24 15:41:20)

Comment on 'Semicolons'

2009-05-24T15:32:01-07:00

Semicolons

So, the recommendation for Scala code is to leave the semicolons out, right? I'm asking because semicolons are can be included or left out in both Python and JavaScript, but in Python it is considered a bad habit to put them in and in JavaScript, it is good style to finish the statements with semicolons.

I want to write idiomatic Scala-code from day one, so it would be good to know a recommendation in this regard.
— Leonidas (2009-05-24 15:32:01)

Comment on 'Method Declarations'

2009-05-24T05:55:07-07:00

Method Declarations

If a method body has more than one expression, you must surround it with curly braces {…}. You can omit the braces if the method body has just one expression.

Shouldn't it be "has more than one expression" instead of "more than one statement"? According to the Scala Reference: "Both declarations and deﬁnitions produce bindings that associate type names with type deﬁnitions or bounds..." to associate something with something, you'd need an expression (i.e. something, that returns a value with a type to bind against) and not a statement which "just does something"
— battisti (2009-05-24 05:55:07)

Comment on 'Inferring Type Information'

2009-05-21T03:47:34-07:00

Inferring Type Information

"are not as mature" sounds like there's hope for a lot of improvement, which is not at all that clear to me.
— clojure (2009-05-21 03:47:34)

Comment on 'Variable Declarations'

2009-05-20T05:28:41-07:00

Variable Declarations

Scala allows you to decide whether a variable is immutable (read-only) or not (read-write) when you declare it. An immutable “variable” is declared with the keyword val (think value object).

type inferencer just doesn't sound right, perhaps it should be "Type inference can figure this one out easily."
— reidhoch (2009-05-20 05:28:41)

Comment on 'Inferring Type Information'

2009-05-20T04:01:04-07:00

Inferring Type Information

Let’s look at examples where explicit declarations of method return types are required. In the following script, the upCase method has a conditional return statement for zero-length strings.

3.d When the method is an implicit method that the compiler will automatically use to convert from one type to another.
— retronym (2009-05-20 04:01:04)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-05-20T04:00:26-07:00

Option, Some, and None: Avoiding nulls

Again two times "in"
— myrddin (2009-05-20 04:00:26)

Comment on 'Method Declarations'

2009-06-10T05:44:16-07:00

Method Declarations

'followed by an optional argument list in parenthesese' should be qualified with a footnote that refers to a later section showing methods with multiple argument lists and currying.
— retronym (2009-06-10 05:44:16)

Comment on 'Option, Some, and None: Avoiding nulls'

2009-05-20T03:50:42-07:00

Option, Some, and None: Avoiding nulls

Too times "in" at the end of the first sentence without the right object.
— myrddin (2009-05-20 03:50:42)

Comment on 'Inferring Type Information'

2009-05-20T03:00:35-07:00

Inferring Type Information

Actually it's the language's compiler that can discern quite a bit of type information.
— zefhemel (2009-05-20 03:00:35)