I just added the papers on writing interpreters that I mentioned in class. Hutton's paper uses fold and unfold to define program interpretation. I find this to be a wonderful and approachable paper on the topic. Duponcheel's paper talkes about modular interpreters and although it is a bit more difficult to get through initially, it is definitely worth spending some time with. Both the papers and my notes on them are posted.

Project 3 is now available on the Projects Page. Read the project carefully and take note of the Bonus problems. Basically, they allow you to replace 2 problems on the final exam with scores for the 2 bonus project problems.

It's pretty amazing what you can find to do when you don't want to grade projects. In my case, I found time to write a few test functions for Homework 5. I've posted the file on the Resources Page.

Some generally useful notes for homework 5...

1. The boolean type is Bool and the integer type is Int
2. Use not instead of ~ for negation in booleans
3. Put lambdas in parentheses - (\x -> x+1)
4. Remember that all patterns must be in parentheses
5. When all else fails, add parenthesis to tell Haskell exactly what to do.
6. Remember the Maybe type!

Homework 5 is up on the Homework Page. No due date has been assigned yet. Check back later for a version that uses literate Haskell.

I made a small error in class concerning how to generate code for subtraction. The way I did code generation for x-y is resulted in:

(push x) (push y) (sub)

The problem is that this actually calculates y-x. The second argument needs to be pushed on the stack first. So, the code should be:

(push y) (push x) (sub)

Of course the order doesn't matter for addition, but if you do it in the same order as subtraction, you'll end up simplifying your code by only generating code one way.

I'll talk about this in class tomorrow. Until then, if you're looking at your assignment, the example show there is correct.

Use symbol->string to convert symbols to their string names... Read More...

Please ignore any emails you may have received about moving class on Friday. There is still no class on Friday, unless of course you just want to go hang out in the room.

A solution for Homework 4 is available on the Resources Page. There is a note in the assignment about the parse and elaboration functions. Unfortunately, those two questions were not well-formed on the assignment making them much harder than they needed to be. I will not grade them unless it somehow improves your homework assignment grade. I'll discuss problems with the questions in class.

I've had several questions concerning what parse and elaborate actually do. Here's a bit more detail... Read More...

I have posted a solution for Homework 3 at the bottom of the Resources Page.

Project 2 is up on the Projects Page. It currently has no due date - we'll talk about that next week.

Examples for Problem 1a,b are not helpful... Read More...

The date for our Midterm (more like late term) exam is October 31, Halloween, in class. I will give you a study guide to help with your prep the week before the exam.

The due date for Homework 4 is officially Monday, October 22 before class. i will also assign Project 2 around that time.

In our faculty meeting yesterday, we were informed that we can no longer send email to students with sensitive information (i.e. grades) using addresses outside the ku.edu domain. The belief is that it's too easy to spoof an address using an external, public domain email system. Basically, we have no idea who KU_beer_stud@gmail.com really is, even if someone tells us they own the address. On the other hand, KU_beer_stud@ku.edu is traceable to a particular person in the KU domain. I find this a bit silly, but I have to respect the University's intent to keep your private information confidential.

If I have a non-KU address on file for you, then I will be bugging you for a new address or a public key to encrypt your data. A public key is a far better way to ensure integrity and confidentiality, so I'm quite happy to use PEM if you want me to.

If you really want to use a mail system outside KU, my suggestion is to use a forwarding address so that your *.ku.edu email goes where you want it.

Updates to the Scheme FAQ and a small correction
Read More...

Homework 3 is officially due October 15 before class.

Homework 3 is now available on the Homework Page. You should be able to work all of the problems given lectures on Scheme so far. The due date is not set, but will likely be October 15 before class. Watch the blog for more info.

Lots of you are seeing the ConcurrentModificationException, which seems to be new exception that is thrown whenever you modify a list you are iterating over. There are a couple of ways around it. One is to use iterator methods to modify your collection rather than collections methods. Unless you are using the List interface, this is going to be tough. The other solution that should be rather easy to implement is to use the clone method to create a copy of the structure you are iterating over, iterate over the copy and modify the original. Because sequent elements are not ordered, I don't see any reason why you would need the iterator when you are modifying the collections that comprise a sequent.

This is an exception that, quite frankly, I've not seen before. It makes me wonder if it's a new addition in the new Java implementation. I'll poke around and see if I can find out.

We will be having class on Wednesday. One of my PhD students will be presenting the lecture.

I will be visiting DARPA in Washington, DC on October 3, thus I will not be in class that day. I will either schedule a makeup class sometime later in the semester or have one of my graduate students cover the lecture. Watch here for more details.

Here are a few thoughts on using the instanceof operator. Read More...

As promised, a few example test cases Read More...

