Ch 7 Solutions code commented out to start exercise

[oldfartdeveloper]

Issue #109

[milesfrain]

I'm thinking it would be better to just let this be an implicit import (no parens, like Prelude), then you don't have to touch it when implementing the solutions.

[milesfrain]

To make solutions management easier when rebasing on master, I think it would be best to try to minimize interleaving of new and existing code in this file with the following changes:

• No instructions comments in this file
• Move all existing code to a test/Starter.purs which this solutions file can include implicitly.

That way, we'll minimize edits to this solutions file when making changes to master branch.

[milesfrain]

An example of this vision of minimum edits is Ch4, where there's just a single block of changes for test/Solutions.purs and a comment removed from test/Main.purs

The Ch6 test/Solutions.purs file requires some existing starter code in the module because we can't import the type definitions from another module, then define them in the solutions module, as that would be creating orphan instances. But the diff can be converted into a single block by just putting all the new code at the top of the file, rather than interleaving. Hopefully that won't make reading the solutions too difficult.

[oldfartdeveloper]

@milesfrain I'm running into scoping problems when I try to do your suggestion.

Here's the simple case:

In test/Solutions.purs

module Test.Solutions where

import Prelude
import Test.Starter

then

module Test.Starter where

import Prelude
import Data.AddressBook
  ( Address
  , PhoneNumber
  )
import Data.Maybe
  ( Maybe
  )

lift3 ::
  forall a b c d f.
  Apply f =>
  (a -> b -> c -> d) ->
  f a ->
  f b ->
  f c ->
  f d
lift3 f x y z = f <$> x <*> y <*> z

data Tree a
  = Leaf
  | Branch (Tree a) a (Tree a)

type Person'
  = { firstName :: String
    , lastName :: String
    , homeAddress :: Maybe Address
    , phones :: Array PhoneNumber
    }

person' :: String -> String -> Maybe Address -> Array PhoneNumber -> Person'
person' firstName lastName homeAddress phones = { firstName, lastName, homeAddress, phones }

I get two warnings as follows:

 ch7-master-problem ●  spago test
[info] Installation complete.
Compiling Test.Starter
Compiling Test.Solutions
Warning 1 of 2:

  in module Test.Solutions
  at test/Solutions.purs:3:1 - 3:15 (line 3, column 1 - line 3, column 15)

    The import of Prelude is redundant


  See https://github.com/purescript/documentation/blob/master/errors/UnusedImport.md for more information,
  or to contribute content related to this warning.

Warning 2 of 2:

  in module Test.Solutions
  at test/Solutions.purs:4:1 - 4:20 (line 4, column 1 - line 4, column 20)

    The import of Test.Starter is redundant


  See https://github.com/purescript/documentation/blob/master/errors/UnusedImport.md for more information,
  or to contribute content related to this warning.


[info] Build succeeded.
→ Suite: Verify eqPhoneType in AddressBook to verify initial passing solutions tests
  ✓ Passed: HomePhone and HomePhone are equal
  ✓ Passed: HomePhone and WorkPhone are not equal

All 2 tests passed!

If I remove the import Prelude from Starter.purs, then I get an error:

 ch7-master-problem ●  spago test
[info] Installation complete.
Compiling Test.Starter
Error found:
in module Test.Starter
at test/Starter.purs:13:3 - 13:10 (line 13, column 3 - line 13, column 10)

  Unknown type class Apply

If I instead remove import Prelude from Solutions.purs, I get.

 ch7-master-problem ●  spago test
[info] Installation complete.
Compiling Test.Starter
Compiling Test.Solutions
Warning found:
in module Test.Solutions
at test/Solutions.purs:3:1 - 3:20 (line 3, column 1 - line 3, column 20)

  The import of Test.Starter is redundant

Seems I always have to tolerate warnings or errors. Is tolerating warnings part of your approach here?

[oldfartdeveloper]

@milesfrain Ahh, I get a sense of what you're doing in what you modified in Chapter 4. You are accepting warnings. If the tests are written adequately, the reader will know what to name the function to be written in the exercise and will have a good idea of what its arguments are. I'll update appropriately.

[milesfrain]

The Test.Starter module might actually be completely unnecessary for Ch7.

• No need to re-define lift3, as it's already built-in.
• Tree needs to be defined in Test.Solutions anyway in order to write instances for it (no orphan instances allowed).
• Not sure what that person' stuff is for. Could probably just get rid of it.

[oldfartdeveloper]

@milesfrain you might be right. The reason for person' stuff is for the initial "prove test is set up correctly" by using the added derive for eqPhoneType introduced for Data.AddressBook. I realize now it's a "decoy" and will go back to the simple unit test instead.

[oldfartdeveloper]

@milesfrain Have made the above change.