Instructions
If you want to build something using a Raspberry Pi, you'll probably use resistors.
For this exercise, you need to know two things about them:
- Each resistor has a resistance value.
- Resistors are small - so small in fact that if you printed the resistance value on them, it would be hard to read.
To get around this problem, manufacturers print color-coded bands onto the resistors to denote their resistance values.
Each band has a position and a numeric value.
The first 2 bands of a resistor have a simple encoding scheme: each color maps to a single number.
For example, if they printed a brown band (value 1) followed by a green band (value 5), it would translate to the number 15.
In this exercise you are going to create a helpful program so that you don't have to remember the values of the bands.
The program will take color names as input and output a two digit number, even if the input is more than two colors!
The band colors are encoded as follows:
- black: 0
- brown: 1
- red: 2
- orange: 3
- yellow: 4
- green: 5
- blue: 6
- violet: 7
- grey: 8
- white: 9
From the example above:
brown-green should return 15, and
brown-green-violet should return 15 too, ignoring the third color.
Defining syntax
This exercise is intended as a continuation of Resistor Color and builds upon it.
Although you may solve practice exercises in any order, we encourage you to follow the suggested sequence.
In this exercise, you are given syntax for colors already predefined using the c* prefix, e.g., c*black.
You must then define syntax that associates a sequence of colors to a number, according to the instructions.
The colors are within *[[ and ]] and separated by , , e.g., *[[c*black, c*yellow, c*violet]].
This task will likely require you to use either notations or macros.
You might want to check a reference.
Because new syntax is expanded at compile time, any test would fail to compile unless all the required syntax is defined.
For this reason, instead of relying on traditional runtime tests, we use #guard_msgs.
This command compares a given docstring with a message generated by another command, in this case #eval, and reports an error if they are different.
You may consider the absence of an error as a passing test.
If you work locally or in Lean's online playground, you will get instant feedback on any error reported by #guard_msgs through Lean InfoView.
The online test runner does not currently support importing the full Lean meta-programming library.
While you are free to use any features available in Lean by default, including those within the Lean namespace, adding import Lean or importing specific modules from the Lean namespace will cause your submission to fail when submitted to Exercism.
Note that importing the Lean library is not necessary to solve this exercise.
