The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

tempusfugit (144) [Avatar] Offline
Looks great so far - thank you for embarking on this endeavour!

1.3.5 Operators

Page 19(23): "As Listing 3.4 demonstrates" - actually should refer to the "circled digit three" ( U+2778 ) in Listing 1.13

Page 20(24): Precedence issue already covered in another topic

Page 22 (26): 1.4.1 Lists; Table 1.4 Contrasting JavaScript Arrays and Elm Lists
  • The List.head [ "one fish", "two fish" ] entry may warrant a footnote, something like: "Actually Maybe.withDefault "no fish" (List.head [ "one fish", "two fish" ]) is closer to the truth but more on that later."

  • No arbitrary position-based element access may also warrant a footnote to re-assure the reader that there are different ways that will emerge later to get at the second or any other value in a list - it's just a matter of "Toto, I've a feeling we're not in Kansas anymore." Never know how functional programming neophytes may react to something "basic" like indexed element access not being available (especially in the sample chapter).

  • Page 27(31): 1.5 Summary
    This bullet has me puzzled:
    ( foo, bar ) destructures the first two fields of a tuple such as ( 2, 4, 6, 8 ). In this example, foo would be 2 and bar would be 4.

    > myTuple = ("2","4","6","8")
    ("2","4","6","8") : ( String, String, String, String )
    > let \
    |   (foo, bar) = myTuple \
    | in \
    |   foo ++ bar
    ==================================== ERRORS ====================================
    -- TYPE MISMATCH --------------------------------------------- repl-temp-000.elm
    `myTuple` is being used in an unexpected way.
    7|     (foo, bar) = myTuple 
    Based on its definition, `myTuple` has this type:
        ( String, String, String, String )
    But you are trying to use it as:
        ( a, b )
    rtfeldman (60) [Avatar] Offline
    Thanks, appreciate the feedback! I'll incorporate this into the next release.
    John Kirkham (2) [Avatar] Offline
    A minor spelling error in chapter 1, Section 1.2.3 "Booleans and Conditionals":
    In the third point, "insetad" should be "instead".
    John Kirkham (2) [Avatar] Offline
    Also Chapter 1, comparing Elm If-Expressions to JavaScript Terniaries.
    You talk about similarities between the 2 languages, but you should mention one very significant difference: type safety.
    As in languages like Haskell, each sub-expression (if/else clause) must return the same type.
    Something like:
    elfCount = if vacationingElves == 1 then 1 else "many"

    produces a compiler error because if and else expressions are returning different types, Int and String respectively. This is allowed in JavaScript but not Elm.
    The branches of this `if` produce different types of values.

    4| elfCount = if vacationingElves == 1 then 1 else "many"
    The `then` branch has type:


    But the `else` branch is:


    Hint: These need to match so that no matter which branch we take, we always get
    back the same type of value.

    Great work, by the way. Thanks,

    rtfeldman (60) [Avatar] Offline
    Thanks for the posts! I'll revise that for the next release (which will include Chapter 3 as well as revisions to chapters 1 and 2.)
    Richard Haven (8) [Avatar] Offline
    The requirement for both the if and the else to return the same types are more a feature of a typed language than about the if/else: JS allows different types because it will just duck them anyway.