head>
Consider the programming language Rust.
Write a report (PPT presentation, see below) discussing the following issues about Rust. These are issues and topics we have looked at with the other languages we have studied this semester:
Write your report as a PPT slide deck and submit to Sakai. Not one slide, not 80 slides... maybe 15-30 slides, whatever it takes to tell the story. Work on your own (no group work). In a class like this (seminar style) we would have presentations... if the size was also seminar size. But just the PPT will do with 40 people.
In this assignment we will do some Go proramming. Team work is fine on this.
You have installed Go on your computing platform. You have looked over the class notes, and the reading materials. You have tried writing basic Go.
Now, for submission, lets do some more advanced Go programming. Write a solution to the Sleeping Barber problem in Go. Put your code into a zip file for submission. Make sure to identify all of your team members for proper credit.
In this assignment we will do some basic Elixir proramming.
a) First, install Elixir on your computing platform. Look over the class notes, and the reading materials. Figure out how to compile and run basic Elixir code, both in the iex shell and also using the compilers elixir and elixirc.
b) Then, for submission, write the 3 smaller Erlang programs from Assignment 4 and Assignment 5 as Elixir programs.
Put the Elixir source code files into a zip file for submission. Make sure to identify all of your team members for proper credit.
In this assignment we will write an Erlang program that solves the Sleeping Barber problem we programmed in Java.
Feel free to use the Dining Philosophers Erlang solution posted in your class materials to help you make a solution.
In this assignment we will write an Erlang program that spawns several processes to cooperatively solve the problem.
Write an Erlang program that will use the "send_recv" module we discusses in the video as a pattern or guide. You will write a chain of 3 "servers" which are processes that are in a chain communication pattern. Lets call for this discussion the servers serv1, serv2, and serv3. The head of the chain is serv1, which will be communicating with serv2; serv2 will communicate with serv3. The serv1 process will receieve messages (from the main function) and possibly send what it received on to serv2. The serv2 process will receieve messages from serv1 and possibly send what it received on to serv3; likewise, the serv3 process will receieve messages from serv2 but will not send any messages onward.
The basic specs are these:
-- all 3 server processes run potentially "forever" (except each will end when a halt message is received) -- each one will examine messages it receives looking for ones that it knows how to handle; on finding one, it will processes it as its job requires; if a message does not match the pattern(s) that it handles, the server process will pass that message down the chain. -- serv1 will do much like the math servers from our example code. It will intercept messages that are tuples of size 3 or size 2. A size 3 tuple will have the first component the atom 'add', 'sub', 'mult' or 'div', and the rest of the message will be 2 numbers. Perform the indicated arithmetic operation with component 2 the left operand and component 3 the right operand. In addition, a size 2 tuple will have the first component the atom 'neg' or 'sqrt' and the second component the numbers to apply the appropriate operation on. For all messages, print an informative message indicating the operation, the operands, and the result. If the message does not match any of these patterns, then send the message on to serv2. -- serv2 will intercept mesages that consist of lists, where the head element in the list is a number. if that number is an integer, then print out the sum of all elements in the list that are numbers. If the head element of the list is a float, then compute and print the product of all the numbers in the list (integer or float). If the message does not match any of these patterns, then send the message on to serv3. -- serv3 will get all the messages that the processes earlier in the chain dont want to handle. If the message is a tuple of size 2, with the first component the atom 'error' then print "Error: " and the second component of the message tuple. For any other message keep a running count of the unprocessed messages. Simply print out "Not handled: " followed by the message; also bump up the unprocessed message count. To do this you will need an accumulator that you pass to each successive recursive server call. This means the serv3 function you make into a process will use a helper recursive function that takes one parameter (the accumulator) and starts with 0 as that parameter. -- each server process is doing some printing. Any output they make should have the first part indetify the process doing the writing -- something like "(serv1) whatever the output text is..." -- in addition to the various different message patterns each server process will watch for, all 3 processes will also respond to a shut down message. The message will be the single atom 'halt' and the server behavior will be to forward the 'halt' message down the chain, then print out that it is halting, and finally end its own execution (meaning do not recurse for more message handling). For the end of the chain, the serv3 process, which is counting all messages not processed, print a note with the value of that counter before doing its halt sequence,
The main function (let's call it "start/0") will repeatedly as the user to type a message as input, and will send the message to serv1 at the head on the chain. If the user types the atom 'all_done' then the main start function will end execution.
Feel free to embellish the program as you wish. Have fun with it.
You may work alone, or in groups of up to 3. In group work, the group produces a common solution and one group member submits the entire solution on behalf of all the group members. Put an erlang comment in your module source files naming all the group members, or naming the solo person doing the work. Put your source files into one zip file, and in Sakai, submit this single zip file.
In this assignment we will get Erlang running on your computers, and then write two simple Erlang programs.
Follow the instructions to get Erlang installed on your laptop or other computer. Try the examples we have looked at in class, and get used to making source modules (with the .erl file type). Make sure you move around in the file system using the unix-ish "cd", "pwd", and "ls" commands; make sure you can compile the modules; make sure you can run the functions defined and exported by those modules.
Here is a short new erlang lesson: getting input from the keyboard. This is a small function that will get a number from the keyboard, and you may use this as you wish in the programs you write:
get_numData() -> {ok, Num} = io:read("Enter a number: "), io:format("The number you entered is: ~w~n", [Num]).This works using pattern matching, where the number typed by the user is bound to "Num" on the left side of the expression using io:read.
Once this all works, write these two Erlang programs. You can put them both in one module, along with any supporting functions; or if you would rather, you can write two different modules:
a) if the input is not an integer, print "not an integer" b) if the input integer is negative (smaller than 0), compute the absolute value of that integer raised to the 7th power... and print that. c) if the input integer is 0, simply output the 0 d) is the input integer is greater than 0 then decide if it is a multiple of 7 or not; if it is a multiple of 7, print out the 5th root of the integer; if its not a multiple of 7, then print out the factorial of that integer.It ends after doing the correct thing with the input number. You may find math:pow(X,Y) useful... it returns a float, and it computed X raised to the Y power. Factorial is a function we defined in class (in a PPT).
You may work alone, or in groups of up to 3. In group work, the group produces a common solution and one group member submits the entire solution on behalf of all the group members. Put an erlang comment in your module source files naming all the group members, or naming the solo person doing the work. Put your source files into one zip file, and in Sakai, submit this single zip file.
Please use class time today to get into teams and consider this: How can we use ChatGPT (or other large language model, generative AI) as a sort of "high-level" or abstract compiler? Can we give specs to it that are "informal" (in English) and get it to generate specific, executable code? We know we can in some ways... in that if we ask it to write a bubble sort in C++ it will. It has basically "memorized" all the code out there and does matches as best it can. There is more trouble if we ask it to write code for something that does not have a canned name (like bubblesort). We are left trying to write a prompt that has enough information in it about what we want, and is unambiguous enough, to get working code that meets our needs. So we still have a situation similar to using Guttag's method for ADT specs. We are trying to be as formal as we can without just writing detailed code ourselves. ============== The point of our exploration of Guttag's method for algebraic axioms for ADTs has been to formally specify some computational behavior without getting into details of any particular programming language or implementation structure. We want a specification notation that is mathematically manipulable and unambiguous (informal English is neither). We are also then using SML as a vehicle for implementing such abstract algebraic specs because the translation from axiomns (in functional notation) into functional code is fairly straightforward. But we could code from formal specs into other languages. Try using ChatGPT as our "compiler" from formal specs to code. Try getting ChatGPT to write SML code for things like the ADTs we are working with... Stack, Queue, MAP, etc. Also try it with ADTs that are not well-known by name... maybe Bounded Stomp Stack ... or make up some different ADT of your own and see if you can get the code by giving the axioms as specs. Come to class Tuesday next week with some examples we can discuss. Perhaps capture your ChatGPT interactions in a text file which you have on the web someplace so we can project it and discuss it.
You will be writing ML code (as we did in class) to implement ADT axioms for several ADTs. Use the method we looked at in class for encoding them in ML. For some of these, I give you axioms and you simply encode them into ML. For some I ask you to write the axioms as well as encode them into ML.
For the SML code, just use datatype definitions (for canonical ops) and partial function defintions (for non-canonical ops). Also exceptions and basic SML stuff. Don't use more complicated module features like signatures, etc. Let's just stick to the basics like the class examples.
Include test code with each SML implementation... in other words, "prove" to me the semantics of the ADT are correct and the implementation works properly.
In Sakai, Upload a zip file containing your ml source files. Also include in that a text file with the names of the group members, if you worked in a group.
Prepare a single document (PDF, or Word) that contains your
answers to this discussion question.
Then submit it in Sakai for Assignment 0 as a single PDF file.
Due: Sun. 9/3 9:00pm in Sakai
You are allowed to work together in teams of size 1, 2, or 3
this semester.
So form teams and let me know the team compositions.
Send me email (to the class account)
telling me the names of the students in your team.
If you are a team of 1, send me email as well
saying so.
I want to make sure all names on our class
roster are accounted for.