Greatings from Annapolis!
Two quick updates on the project. I’ve updated the recursive test
case I provided to provide a proper type for
ie. It should be
Nat->Nat rather than just
Nat. It executes fine as is, but it is
not properly typed.
I’ve added the concrete syntax for
bind to the langauge in the
bind is in the abstract syntax and parser
provided, but I forgot to add it to the syntax description. This
should not have caused anyone difficulty, but could prove confusing if
you’re reading carefully.
As promised, here is a test case for
fix that implements factorial.
I’ve also included types so this should be a good test case for your
You should be able to drop this right into your
interp function. I
pulled out all the formatting so you can just copy paste. Here’s what
the test case looks like with reasonable formatting:
You can use
bind to create nice names like
we did in class.
This test case is nice because it tests a ton of functionality. If you can get it to interpret successfully, you’re in great shape.
The first version of the Project 4 description is available. I’m still cleaning up and testing the utilities file and will post it over the weekend. The project description contains listings of the various AST and value data structures. This should allow you to get started on the evaluators and type inference functions if you so choose.
Subject says it all. Project 1 is graded and grades are posted on blackboard. Please read comments I left as I had questions over some of your projects that impact project grades. I have asked for resubmission in some cases.
As promised, here is your test case for comparing dynamic and static scoping. First, the version that uses
bind before elaboration:
When I parse this example I get the following structure:
When I elaborate that result I get the following structure:
My statically scoped interpreter gives me
8 and my dynamically scoped interpreter gives me
I’ve tried to get the indentation set up so both arguments to each
app are lined up. Still, I suspect what you want is the concrete syntax for this expression:
If you’re using the string parser, you’ll need to get rid of the line breaks and turn the expression into a string using quotes.
For what it’s worth, I got this expression by writing an elaborator rather than trying to hand translate the
bind expressions into
If you look carefully at the project description and the utilities file for Project 3 you’ll notice the description uses the constructor
if0 for if expressions while the utilities file uses
if. It makes no difference which constructor you use. If you want to, you can change the utilities file to use
If0 to be consistent with the book.
I’m hesitant to push out a change until the project is done because I don’t want to accidentally mess anyone up. You can use the utilities file as is or change the constructor name and everything will work fine regardless.
I just made a small update to the definition of Project 3 to clarify differences in the environments for dynamic and static scoping. The original description used the same environment type name,
Env, for both static and dynamic scoping. However, what’s in the environment differs between interpreters. When using dynamic scoping, the value stored with an ID in
Env is simply a
CFAE value. You just reuse the datatype from your AST definition and you’re done. When using static scoping, the value stored with an ID in
Env is a
What this means is you can’t use the same
Env type in both interpreters unless you employ some Haskell type-fu that I don’t expect you to know. Fortunately it is not a big deal to fix and if you implement your interpreters in separate files you likely did not even notice. What I did in the new project description is define the two evaluation functions to use
EnvS respectively. This eliminates the type clash between the definitions with almost no pain.
If you already have your project working, do not go back and change it to use these new type names. There is no reason to do that. If you use separate files for your implementations, you can use
Env as shown in the original project description.
I just pushed a new version of the project description that makes a few corrections and updates the due date to April 20. Corrections include using the definition for
bind elaboration that we used in class today and fixing the link to the parser utilities file. Hopefully that was it.
I also mentioned in class it is okay to change return values to use
Maybe if you want to implement the interpreters monadically. Personally, I would use the
do notation and
Maybe, but it’s a matter of what you’re most comfortable with. There is certainly no requirement to use the monadic style.
Finally, I mentioned it is okay to use the Haskell
error function to throw errors on this project. Next project will worry about error handling.
I just pushed up a draft of Project 3. I’m still working on proofing and cleaning up the description, but thought I would push it up anyway so you can begin looking at it (or even coding). I do not have the two parsers quite ready to post yet, but you can start on the evaluators and elaborators without a concrete syntax and parser to work from. Hooking in the parser should be your last development step.
We’ll talk about when this project is due formally in class. In the mean time if you find errors or anything that confuses you, please do let me know.
An issue was raised concerning the parser in class today. I just built and ran the parser through a number of test cases and did not see any errors. Make sure you have the current version of
parserUtils.hs. Specifically, look at your version and make sure that
seq is listed as a keyword along with the list operations. If they aren’t there, you have the wrong version.
I’ve gotten quite a few questions about error handling for Project 2. For this project I’m not interested in how your interpreters handle errors. You should implement it, but I will not use test cases that would generate an error on a properly working interpreter. Nor will I use test cases that are not syntactically correct. We will care quite a bit about errors in future projects, but not this one.
As discussed in class today, I’ve come up with a bit of a hack to get printing to work as intended. It involves
performUnsafeIO, a function I would normally never want you to use. But, sometimes you’ve just got to get the program to run and now is one of those times.
First, you need to import the unsafe operations for IO:
You can then use this Haskell code to print
t, then return
(Num 0). Remember that
return is the same as
seq function in this snippet is the Haskell
seq, not the sequence you are implementing for your interpreter.
I hope this helps!
I’ve posted a collection of topics for the midterm in the Exams section of the class website. A good rule of thumb for studying is if it wasn’t covered in class, it won’t be on the exam. Also, there will be little if any Haskell programming. Focus on writing programs in the languages we’ve developed rather than programming in Haskell. You get plenty of Haskell completing your projects.
Well folks, Thursday was just a bad day all around. As it turns out my example for printing using
let to force evaluation doesn’t work. As it turns out I actually did something slightly different in my code that didn’t make it to the board in class. This will not work:
and lazy evaluation is the culprit. Kudos to those of you who caught this when I did it on the board.
i is not used, thus the
This forces the print to evaluate and then evaluates and returns
return (Num 0). This works in my code. You can either use this in the
do notation or a
One of you industrious entrepreneurs should develop a whiteboard that checks and executes code as it’s written. That would be majorly cool…
Given the outcome of yesterday’s game I have decided I will never again let class out early to watch KU men’s basketball. We tempted the Gods of Partial Credit and their retribution was swift. Sigh…
I just pushed several updates to the Project 2 description. There are no changes to what I want you to implement, but there were some parts of the description that were not clear or were associated with an older project. Should be easier to follow now.
Please bring your questions to class!
Several updates to Project 2 that should be of interest.
Due date is now March 16 rather than March 14. This is a direct result of great questions I got in class and during office hours. Plus, I wanted a chance to correct some errors and discuss again in class on March 14.
The exercise using QuickCheck is gone. You are welcome to use it, but I decided it was too much to learn for this project. Please do test your code, but you don’t need to use QuickCheck.
proj2Utils has been updated to eliminate cruft from an old problem I intended to assign. The data structures should work for you now. Note that the same parser and data structure should work for both exercises.
I’m providing a parser and AST data structure for Project 2 that you can base your implementations on. The file proj2Utils contains both the parser and AST structures you’ll need along with necessary imports. It’s easiest to simply copy the contents of this file into your project file.
I’ve also updated parserUtils to handle new keywords. You’ll need to download the new version if you want to use the Project 2 parser.
Project 2 is posted. I’m still proofreading, but the project details will not change. You will be implementing a simple print command and untyped lists. I am testing a parser and AST definition you can use for your implementation that should be posted by the end of the day. This project requires a bit more work than the previous projects, so please get an early start. As always I am happy to answer whatever questions you might have in class.
I made a small error in my notation for beta-reduction Tuesday. I wrote this:
The $t_1$ term should not be there. It should be:
I used the rule correctly, just threw in an extra term. Sorry about that. Again, this will not be on any exam, just FYI in class.
Lots of folks are having issues with the
interp function that combines the type checker, optimizer and evaluator for Project 1. The interpreter function I’ve defined looks like this:
and you guys are trying to use it verbatim. Unfortunately, the
eval function called by this interpreter and the
eval function I’ve asked you to write have different type signatures. Specifically,
eval from my implementation has the following signature:
This is much like the
bind interpreter we’ve been working on in class. Instead of an
Either type, this
eval returns an
interpTyped above returns a value of type
Either String ABE. Thus, when
eval returns a value it must be lifted into
Either String ABE using the
Right constructor. See the third line of
eval function for your your current project has the signature:
Big difference! This
eval returns an
Either type directly. There is no need to lift the return value using
Right as we did above. The
Right constructor can be dropped. Note the difference in the third line in his version of
This is why you keep hearing me say delete that
Right over and over again!
eval returns an
Either type that does not need to be turned into an
Either type for
interpTyped to return.
I just updated the Project 1 description to correct an error on the signature of
optimize. The original signature takes an
ABE and produces an
Either String ABE like the evaluator. The optimizer never generates an error. Thus, it’s perfectly safe to skip the error option and change the signature to:
If you have already implemented the optimizer with an
Either type, there’s no reason to change it. The optimizer will simply never return
Quick update to Project 1. The original description asks for a function,
typeof, with the signature:
that returns an error message or an abstract syntax value. It should have the signature:
that returns an error message or a type value. This should make better sense -
typeof returns either a type or an error message. The project description has been updated as of 17 February 2017 at 8:32 PM, so if you’re reading the project description for the first time after this date you can safely ignore this posting.
I have posted a draft version of Project 1 where you will write a type checker (surprise!) and a simple optimizer for an extended version of the ABE language. The project will not change substantially, so please feel free to start if you want. However, I will be proofing the project and making corrections before I assign a due date.
For Project 0 I am not requiring anything specific related to testing. In particular, you do not need to use QuickCheck. I’ve not covered that in class yet, but you can use it if you choose to.
Here are a couple of ideas that might help you with testing. The first is defining and naming a set of test cases that you can simply use over and over again:
This allows you to execute a single test case to see what happens. Another option is to
interp function over a list of strings:
This will return a list of results corresponding to your list of input strings. This has the simple advantage of doing all your tests in one function call.
Every time I teach this class, I learn something new about what can be confusing. This year’s first learning moment for me is error handling in Project 0. There has been significant wailing and gnashing of teeth over what to do with errors.
The answer is pretty simple.
Just let the interpreter crash.
I’ll even do you one better. I promise not to test your interpreters on bad test cases. Hopefully that will end the confusion!
I just updated the Blackboard submission site to allow for multiple submissions. If you want to resubmit before the deadline, you should be able to. I don’t know why Blackboard defaults to single submission attempts. Seems kind of goofy.
It just struck me that I’ve not gone over parsing
if expressions in class and you need to parse
if0 for Project 0. Thankfully, there is a great example of parsing
if in the source code from the Adding Booleans chapter. You should have no problem extending the parser for
if0 using that example.
The language extension mentioned in class today to get the parser working in the most recent versions of GHC is:
You’ll see in my files the extension:
You can just add
FlexibleContexts like this:
You do not need to worry about handling divide-by-zero errors in Project 0. I’m not going to test for that case. We’ll worry about errors in Project 1.
If you are curious and do want to catch this error, simply test the denominator value before performing division and use the
error function to throw a Haskell error. Don’t use
Either for this project. You’ll get plenty of that later.
Folks are having a hard time finding the
parserUtils file that I used in all my interpreters. Sorry about that. You can download parserUtils here.
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.
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.
I mistakenly scheduled an invited talk on January 20 that requires me to travel the afternoon of January 19. Thus, we will not have class that day. I will be available for office hours. Sorry about that.