A question was raised in class today about comparing propositions. When using the equals method that is used by the Collections class, two objects are equal if they are the same object. To get around this, redefine equals for literals to compare the names of the literals. Specifically, inside the literal class define an equals method that compares the string names used in the literals. This should avoid the same object problem mentioned in class.

An alternative is to use the same object version of equals and make sure you keep references to your literals after you create them. Then use the references when you create predicates using and, or, not and implies. This works equally well, but is a bit harder to do.

The due date for Project 1 is October 1, before class. Submit the project the same way as homework - create a tarball and email it to me with [EECS 368] at the beginning of the subject line. Please only send one project per group if you are working in groups. Make sure that you include both partners in the documentation or I'll have no way of knowing who to credit for the work.

I'm still working on getting homework scores distributed. In the mean time, please check your email for questions from me. Specifically, I had some difficulty getting a couple of projects to compile and some people sent me the wrong files. I was going to distribute this information when I sent grades out, but as that is still delayed I decided to send requests out now.

I forgot the most important Scheme command of all. You exit the interpreter by typing control d.

Project 1 is available on the Projects Page. I have not assigned a due date.

It's been pointed out to me that the EECS machines provide a version of Java that does not support generics. If you are using an older Java implementation like this, simply drop the type variables from your definitions and use Object instead. More specifically, drop all the instances of in our definitions from class and when you use E, use Object instead.

Once that's done, you have to cast Object instances back to the class you're using. This is easily done using the notation:

((shape) s)

to cast s from Object to Shape. Java will yell at you if you try to do an illegal cast.

I'm going to try to get the machines in the EECS department updated, but this is a huge task for the admins, particularly after the semester has started.

The collection class provides two kinds of methods for sorting and finding extreme values. One uses what is called the natural order of a class while the other requires a comparator. You are welcome to use either one. However, I am discussing the definition and use of natural order in class. Basically, you define a natural order for a class when you implement the Comparable interface. This interface defines a single method, compareTo that is used like this:

o1.compareTo(o2)

It returns -1 if o1o2.

When you implement this interface, any two instances of a class may be compared. Thus, a sort or max method knows how to compare objects without being told explicitly.

Using the comparator version of sort, max and min requires you to pass a comparator to the method. I'm not going to cover this in class, but I don't care if you use it.

As promised Friday, I'm slipping the Homework 2 due date until Friday, 9/14 before class.

As I mentioned in class, you can use length to check the length of an array. If you have an array defined as follows:

Shape[] shapes = new Shape[10]

you can find the length of shapes using:

shapes.length

The call shapes[].length will not work as shapes[] is nonsensical - half type half array. The call shapes[0].length will also not work as shapes[0] is a shape, not an array.

If you declare an instance variable, but do not initialize it, the value associated with the variable is null. Thus, if you declare:

Shape x;

the value of x will be null. The same can be said for array elements that are not initialized. Thus, you can find elements in your Shape array that do not have values by checking for null.

Recall that in class today when I first declared an array, I did this:

Shape[] shapes = new Array[10];

It was later suggested that you can use Shape rather than Array to allocate the array:

Shape [] shapes = new Shapes[10];

The second declaration is definitely the way to go. Instead of Array[10] use Shape[10] to allocate space for the array. I believe that Array[10] will work, but you'll end up with an array of Object rather than and array of Shape. Thus, you'll have to cast everything to Shape. Don't do that...

I've gotten several questions about documentation. Here are the answers:

1. Yes you need to do it.
2. No it does not need to be too extensive

Just a file header with your name and some simple documentation. It's also useful to identify where you answer each question. On this homework, it's no big deal.

For testing, I suggest writing a test method for each class or write a test class that builds and tests all of your classes. It's pretty easy to write a method that will use system.io.println to print out values from your classes. We'll talk more about testing over the semester - for right now, just show me that your classes are implemented correctly.

When we do full projects, I'll expect a bit more. This is just a homework.

If you're looking ahead, Homework 2 will be due September 10 before class. Same drill as Homework 1 - send me your source files (in a tarball if there is more than one file). Put [EECS 368] at the beginning of the subject line.

Homework 2 uses some techniques that we will likely not get to until later this week, so don't panic if it looks a bit difficult today.

September 3 is Labor Day, so the due date for Homework 1 has been moved to September 5 before class. The remainder of the assignment stays the same - submit your solution via email with [EECS 368] at the beginning of the subject line.

The title says it all. Homework 1 is now officially due September 3 before class. Email me your .java files with [EECS 368] in the subject line of your email. If you have multiple files, create a tarball for submission. No need to submit .class files.

If you're planning ahead, Homework 2 will be due one week after Homework 1.

Wait to buy your texts Read More...

Welcome to the EECS 368 course blog Read More...