exercism / haskell

Exercism exercises in Haskell.

Exercism Haskell Track

Exercism exercises in Haskell

• How to contribute
  • Git and GitHub
  • Report or fix a bug
  • Review issues and pull requests
  • Port or create an exercise
  • Port or create a concept
  • Port or create a concept exercise
  • Update an exercise test suite
• Repository structure and conventions
  • Directory structure
  • Practice exercise structure
  • Exercise versioning
• Development Dependencies
• Stub solution
• Example solution
• Test suite
• Running tests
• Running HLint
• Automated Test Runner

How to contribute

Git and GitHub

If you would like to contribute but lack experience with git and/or GitHub, try these resources:

• GitHub Guides: Understanding the GitHub flow
• GitHub Help: Creating a pull request from a fork
• Exercism's Git Basics

Report or fix a bug

Typical examples for a bug: A typo, a missing test case, an unclear or ambiguous problem description.

• If you are unsure whether you have really found a bug, just ask.
• To report a bug you can create an issue.
• If you already have a fix for it, you may submit a pull request.

Review issues and pull requests

If you have a dedicated opinion you are welcome to write a comment for an issue or a pull request.

Please be detailed and include reasons, links or arguments to support your opinion.

Port or create an exercise

Exercism contains two types of exercises: concept exercises, and practice exercises.

Haskell has some concept exercises. You can read about concept exercises and take part in creating Haskell's learning track.

You can get a full list of common Exercism practice exercises and cross-reference it with Haskell practice exercises and implement any of the missing ones for the Haskell track.

Port or create a concept

