Subject says it all. Take your notes from last lecture and burn the last 20 minutes. The second definition of evaluating
fix is wrong and was not supposed to be in my notes. Yuck. I added the definition after last semester when I thought I had reformulated
fix evaluation to be clearer. When I implemented the interpreter I discovered it was wrong. However, I forgot to delete the new version from my notes. Very BAD
The initial definition that is still in the notes is fine as is the example using
fact following. I’ll walk through the example in class on 11/16 and will not trust my notes!
Feel free to boo if I do that again…
I just updated the Project 3 due date on the website - November 15, 2018 at 11:59pm. Forgot to update it after making the announcement in class. Sorry about that.
In class I mentioned a paper by Graham Hutton called “Fold and Unfold for Program Semantics”. I’ve uploaded a tarball that includes the paper and a companion paper I wrote that includes Haskell sources for programs in the paper. Hutton is an oustanding writer, so I think you will enjoy the paper if you are interested in generalizing the interpreter pattern we’ve been using in class.
I just pushed Project 3 to the website. No due date yet, but I will take about it in class today. As you may have guessed it adds functions to our existing interpreter. However, it also adds an elaborator that implements
bind and Booleans using functions. Should be an interesting project and will require a bit more thought on your part.
I just pushed Project 2 to the website so you can get started on it early if you would like. I will discuss the project on Tuesday in class and we’ll decide on a due date. The project requires implementing a type checker for our language with
bind in addition to two interpreters. One interpreter will use
subst and the other will use an environment just like we did in class. The type checker is not difficult, but I will discuss it in class before I expect you to start working on the project.
I will be out-of-town attending a DARPA PI meeting September 24-28, thus we will not have class that week. My plan is to schedule an optional make-up session for those who are interested.
The DARPA meeting is for the stairCASE effort we are working on with Rockwell Collins, Data61, Galois, Adventium and K-State. We are developing techniques to statically prove security of a mission planning system for UAVs. KU’s task is developing a remote attestation system with formal properties that integrate into static analysis results. This includes a language (APDT) and tools for checking and interpreting it. I’m happy to discuss with anyone intersted or talk about the project in class.
I just pushed a new version of
p0.hs to the website that loads under my GHCI installation. The problem seems to be related to the QuickCheck libraries that are not used for this project. I have vague memories of issues with Parsec libraries as well, but those load fine for me. If you are having issues with the new
p0.hs file loading, please let me know asap and I’ll look further into the issue.
I suspect that if you do a full Haskell Platform installation that includes all the libraries, this problem will go away. I have not tried this, so no guarantees. Hopefully I’ll get a chance to try it before class tomorrow.
I’ll hit this in class today, but posting here in case anyone misses lecture.
In the first problem on Project 0 I ask you to use the Haskell
error function to throw an error in your interpreter. This is not hard. In fact, it is so not hard that I forgot to cover it in class for those who have not seen it.
When you want to halt a Haskell program in an error state, you can always use:
error "nifty error message"
This causes your program to terminate completely and generates the error message specified. You can use this where you might otherwise use
Nothing in a monadic interpreter. However, your program terminates immediately and returns no value. This is quite different from
Nothing which is a value that indicates the computation was not successful. Very different things, but useful in the same situation.
I have been systematically making an error when writing
case expressions on the board in class. Specifically, I’ve been using this syntax:
case e of a in x = b y = c z = d
Haskell requires using a guard syntax rather than an equal syntax in
case expressions. The above should be:
case e of a in x -> b y -> c z -> d
-> instead of
= and everything will be fine.
Sorry about that! The code in the online notes is correct.
Welcome to the website for EECS 662 - Programming Languages at the University of Kansas. Contents of this blog are available via an Atom feed that can be viewed using any RSS reader. Use this url. Please check here frequently for breaking news and information about projects and exams.
Project 0 is now available if you want to get started. I provided a
template file that sets GHC options, defines the
AE data type, and
defines signatures for each function required for the
project. Hopefully this will help you get started.
Please note that a parser is required only for Exercise 4 and I
provided the parser in the template file for you. Also note that
numbers in this parser are
natural and should never be negative. The
example we did in class today allowed negative numbers.
We’ll talk about testing later, but if you are brave there is a QuickCheck implementation for part of this language in the examples associated with the text. I do not expect you to use QuickCheck, but I will use it for grading.
The language extension to use GADTs in the most recent versions of GHC is:
Include this pragma at the top of your source files and the GADT notation I use in class will be available.
In my notes and in class I have been using the GADT notation when defining data types. I do this because it closely resembles other languages that I use and we will most likely use GADTs later in the semester.
If you prefer the traditional notation that you learned in 368, you are more than welcome to us it. For early projects, there is no read advantage to using the GADT notation.