Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modified showPiece to use lookup table #16

Closed
wants to merge 3 commits into from
Closed

Modified showPiece to use lookup table #16

wants to merge 3 commits into from

Conversation

PatrickLerner
Copy link

showPiece now uses the same typeList lookup table that readPiece uses.

Patrick Lerner added 3 commits August 13, 2012 00:32
showPiece now uses the same typeList lookup table that readPiece uses.
This reverts commit 3f2a2b1.
showPiece now uses the same typeList lookup table that readPiece uses.
@paulcc
Copy link

paulcc commented Aug 13, 2012

Consider: where do the errors (or the possibility) come from?

Basically, from the potential for mismatch between the constructors in the type-map and the ones defined. We can simplify this by defining one function for converting Pieces to (lower-case) chars and then construct the type-map from this.

ie
letter_for King = 'k'
letter_for Queen = 'q'

type_map = map (\p -> (letter_for p, p)) [minBound .. maxBound]

NB you need to add "deriving (Enum, Bounded, ...)" somewhere

then, any missing char for a piece is a run-time error (missing case for letter_for) OR could even be caught at compile time if you have the right warnings turned on.

also it might help to push the colour handling elsewhere, eg with

color_fn White = id
color_fn Black = upcase

so you can then say

showPiece (Piece col thing) = color_fn col $ letter_for thing

You might call this "defensive programming" - ie anticipating where errors might occur and coding in a way to prevent them being an issue

@reinh
Copy link
Contributor

reinh commented Aug 14, 2012

@paulcc Thanks very much for your comments!

As a simple product type composed of sum types, it's trivial to prove that a function over Piece is total. One simply must ensure that each possible piece (the cartesian product colors x types ) in the domain is mapped. If the function from Piece is provably total then a runtime error based on a missing piece mapping is impossible. It should be possible, then, to prove both the totality and correctness of, say:

letterFor :: Piece -> Char
letterFor (Piece color ptype) = colorize letter
  where colorize = case color of
                     White -> toUpper
                     Black -> id
        letter = fromJust $ lookup ptype letterList
        letterList = map swap typeList

where colorize is a total function over PColor and letter is a total function over PType, and the two are composed into a total function over Piece.

In lieu of a formal proof, I think QuickCheck could do a great job exercising this code if Piece, PColor and PType are made instances of Arbitrary.

@reinh reinh mentioned this pull request Aug 14, 2012
@reinh
Copy link
Contributor

reinh commented Aug 16, 2012

@benjaminfjones Yes, it would be better to do that at the top-level.

@PatrickLerner PatrickLerner closed this by deleting the head repository Oct 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants