Add new practice exercise `bank-account`
This is week 41 of 48in24.
This exercise is not straightforward, there are different ways it could be approached. Here are some notes:
- It is suggested that it's a good one for testing concurrency, but Elm can't do that on Exercism (since we need
Taskand a way to test them) so I did not implement the last test related to concurrency. - In some languages, a stateful approach could be taken (a bank account is created and can be accessed by different clients), but we can't do that in pure Elm either.
- The way I would write this API in real life would be different, I would consider phantom types to only allow operations on accounts that are open. The problem with this approach is that it would get rid of a lot of tests that check for errors, and there are no way of looking at types with tests. We could do it with the analyzer, but that would be pretty unorthodox, and would require additional instructions. Doable though.
- There were two tests that checked that an account not opened could not be closed, but that just doesn't make sense in a typed language so I did not implement them.
- The API for the
openfunction is quite unnatural, I wrote it this way to preserve as many test cases as possible and keep the spirit of the exercise as much as possible. - I'm very happy that this exercise is suitable to be our first one to practice the
opaque-typesconcept, since we don't even need to export the type.
I'm happy to discuss or revisit all of these decisions. The code is very simple, but the API is not.
I just had a quick look and didn't find anything shocking with the code. But I don't know much of the context and objectives of the exercise regarding concurrency.
The code is fine, it's quite simple, it's the API (function signatures) that could be built differently. The canonical data is a bit vague with it's "operations". The last test is the one talking about concurrency.
@mpizenberg @ceddlyburge I know that my description was long, but really if you don't have concerns, I'm fine with the exercise as it is. In a nutshell:
- we don't have concurrency, but that's not a requirement, so it's not an issue
- the API could be different, but this version allowed to keep the most exercises
Hi @jiegillet , I left this to matthieu as he got their first, but if he doesn't get back to you in a few days I'll take a look
We missed the 48in24 deadline, so this is not in any sort of rush at the moment, but @ceddlyburge if you have the time for a quick review, that would be nice.
Out of interest, is there data showing how many elm exercises are submitted as part of 48 in 24?
I don't know, maybe we should ask about that on the Forum, I'm sure other tracks would also be interested in having a breakdown of exercises submitted. It might already exist.