tempusfugit (144) [Avatar] Offline
#1
v3 code.zip
Given that the archive contains a __MACOSX folder I was a bit surprised that the index.html files had DOS line endings rather than Unix line endings.
In the past I worked off of https://github.com/rtfeldman/elm-in-action, this is the first time I've used the code.zip file as a cross reference.

Page 92(96):
4.1.2 Resolving Data Dependencies >> Fixing SelectByIndex

It may be clearer in the SelectByIndex code sample to show that we are in the update function

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        SelectByIndex index ->
            let
...


Without that initial bit of context I wasn't sure at first where we were - scanning through source code I primarily focus on the function names in the declarations - not the "SelectByIndex" buried somewhere inside a function body.

page 93(97):
4.1.2 Resolving Data Dependencies >> Using the Pipeline Operator

As I already mentioned previously - (|>) forward function application is being colloquially referred to as "the Pipeline operator" without even mentioning the "official jargon". The term "Pipeline operator" seems to see use in NoRedInk packages but doesn't seem to appear in the official core documentation. In the interest of fostering a common language within the community I would suggest to stick with the official terminology - i.e. forward function application.

I conceed that in the context of the discussion "Pipeline operator" may seem more expressive but I think it is better practice to use the official jargon with Elm neophytes. For the sake of the discussion it may make sense to mention in passing: "You can think of forward function application as a 'Pipeline operator'" but to stick to forward function application past that point. This doesn't have to effect the use of "pipeline style" as in figure 4.2 "pipeline style vs. without forward function application" (rather than "without pipelines").

Page 99(103):
4.2.2 Handling HTTP Responses >> Using Type Aliases To Create Records
It also gives us a convenience function whose job is to build Photo record instances.

Why the beating around the bush? The child has a name - "record constructor", see: Type Aliases · An Introduction to Elm
When you create a type alias specifically for a record, it also generates a record constructor.

Lets use it. Similarly page 100(104):
the Model function accepts three arguments instead of one

versus
the Model record constructor accepts three arguments instead of one

Page 101(105):
4.2.2 Handling HTTP Responses >> Pattern Matching
Pattern matching is a way of destructuring values based on how their containers look.

See: http://blog.fogus.me/2011/01/12/pattern-matching-vs-destructuring-to-the-death/#comment-23455
Pattern matching is a conditional construct and destructuring isn’t.
follow up

Phrased differently - destructing is necessary for pattern matching but it isn't sufficient. So destructuring "extracts" the values from the "shape" of the type instance. In addition pattern matching conditionally branches based on the values found in the destructured type instance.

Page 102(106):
4.2.3 Sending HTTP Requests
Back in Section 2.2.1 of Chapter 2, we noted that an anonymous function like (\foo -> bar baz foo) can always be rewritten as (bar baz) by itself.

I think some name dropping may be helpful here:
Back in Section 2.2.1 of Chapter 2, we noted that thanks to partial application (\foo -> bar baz foo) can always be rewritten as (bar baz).


Page 105(109):
4.2.4 Gracefully Handling Errors
Have update set this error message when it receives a ReportError message.
NOTE We need the Just here because we’re storing loadingError in our Model as a Maybe String whereas ReportError holds a plain String.
ReportError comes out of nowhere here. Back on p.97(101) the Err constructor parameter was named errValue and on p.98(102) it's type bound to it is Http.Error as per LoadPhotos (Result Http.Error String). So I guess we are dealing with a LoadPhotos (Err (errValue : Http.Error)) message where Http.Error:

type Error
    = Timeout
    | NetworkError
    | UnexpectedPayload String
    | BadResponse Int String


- i.e. Http.Error isn't a plain String. Seems to me that ReportError is the (function that generates the) String which is formulated based on the content of the received Http.Error instance.

to be continued ...