Concepts are short tutorials explaining a single feature of the language. The Haskell track has a few concepts currently developed and a list of additional concepts yet to be created. You can contribute by porting (from the F# or Elm tracks for example) or developing any of the topics listed in reference/concepts.md

Port or create a concept exercise

Each concept is accompanied by a concept exercise to test the student understood the basic use of the concept and unlock the next concept(s). To develop concept exercises see reference/implementing-a-concept-exercise.md

Update an exercise test suite

Most unit tests are shared between language tracks. You may update a test suite with new unit tests.

• Read about pushing new unit tests to Exercism.
• See a list of exercises from which new unit tests can be pulled to this track.
• Read about test suite principles.

Note that the whole test suite must run with the sample solution within a couple of seconds.

Repository structure and conventions

The track anatomy documentation is a general description of all the files and directories that are not explicitly described below.

Directory structure

├── .gitignore
├── .github
│   └── workflows
│       └── tests.yml
├── LICENSE
├── README.md
├── bin
│   └── fetch‐configlet
├── concepts
│   ├── basics
│   │   ├── about.md
│   │   ├── introduction.md
│   │   └── links.json
│   └── ...
├── config.json
├── docs
│   ├── ABOUT.md
│   ├── EXERCISE_README_INSERT.md
│   ├── INSTALLATION.md
│   ├── LEARNING.md
│   ├── RESOURCES.md
│   └── TESTS.md
└── exercises
    ├── concept
    │   ├── AnnalynsInfiltration
    │   │   ├── package.yaml
    │   │   ├── stack.yaml
    │   │   ├── src
    │   │   │   └── AnnalynsInfiltration.hs
    │   │   ├── test
    │   │   │   └── Tests.hs
    │   │   ├── .docs
    │   │   │   ├── instructions.md
    │   │   │   ├── introduction.md
    │   │   │   └── hints.md
    │   │   └── .meta
    │   │       ├── config.json
    │   │       ├── design.md
    │   │       └── exemplar
    │   │           ├── package.yaml
    │   │           └── src
    │   │               └── AnnalynsInfiltration.hs
    │   └── ...
    └── practice
        ├── accumulate
        │   ├── package.yaml
        │   ├── stack.yaml
        │   ├── src
        │   │   └── Accumulate.hs
        │   ├── test
        │   │   └── Tests.hs
        │   ├── .docs
        │   │   └── instructions.md
        │   └── .meta
        │       ├── examples
        │       │   └── success-standard
        │       │       ├── package.yaml
        │       │       └── src
        │       │           └── Accumulate.hs
        │       ├── config.json
        │       └── hints.md
        ├── allergies
        │   └── ...
        └── ...

• config.json: Every exercise has to be registered here. It has a unique name and a difficulty. The sequence order is also the default order in which the exercises are fetched.

Practice exercise structure

Each practice exercise has the following structure:

• stack.yaml has just one line specifying the current Stack snapshot. We use the same resolver for all the exercises.
• package.yaml is a file in the hpack format that has all dependencies and build instructions for an exercise. One of the properties tracked in package.yaml is the version of the exercise.
• src/ModuleName.hs is a stub solution.
• .docs/instructions.md contains the instructions and requirements to complete the exercise. For an exercise from problem-specifications, this file should exactly match the description.md from problem-specifications. The Exercism-wide documentation for instructions.md contains more information.
• .meta/examples/success-<name>/package.yaml contains library dependencies for the example solution. <name> is a unique name for the example - usually "standard" (as in success-standard), but it can be some other name in case of multiple example solutions.
• .meta/examples/success-<name>/src/ModuleName.hs is the source code of the sample solution.
• test/Tests.hs is the test suite.
• .meta/hints.md is an optional file containing instructions and/or hints. It is used together with the respective description.md for the exercise from problem-specifications to build the README.md file.
• .meta/config.json is the exercise configuration file. The Exercism-wide documentation for .meta/config.json contains more information.

Exercise versioning

Each exercise contains a four-part version in its package.yaml file, MAJOR.MINOR.PATCH.SERIAL.

There are two possibilities for the meaning of the MAJOR.MINOR.PATCH components:

• Exercises based on a canonical-data.json in problem-specifications should use its version plus a serial number.
• Exercises that are not based on canonical-data.json should use version 0.1.0 plus a serial number.

The serial number starts at 1 and always increases when the tests are changed, regardless of the changes in other version numbers.

When changing a test suite, the version number should be updated appropriately so that:

• It is possible for maintainers of this track to tell whether test suites are up to date with https://github.com/exercism/problem-specifications.
• It is easier for students to determine at-a-glance whether they have the same tests, by comparing version numbers.

This versioning policy was proposed and accepted in #522.

Development Dependencies

You should have Stack installed in your system to make contributing to this repository easier.

Stub solution

The stub solution should be as general as possible in order to not exclude any possible solutions. It should take Haskell specifics into account (for example use Maybe instead of a dummy return value). It should not contain any comments (people might forget to remove them), you can use the hints file instead.

The stub solution must compile by itself (with stack build). Ideally, it would also compile together with the test suite (with stack test --no-run-tests). These two conditions are enforced by GitHub Actions CI. If the second condition cannot be met for a good reason, place the explanation in .meta/DONT-TEST-STUB to circumvent the check. The first condition is always enforced and cannot be circumvented.

Example solution

The example solution could be inspiration for other language implementors. It doesn't need to be perfect or very elegant. But it should be efficient enough for the test suite to finish in only a few seconds.

Examples are named <type>-<name>. There are three possible types of examples:

• success: The example is expected to pass the tests.
  • There must be at least success example per exercise, in order to confirm that it is possible to solve the tests.
  • There may be more than one success example for a given exercise, but these are intended for use when we want to confirm that multiple type signatures for a given solution will compile and pass the tests.
  • We do not intend to use multiple success examples just to showcase a wide variety of possible solutions, since that is not in the goals of this repository.
• fail: The example is expected to build, but fail the tests.
  • These are intended for use when we want to make sure that the track tests have coverage: Whether the tests find certain classes of incorrect or inefficient solutions.
  • It's suggested that these only be used for tests that are specific to the track. This is under the assumption that tests sourced from problem-specifications have already been judged to have appropriate coverage by the reviewers of the problem-specifications repository.
• error: The example is expected to fail to build.
  • There is only one intended use of this so far, and that is a single check that a solution without a type signature will fail to build (because CI builds with --pedantic).
  • We do not intend for any additional uses of this type of example.

These example types were proposed and accepted in #397.

Test suite

The test suite should be derived from the respective problem-specifications/exercises/<exercise-name>/canonical-data.json and comply to some formatting and coding standards (to get an idea you may look at some of the existing tests).

Running Tests

In order to be accepted by GitHub Actions, every exercise must be registered in config.json, it must compile without warnings and the example solution must pass the tests without failures. Additionally the tests should not run longer than a few seconds.

First you need to provide an example solution.

We provide three scripts in the bin directory of this repository to run the tests. These are the same scripts as those used by GitHub Actions.

• test-example path/to/example/dir runs the tests on a single example.
• test-all-examples path/to/exercise/dir runs the tests on all examples for an exercise.
• test-stub path/to/exercise/dir checks that the stub for the given exercise compiles.

Running HLint

All code in this repository should be as idiomatic as possible, so we enforce in GitHub Actions that it returns No hints when processed by HLint.

It is highly recommended to run hlint on your sources before opening a pull request, so you can fix your code before submitting it for review.

If you are certain that a suggestion given by hlint would make the code worse, you can suppress it with annotations in the source file.

Automated Test Runner

We have a test runner to automatically run tests on Haskell solutions submitted to exercism.

haskell's Issues

Add instructions for running tests with Stack

It seems that stack is the recommended way to install Haskell these days. As a Haskell newbie, I haven't quite figured out how to run tests with stack, but that seems like a valuable addition to the README.

Move exercises to subdirectory

The problems api (x-api) now supports having exercises collected in a subdirectory
named exercises.

That is to say that instead of having a mix of bin, docs, and individual exercises,
we can have bin, docs, and exercises in the root of the repository, and all
the exercises collected in a subdirectory.

In other words, instead of this:

x{TRACK_ID}/
├── LICENSE
├── README.md
├── bin
│   └── fetch-configlet
├── bowling
│   ├── bowling_test.ext
│   └── example.ext
├── clock
│   ├── clock_test.ext
│   └── example.ext
├── config.json
└── docs
│   ├── ABOUT.md
│   └── img
... etc

we can have something like this:

x{TRACK_ID}/
├── LICENSE
├── README.md
├── bin
│   └── fetch-configlet
├── config.json
├── docs
│   ├── ABOUT.md
│   └── img
├── exercises
│   ├── bowling
│   │   ├── bowling_test.ext
│   │   └── example.ext
│   └── clock
│       ├── clock_test.ext
│       └── example.ext
... etc

This has already been deployed to production, so it's safe to make this change whenever you have time.

Meetup - 5th Monday

There is an interesting edge case in the meetup problem:
some months have five Mondays.

March of 2015 has five Mondays (the fifth being March 30th), whereas
February of 2015 does not, and so should produce an error.

---

Thanks, @JKesMc9tqIQe9M for pointing out the edge case.
See exercism.io#2142.

Add type information.

It'd be immensely helpful to add the types for the required functions. Maybe this can come in an additional markdown file? Or maybe just a blurb in the tests. Currently I'm having to glean the type information from the tests, that seems like the wrong way.

travis: All GHCs use same cache; check whether that's OK

Currently, our Travis builds use the same package cache for all three versions of GHC that we test, which could cause strange behaviors (but luckily has not, so far).

This bit me when I was setting up Travis on one of my own projects. This will not necessarily be an problem for this track (and this issue could be closed if we think that), but this issue will serve as documentation of what could happen and how to fix it.

If there are problems related to this, I predict symptoms will manifest in one of two ways:

1. (If #129 gets implemented) Cache misses even when no package versions have changed.
   This happened to me because a package was only being pulled in as a dependency in certain GHC versions. The inconsistency caused my different versions to fight with each other for which list of packages was correct to cache (It means I never got cache hits even when I should have).
2. Failure to find a package that we supposedly installed, something like:

test.hs:1:8:
    Could not find module ‘Package.We.Definitely.Have’
    Use -v to see a list of the files searched for.

If this becomes a problem, the remediation is to add a compiler: key in the matrix in travis.yml (https://github.com/hvr/multi-ghc-travis/blob/master/make_travis_yml.hs will generate an example yaml file, or take a look at https://github.com/ekmett/lens/blob/master/.travis.yml for a generated example). This will cause Travis to use separate caches for each GHC version, which should avoid both issues above.

You can confirm the cache behavior by looking at the build logs and expand the arrow next to "Setting up build cache". You should see a line that looks like:

attempting to download cache archive
fetching master/cache--compiler-gcc.tgz
found cache

If all builds are using the same cache, that tgz name will be the same across all versions. If they are different, you might instead see something like:

attempting to download cache archive
fetching master/cache--compiler-GHC7.6.3.tgz
found cache

travis: 7.10.1 -> 7.10.3?

7.10.1 was in March 2015 https://www.haskell.org/ghc/download_ghc_7_10_1
Since then we've had:

• 7.10.2 https://www.haskell.org/ghc/download_ghc_7_10_2 (release notes at http://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/release-7-10-2.html)
• 7.10.3 https://www.haskell.org/ghc/download_ghc_7_10_3 (release notes at http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/release-7-10-3.html)

My impression is that 7.10.1 was chosen because it was the newest at the time. Now that 7.10.3 is out I think we'd like to test that now. This will be the case unless we specifically care about some distro that stays at 7.10.1 and does not move to 7.10.3. That would be odd behavior since it's my impression that incrementing just the least significant number means it's a bugfix release (GHC seems to follow this convention at least)

I wonder if there's a way to specify 7.10.x to travis to always stay up to date... (current suspicion on that is "no" looking at some prominent haskell projects that test multi haskell versions, try lens for example)

Possible typo in ETL test

I'm currently working on ETL and have a question about one of the tests.

The test transform multiple keys from one value is expected to have two results, one a and one e, both of which are valued at 1. This shows that the values are not cumulative, otherwise e would be 2.

  , testCase "transform multiple keys from one value" $
    M.fromList [("a", 1), ("e", 1)] @=? transform (M.fromList [(1, ["A", "E"])])

In the test case transform multiple keys from multiple values it seems as if the result for b is treated cumulatively. In every other spot (in this track and others) b always has a value of 3, not 4.

  , testCase "transform multiple keys from multiple values" $
    M.fromList [("a", 1), ("b", 4)] @=?
    transform (M.fromList [(1, ["A"]), (4, ["B"])])

It wasn't explained in the instructions that we should be summing the scores so I'm wondering if this is a typo.

Make Hamming conform to official definition

From issue exercism/exercism#1867

Wikipedia says the Hamming distance is not defined for strings of different length.

I am not saying the problems cannot be different, but for such a well-defined concept it would make sense to stick to one definition, especially when the READMEs provide so little information about what is expected from the implementation.

Let's clean this up so that we're using the official definition.

triangle: incorrect test in some tracks

Please check if there's a test that states that a triangle with sides 2, 4, 2 is invalid. The triangle inequality states that for any triangle, the sum of the lengths of any two sides must be greater than or equal to the length of the remaining side. If this doesn't affect this track, go ahead and just close the issue.

binary: improve tests for invalid numbers

We should have separate tests for:

• alphabetic characters at the beginning of a valid binary number
• alphabetic characters at the end of a valid binary number
• alphabetic characters in the middle of an otherwise valid binary number
• invalid digits (e.g. 2)

If the test suite for binary has test cases that cover these edge cases, this issue can safely be closed.

See exercism/problem-specifications#95

robot-simulator: "turning edge cases" are not necessarily edge cases

We have:

  [ testCase "turning edge cases" $ do
    North @=? turnRight West
    West @=? turnLeft North
-- other tests omitted
   ]

These aren't necessarily edge cases. It's only an edge case for the particular implementation used in the example solution, where North is the first variant of the data Bearing =, and West is the last. Any student may have chosen a different ordering, at which point these aren't edge cases anymore.

nucleotide-count tests don't enforce valid strand constraint

In the tests for nucleotide-count, this test case:

assertError "invalid nucleotide 'X'" $ count 'X' "GACT"

ensures that the implementation checks that the nucleotide being counted is valid. However, there is no such test for the strand whose nucleotides are being counted, for count or nucleotideCounts.

The example implementation does check for this, so I thought it might be a missing test case.

Delete configlet binaries from history?

I made a really stupid choice a while back to commit the cross-compiled
binaries for configlet (the tool that sanity-checks the config.json
against the implemented problems) into the repository itself.

Those binaries are HUGE, and every time they change the entire 4 or 5 megs get
recommitted. This means that cloning the repository takes a ridiculously long
time.

I've added a script that can be run on travis to grab the latest release from
the configlet repository (bin/fetch-configlet), and travis is set up to run
this now instead of using the committed binary.

I would really like to thoroughly delete the binaries from the entire git
history, but this will break all the existing clones and forks.

The commands I would run are:

# ensure this happens on an up-to-date master
git checkout master && git fetch origin && git reset --hard origin/master

# delete from history
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch bin/configlet-*' --prune-empty

# clean up
rm -rf .git/refs/original/
git reflog expire --all
git gc --aggressive --prune

# push up the new master, force override existing master branch
git push -fu origin master

If we do this everyone who has a fork will need to make sure that their master
is reset to the new upstream master:

git checkout master
git fetch upstream master
git reset --hard upstream/master
git push -fu origin master

We can at-mention (@) all the contributors and everyone who has a fork here in this
issue if we decide to do it.

The important question though, is: Is it worth doing?

Do you have any other suggestions of how to make sure this doesn't confuse people and break their
repository if we do proceed with this change?

Name nucleobases, not nucleosides

The primary nucleobases are cytosine (DNA and RNA), guanine (DNA and RNA), adenine (DNA and RNA), thymine (DNA) and uracil (RNA), abbreviated as C, G, A, T, and U, respectively. Because A, G, C, and T appear in the DNA, these molecules are called DNA-bases; A, G, C, and U are called RNA-bases. - Wikipedia

In other words, we should rename the values in the RNA transcription problem to reflect the following:

• cytidine -> cytosine
• guanosine -> guanine
• adenosine -> adenine
• thymidine -> thymine
• uridine -> uracil

QuickCheck?

It seems that only two tests are using QC right now: https://github.com/exercism/xhaskell/blob/d238a331c2bccaa1d86522198e0a85235a6356d6/octal/octal_test.hs and https://github.com/exercism/xhaskell/blob/d238a331c2bccaa1d86522198e0a85235a6356d6/trinary/trinary_test.hs.

However, I'd think that almost all of the tests should use QC. Any reason why they aren't? Up for PR's?

I'm not implying that HUnit should be replaced entirely, but I think QC should be able to take care of most of the testing. HUnit can still be used for specific test cases.

gigasecond: use times (not dates) for inputs and outputs

A duration of a gigasecond should be measured in seconds, not
days.

The gigasecond problem has been implemented in a number of languages,
and this issue has been generated for each of these language tracks.
This may already be fixed in this track, if so, please make a note of it
and close the issue.

There has been some discussion about whether or not gigaseconds should
take daylight savings time into account, and the conclusion was "no", since
not all locations observe daylight savings time.

travis: Automatically invalidate caches if new package versions exist

While working on #101 I discovered that because we cache .cabal, we'll get conflicts (and thus build failures) if there's a new version of a cabal package we use.

That's less than ideal (and we had to manually clear the cache to fix the build), but I believe there's a way out. Should examine the work done in https://github.com/hvr/multi-ghc-travis/blob/master/make_travis_yml.hs - it seems to check the install plan and compares it to the last known one. If there's a change, it clears the packages and asks cabal to reinstall. I think this will work, though it may need some testing... and depending on how often our used packages release new versions opportunities to test may be rare.

Updated tests for the Custom Set problem

In order to reduce the amount of code required to pass incremental tests (assuming that users pass tests starting from the top), the order of the tests was modified slightly.

Since this track implements Custom Set, please take a look at the new custom-set.json file and see if your track should update its tests.

If you do need to update your tests, please refer to this issue in your PR. That helps us see which tracks still need to update their tests.

If your track is already up to date, go ahead and close this issue.

More details on this change are available in exercism/problem-specifications#257.

Total functions in nucleotide exercise.

count and nulceotideCounts are intended to be partial functions. Why not make them total? Either with a simplistic Maybe Int/Maybe (Map Char Int) or a more descriptive data type that contains information about the error.

Perhaps something like:

data NucleotideError = Invalid Char

count :: Char -> String -> Either NucleotideError Int
nucleotideCounts :: String -> Either NucleotideError (Map Char Int)

How to set up a local dev environment

See issue exercism/exercism#2092 for an overview of operation welcome contributors.

---

Provide instructions on how to contribute patches to the exercism test suites
and examples: dependencies, running the tests, what gets tested on Travis-CI,
etc.

The contributing document
in the x-api repository describes how all the language tracks are put
together, as well as details about the common metadata, and high-level
information about contributing to existing problems, or adding new problems.

The README here should be language-specific, and can point to the contributing
guide for more context.

From the OpenHatch guide:

Here are common elements of setting up a development environment you’ll want your guide to address:

Preparing their computer
Make sure they’re familiar with their operating system’s tools, such as the terminal/command prompt. You can do this by linking to a tutorial and asking contributors to make sure they understand it. There are usually great tutorials already out there - OpenHatch’s command line tutorial can be found here.
If contributors need to set up a virtual environment, access a virtual machine, or download a specific development kit, give them instructions on how to do so.
List any dependencies needed to run your project, and how to install them. If there are good installation guides for those dependencies, link to them.

Downloading the source
Give detailed instructions on how to download the source of the project, including common missteps or obstacles.

How to view/test changes
Give instructions on how to view and test the changes they’ve made. This may vary depending on what they’ve changed, but do your best to cover common changes. This can be as simple as viewing an html document in a browser, but may be more complicated.

Installation will often differ depending on the operating system of the contributor. You will probably need to create separate instructions in various parts of your guide for Windows, Mac and Linux users. If you only want to support development on a single operating system, make sure that is clear to users, ideally in the top-level documentation.

Run travis tests on GHC 7.6, 7.8, 7.10

To ensure that the tests and reference apps run without errors or warnings, we should automate tests on GHC 7.6 (because people use Linux distros with old versions of Haskell), GHC 7.8 (not everyone is on the bleeding edge) and GHC 7.10.

Since it's not feasible to use Haskell Platform from Travis we need to curate a list of packages to cabal install first.

• https://github.com/ekmett/lens/blob/master/.travis.yml is an example of a project that successfully tests multiple GHC versions

We may want to investigate halcyon and/or stack for faster builds. Note that stack does not support GHC 7.6, only 7.8 and 7.10. We could change the installation instructions and drop support for GHC 7.6, but that may be too high of a cost.

Warning "Defaulting the following constraints to type `Integer` in leap_test.hs

The years in leap_test.hs have no explicit type, allowing solutions with differente type signatures:

isLeapYear :: Int     -> Bool
isLeapYear :: Integer -> Bool

This is desirable, but has the unintended effect of displaying a warning...

Defaulting the following constraint(s) to type `Integer` arising from the use of `isLeapYear` at leap_test.hs ... arising from the literal 1996 ...

... when compiling leap_test.hs with the most general solution:

isLeapYear :: Integral a => a -> Bool

It's important to supress this warning so we don't misguide newcomers in thinking that there is something wrong with their code, when the problem is in the test module. Also, using the most general type is usually encouraged in Haskell.

I don't think it's possible to write a test allowing those three distinct signatures without raising a warning, so I propose to suppress it with:

{-# OPTIONS_GHC -fno-warn-type-defaults #-}

I could make a pull request for leap and maybe other exercises sharing the same problem, but I haven't checked yet how many they are.

Anyone against it?

Gigasecond - Could not find module ‘System.Locale’

I'm a newb to Haskell and I'm doing the Gigasecond exercise in Haskel. I'm getting this error -

when I run runhaskell -Wall gigasecond_test.hs

gigasecond_test.hs:7:8:
    Could not find module ‘System.Locale’

Glasgow Haskell Compiler, Version 7.10.1, stage 2 booted by GHC version 7.10.1
Using binary package database: /usr/local/Cellar/ghc/7.10.1_1/lib/ghc-7.10.1/package.conf.d/package.cache
Using binary package database: ~/.ghc/x86_64-darwin-7.10.1/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67
wired-in package base mapped to base-4.8.0.0-9015e10d2b2b0f71f570c3f2bbe09c8a
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-7dd4b8bf14d5c74339cc9bf2cb38ffa4
wired-in package ghc mapped to ghc-7.10.1-5786533e1406205cf5a1af1a23ee7528
wired-in package dph-seq not found.
wired-in package dph-par not found.

I rancabal install systemand it returned cabal: There is no package named 'system'.

Is this an error on my end?

Change design of meetup problem

@pminten brought up a very good point about the API of meetup being
pretty terrible (See exercism/exercism#950).

If the meetup problem has not already been fixed in this track, we should
improve the test suite and example code to give the API a better design.

travis: document why we use hvr-ghc not `travis: haskell` and `ghc:` array with versions

I submitted #121 to check why we do not use travis: haskell and ghc: to specify our GHC versions like https://docs.travis-ci.com/user/languages/haskell suggests and instead we use https://github.com/hvr/multi-ghc-travis. The reason is travis doesn't yet support 7.10 and 8.0; that's a dealbreaker for me.

To prevent any further questions, and leave notes for when we can or cannot potentially move to the travis: haskell model, we should document in the .travis.yml why it is the case that we do what we do, so that future people don't have to ask the same question I just asked.

Verify that nothing links to help.exercism.io

The old help site was deprecated in December 2015. We now have content that is displayed on the main exercism.io website, under each individual language on http://exercism.io/languages.

The content itself is maintained along with the language track itself, under the docs/ directory.

We decided on this approach since the maintainers of each individual language track are in the best position to review documentation about the language itself or the language track on Exercism.

Please verify that nothing in docs/ refers to the help.exercism.io site. It should instead point to http://exercism.io/languages/:track_id (at the moment the various tabs are not linkable, unfortunately, we may need to reorganize the pages in order to fix that).

Also, some language tracks reference help.exercism.io in the SETUP.md file, which gets included into the README of every single exercise in the track.

We may also have referenced non-track-specific content that lived on help.exercism.io. This content has probably been migrated to the Contributing Guide of the x-common repository. If it has not been migrated, it would be a great help if you opened an issue in x-common so that we can remedy the situation. If possible, please link to the old article in the deprecated help repository.

If nothing in this repository references help.exercism.io, then this can safely be closed.

Configure Travis CI build

@etrepum I'm in the process of extracting all the exercises, putting each language in its own repository.

I'm creating a separate api (http://github.com/exercism/x-api) which includes all the language repositories as git submodules.

Do you have time to set up the Travis build for the haskell repository?

Changes to Custom Set tests

We recently rewrote the test suite for Custom Set. Since this track implements Custom Set, please take a look at the new custom_set.json file and see if your track should update its implementation or tests.

The new test suite reorders tests so that students can get to green quickly. It also reduces the number of tests so that students can focus on solving the interesting edge cases.

More details on this change are available in the pull request

scrabble-score: replace 'multibillionaire' with 'oxyphenbutazone'

The word multibillionaire is too long for the scrabble board. Oxyphenbutazone, on the other hand, is legal.

Please verify that there is no test for multibillionaire in the scrabble-score in this track. If the word is included in the test data, then it should be replaced with oxyphenbutazone. Remember to check the case (if the original is uppercase, then the replacement also should be).

If multibillionaire isn't used, then this issue can safely be closed.

See exercism/problem-specifications#86

mageia and the haskell course

Hello,

I work with Mageia and they have only gch avaible.
It this enough to do the course ?

Roelof

travis: Document why we test the GHC versions that we do

For example #82 explains that we test 7.6 because some versions of Linux use that. An example I found was that Ubuntu trusty uses 7.6. It would be good if we would express the rationale as comments in the .travis.yml file so that we may potentially answer questions such as "when is it safe to remove our support for 7.6?"

To be clear, not that I'm advocating removing support of 7.6 anytime soon. In fact I may even advocate for adding 7.4, since I found that Ubuntu Precise ships with that.

Edit: Indeed I still would have advocated for 7.4 but experiments in #131 to try to get 7.4 working were unsuccessful. (no mkdtemp in System.Posix.Temp in the version of unix we get with 7.4).

rna-transcription: don't transcribe both ways

I can't remember the history of this, but we ended up with a weird non-biological thing in the RNA transcription exercise, where some test suites also have tests for transcribing from RNA back to DNA. This makes no sense.

If this track does have tests for the reverse transcription, we should remove them, and also simplify the reference solution to match.

If this track doesn't have any tests for RNA->DNA transcription, then this issue can be closed.

See exercism/problem-specifications#148

Pass explicit list of multiples in "Sum of Multiples" exercise rather than defaulting to 3 and 5

Hello, as part of exercism/problem-specifications#198 we'd like to make the sum of multiples exercise less confusing. Currently, the README specifies that if no multiples are given it should default to 3 and 5.

We'd like to remove this default, so that a list of multiples will always be specified by the caller. This makes the behavior explicit, avoiding surprising behavior and simplifying the problem.

Please make sure this track's tests for the sum-of-multiples problem do not expect such a default. Any tests that want to test behavior for multiples of [3, 5] should explicitly pass [3, 5] as the list of multiples.

After all tracks have completed this change, then exercism/problem-specifications#209 can be merged to remove the defaults from the README.

The reason we'd like this change to happen before changing the README is that it was very confusing for students to figure out the default behavior. It wasn't clear from simply looking at the tests that the default should be 3 and 5, as seen in exercism/exercism#2654, so some had to resort to looking at the example solutions (which aren't served by exercism fetch, so they have to find it on GitHub). It was added to the README to fix this confusion, but now we'd like to be explicit so we can remove the default line from the README.

You can find the common test data at https://github.com/exercism/x-common/blob/master/sum-of-multiples.json, in case that is helpful.

Fix crypto-square to use a square, not groups of five

Somewhere along the line we lost the square part of the crypto square problem, replacing the grouping with the standard groupings of 5.

The test suite should be updated to reflect the squarishness of this problem.

See exercism/problem-specifications#28

'accumulate' exercise is inappropriately placed.

My gut says it's inappropriate to Haskell full stop, being so core to the language that even a zero-sugar, from-scratch implementation is two lines long. But eh, I saw enough people unnecessarily bind the function on the empty-list case that I guess it's worth something. After the preceding exercises, though, it's beyond trivial. Maybe move this up to be exercise #1 or #2?

Reorder exercises

OK, it's harder than I thought it would be to come up with a good order. I've tried not to make too many inconsequential changes...

Obviously the first exercise deserves particular attention. bob is fiddly, requires a few imports and probably familiarity with recursion, list comp or higher order functions which are better introduced by rna-transcription. I see that leap is first on some of the other tracks and it's just writing a boolean expression (or using guards). Is it a good choice?

I don't think the order of the later exercises matters so much.

I wonder if list-ops should even come before nucleotide-count? This order still doesn't really address the combined Map and foldl'-foldl-foldr trap, it just moves it from word-count into nucleotide-counts. But it would be nice to motivate the use of whatever higher order function before asking it to be implemented. Maybe suggest in the test of an earlier exercise to use a fold? Or write a new exercise? It would probably be Haskell specific but I assume eventually language specific exercises/READMEs will be supported and until then it can live in x-common.

So, still a WIP. I can make the PR when we've got a good order.

Change	Exercise	Comment
-11	leap
0	rna-transcription
0	sublist	good place to introduce Hoogle if isInfixOf isn't found
-27	accumulate	shame about the name
-11	grains
-11	gigasecond	Num class / integer division / floor etc.
6	bob
-54	sum-of-multiples	filter + any
-52	strain	write filter
2	point-mutations	zip/zipWith
-4	space-age
7	anagram
6	nucleotide-count	now comes before word-count
5	phone-number
5	grade-school
-31	simple-linked-list
-15	list-ops	fundamental; test file should have a comment about foldl' or even just link the foldl'-foldl-foldr wiki
14	word-count	this is nucleotide-count but with some extra word splitting trickiness; good to have a bit of padding between them so if someone is blasting through the exercises they get feedback on nuc-count before trying this?
6	etl
9	robot-name
7	meetup
16	beer-song	tedious
5	triangle
5	scrabble-score
5	roman-numerals
5	binary
5	prime-factors
5	raindrops
5	allergies
5	atbash-cipher
5	bank-account
5	crypto-square
5	kindergarten-garden
5	robot-simulator
5	queen-attack
3	binary-search-tree
3	difference-of-squares
3	hexadecimal
3	largest-series-product
3	luhn
3	clock
3	matrix
3	house
3	minesweeper
3	ocr-numbers
3	octal
3	trinary
3	wordy
3	food-chain
2	linked-list
2	custom-set
2	nth-prime
2	palindrome-products
2	pascals-triangle
2	pig-latin
2	pythagorean-triplet
2	saddle-points
2	say
2	secret-handshake
2	series
2	sieve
2	simple-cipher
0	parallel-letter-frequency
0	sgf-parsing
0	go-counting
0	zipper
0	forth

check-exercises.hs redundant import warning after GHC 7.10.x

Travis keeps warning with:

_test/check-exercises.hs:18:1: warning: [-Wunused-imports]
    The import of ‘Control.Applicative’ is redundant
      except perhaps to import instances from ‘Control.Applicative’
    To import instances alone, use: import Control.Applicative()

Should check whether that's required. If not required, remove the line completely. If required, add the ().

Error running gigasecond test

I'm getting the following error when trying to run the Gigasecond test:

gigasecond_test.hs:9:15:
    Couldn't match expected type ‘time-1.5.0.1:Data.Time.Format.Locale.TimeLocale’
                with actual type ‘System.Locale.TimeLocale’
    NB: ‘time-1.5.0.1:Data.Time.Format.Locale.TimeLocale’
          is defined in ‘Data.Time.Format.Locale’ in package ‘time-1.5.0.1’
        ‘System.Locale.TimeLocale’
          is defined in ‘System.Locale’ in package ‘old-locale-1.0.0.7’
    In the first argument of ‘readTime’, namely ‘defaultTimeLocale’
    In the expression:
      readTime defaultTimeLocale (iso8601DateFormat (Just "%T%Z"))

I'm not sure if this is a problem in the test or if it is a problem in my Haskell install or even if it is in my solution (although from the error message, it doesn't look like the problem is in my solution). I'm (obviously) pretty new to Haskell, so I'm sorry I can't be more help in diagnosing this.

I'm on OSX with ghc, and installed via Brew, and HUnit installed via cabal, apparently up to date on everything.

Apologies if this is my problem, and should have been posted elsewhere!

ListOps - should test strictness of foldl'

A simple test case for strictness involves expecting exception Prelude.undefined from the test:

foldl' (\_ x -> x) 0 [undefined, 1]
-- *** Exception: Prelude.undefined
foldl (\_ x -> x) 0 [undefined, 1]
-- 1

Unfortunately, expecting exceptions does not appear to be built into HUnit.

clock: canonical test data has been improved

The JSON file containing canonical inputs/outputs for the Clock exercise has gotten new data.

There are two situations that the original data didn't account for:

• Sometimes people perform computation/mutation in the display method instead of in add. This means that you might have two copies of clock that are identical, and if you add 1440 minutes to one and 2880 minutes to the other, they display the same value but are not equal.
• Sometimes people only account for one adjustment in either direction, meaning that if you add 1,000,000 minutes, then the clock would not end up with a valid display time.

If this track has a generator for the Clock exercise, go ahead and regenerate it now. If it doesn't, then please verify the implementation of the test suite against the new data. If any cases are missing, they should be added.

See exercism/problem-specifications#166

SETUP.md links to help.exercism.io

That no longer exists. What should it link to instead? Are students seeing this, or is it just for this repository?

Add helpful information to the SETUP.md

The contents of the SETUP.md file gets included in
the README.md that gets delivered when a user runs the exercism fetch
command from their terminal.

At the very minimum, it should contain a link to the relevant
language-specific documentation on
help.exercism.io.

It would also be useful to explain in a generic way how to run the tests.
Remember that this file will be included with all the problems, so it gets
confusing if we refer to specific problems or files.

Some languages have very particular needs in terms of the solution: nested
directories, specific files, etc. If this is the case here, then it would be
useful to explain what is expected.

---

Thanks, @tejasbubane for suggesting that we add this documentation everywhere.
See exercism.io#2198.

travis: all builds install all GHC versions, rather than just the one they're testing

For example, the 7.6 build will install the 7.8 ghc and the 7.10 ghc. This may unnecessarily increase install times.

This can be avoided by specifying addons in the matrix, rather than on the top level.

"point-mutations" is deprecated in favor of hamming

This happened a while back, and it was for really weird legacy reasons.

I've since fixed the underlying issues that caused the problem, but for consistency
it would be nice to rename point-mutation to hamming, so that all the tracks are using
the same exercise name.

Once the problem has been renamed, I can run a script on the website to point people's
existing point-mutations solutions to the new hamming exercise so that they'll be able
to review solutions to hamming, and people who solve the new hamming exercise can see
all the old ones.

Remove mention of RNA (uracil) from nucleotide-count problem?

The metadata for this problem has been simplified, and it might be worth changing the test suite and example so that theres no mention of RNA or uracil.

I've also changed the API of the problem in Ruby so that there is no error checking in the object itself, only in the factory that creates it: https://github.com/exercism/xruby/blob/master/nucleotide-count/example.rb#L2-L8

I don't know if this is relevant or idiomatic in Haskell.

discussion: Should we return Maybe when there is a possibility of invalid input?

While working on #114 I noticed that the binary tests just return 0 when there is an error.

That's simpler to implement. The disadvantage is that it makes the two cases "valid input whose value is zero" and "invalid input" indistinguishable to someone who can only observe the output values. Would we like to return Nones for invalid inputs? I did get Maybes added to largest-series-product in #89 .

Personally I would argue for it since I think it's a common thing in Haskell and more exposure to it is good, but there may be a possibility that there's too much. Wonder what others think.

To clarify scope, this is not suggesting that every exercise that possibly can test invalid inputs should (for example, "should the meetup exercise test nonexistent months") - that is a separate question that is worth another issue if someone wish to discuss it. The question is simply: For the exercises that already test invalid inputs, should they return Maybe as the result?

If this is done, at the very least all the base conversion exercises will want it (binary, trinary, octal, hexadecimal). I can possibly investigate the other exercises in Haskell to see where else it would make sense to add too.

Survey of existing exercises and how they handle invalid inputs:

• base-conversion exercises (binary, trinary, octal, hexadecimal) have already been mentioned - they return 0.
• nucleotide uses error https://github.com/exercism/xhaskell/blob/master/exercises/nucleotide-count/example.hs and the tests check for it via Control.Exception. Seems a big hammer, whereas I'd rather make the possibility of error apparent in the type system if we're going to check for it (it's one of the reasons why I use Haskell anyway)
• phone number also returns 0000000000, whereas it could return Maybe
• say, wordy, zipper already return Maybes.

Binary search tree cannot be a monoid

I was surprised that the binary-search-tree exercise doesn't allow solutions where the BST can be empty.

The problem is that the bstValue function is of type BST a -> a instead of of BST a -> Maybe a.
This also means that the fromList function must have a special case where it returns an error for the empty list.

In the example solution the BST is defined as:

data BST a = Node { bstValue :: a
                  , bstLeft :: Maybe (BST a)
                  , bstRight :: Maybe (BST a) }

Wouldn't a definition like the following be nicer?

data BST a = Tip
           | Node (BST a) a (BST a)

Update queen attack to use _'s not O's for empty spaces

See the updated problem description

pov: Consider making tests insensitive to child ordering

In the pov tests, given a tree that must be reparented on node x, the tests ensure that the former parent of x comes after the former children of x.

I think it would be beneficial if the tests did not care about the ordering of the children, since trees probably don't care about the ordering of their children, and it almost certainly is valid to allow either order in the POV problem.

Verify "Largest Series Product" exercise implementation

There was some confusion in this exercise due to the ambiguous use of the term consecutive in the README. This could be taken to mean contiguous, as in consecutive by position, or as in consecutive numerically. The the README has been fixed (exercism/problem-specifications#200).

Please verify that the exercise is implemented in this track correctly (that it finds series of contiguous numbers, not series of numbers that follow each other consecutively).

If it helps, the canonical inputs/outputs for the exercise can be found here:
https://github.com/exercism/x-common/blob/master/largest-series-product.json

If everything is fine, go ahead and just close this issue. If there's something to be done, then please describe the steps needed in order to close the issue.