project on language erlang

AimsThe aims of this project are as follows:
● To give you more exposure to recursive programming, high-order functions and
list comprehensions.
● To expose you to Erlang programming.
Requirements
Implement all the functions specified in prj5_sol.erl using the Erlang compiler installed
on remote.cs. Please consult the provided tests and LOG if the specs for a function are
not entirely clear.
Specifically, all provided tests should pass:
$ erl
Eshell V11.1.8 (abort with ^G)
1> c(prj5_sol).
{ok,prj5_sol}
2> prj5_sol:test().
All 149 tests passed.
ok
3> q().
4> $
Provided Files
You should use the provided prj5-sol directory as a starting point for your project by
copying it into your i571?/submit directory. It contains the following files:
prj5_sol.erl
A skeleton file which contains the specifications for the functions you are required to
write. Each function you are required to implement is set up to return a dummy ‘TODO’
placeholder value.
README
A template README which you should complete and submit.
Tests
[Note that the test code is roughly an order of magnitude longer than the code you are
required to implement.]
Each test is defined using a TestSpec tuple having one of the following forms:
{ Test, Args, Expected }
This triple gives an atom Test describing the test, a list Args of the arguments for the
function under test and the Expected result.
{ Test, Args, Expected, ResultFn }
The additional ResultFn should specify a 1-argument function which is used to
massage the result of the function under test into the format needed for Expected. (The
specs require an error message, but the exact contents of the error message is not
specified; hence ResultFn is used to remove the error message from the output before
it is compared with Expected).
In order to keep the tests DRY, test data are defined using preprocessor macros and
tests for one function are transformed into tests suitable for a related function.
Usually, the tests for a function fn() are provided by fn_test_specs() which is a function
which will return a list of TestSpec’s. These specs are then transformed by make_tests/2 into
a form suitable to be run by Erlang’s eunit.
Hints
The following points are worth noting:
● Details of specific syntax for different Erlang constructs are available in this
Erlang Cheat Sheet.
● The provided skeleton file is set up to export all functions automatically.
● An exported function fn() must be preceeded by the module name when used in
the REPL, i.e. prj5_sol:fn().
● Please look at the provided tests and LOG if the specs for a function are not
entirely clear.
● Produce error messages using io_lib:format(). This may produce a nested list, so
process its result using lists:flatten().
● Minor hints for each function are available in the provided prj5_sol.erl skeleton
file.
You may proceed as follows:
1. Review the class Erlang slides.
2. Review the Test Control section in the skeleton file and make sure you
understand how to enable/disable tests and control the level of detail shown
when tracing tests. You need not understand the operation of make_tests/2.
3. Review the employee Type and Data section in the skeleton file. Make sure you
understand the syntax used to access an individual field of an employee and the
functionality of the provided predicates.
4. Implement dept_employees1/2. As in your previous projects, you will need to handle
three cases:
a. The Employees list is empty.
b. The Employees list is non-empty and its head Employee has a matching Dept.
c. None of the above conditions are true.
5. Handle each of the above cases using a separate clause, with the clauses being
separated by ;.
6. Implement dept_employees2/2. Note that the syntax of an anonymous function in
Erlang is fun (Args) -> Expr end. The body Expr can contain multiple sub-expressions
separated by ,.
7. Implement dept_employees3/2. Transform the above filter() into a list comprehension;
note that Erlang uses || to separate the expression computing the elements from
the generators and conditions.
8. Implement delete_employee/2. Simply use a list comprehension to select those
elements of Employees having name’s /= Name.
9. Implement upsert_employee/2 using recursion. Handle three cases similar to those
for dept_employees1/2 above.
10. Implement find_employees/2 using a list comprehension which uses lists:all() to
check the provided predicates.
11. Implement employees_req/2 by using a case pattern match on the Req. The delete, find
and upsert operations can be implemented by calling the functions implemented
earlier. The dump operation is trivial. The read operation can use the earlier
find_employees/2 using the specs for employees_req/2 as a guide.
12. Implement employees_req_with_sort/2. If the specified operation is sort, then sort the
Employees list using lists:sort/2. Otherwise forward the request to employees_req/2.
13. In order to implement start_employees_server/2 define an auxiliary recursive function
employees_server(Employees, Fn) for the actual server. employees_server/2 will track its
state in its arguments:
Employees
The current set of employees stored by the server.
Fn
The current processing function used by the server.
Have the function wait for a message on its mailbox using receive. There will be
three cases:
A stop request
Return from the function after replying with a {ok, stopped} message.
A new_fn request
Recurse with the same Employees and the new Fn.
Anything else
Run the Req using the current processing function Fn. Destructure the result into
{Status, Result, Employees1}. Send {Status, Result} back to the client and recurse with
Employees1.
The start_employees_server/2 will simply use spawn/3 and register/2.
14. Implement stop_employees_server/2; simply send a stop request to the server usings
its ID emps, wait for a response from the server and return the server’s response
message.
15. Finally, implement employees_client/2 in a manner similar to the RPC example
covered in class, using the server’s ID emps.
16. Iterate the above steps until all requirements are met and all tests pass.