Programming Languages Qualifiers

What you should know

Topics:

You are responsible for anything we did during the semester.  However, you should be particularly sure you can do the following:
  1. Know the way we classified programming paradigms and be able to evaluate the pros and cons of each paradigm.  Of course, the pros/cons should be in your own words (not a textbook definition), and you should be able to come up with examples supporting your arguments.
  2. Be able to write non-ambiguous BNF grammars, including proper handling of issues such as associativity, precedence, etc.  There are several BNF syntaxes in the literature - although I am not a stickler for which syntax you use if you get it 100% right, you will not get the benefit of the doubt for partial credit if you make errors while using another BNF syntax.  Also, make sure you know the difference between EBNF and BNF, and be able to use either.
  3. Know how parse trees and ASTs work, differences between them, and when/why we use them.  Also, know about control flow graphs. 
  4. For all 3 types of semantics (operational, denotational, axiomatic), be able to express the formal semantics of some new informally-specified construct.  This includes being able to identify and clarify potential ambiguities in the informal semantics.
  5. For all 3 types of semantics, be able to reduce/prove programs.  This includes the identification of assertions for Hoare logic.  You do not need to memorize the rules themselves, though you should understand them and be able to apply them.
  6. Write and understand small Haskell and Prolog programs.  In addition to basic data structure manipulations, you should also know how to handle the following:
    1. Haskell: datatypes (primitive, collections, user-defined, composite, recursive, parametric), type system, higher-order functions, infinite data structures, list comprehension
    2. Prolog: data structures (lists, structures), unification, non-determinism, cut, negation/control.  Any code you write should be as declarative as possible and follow proper Prolog style (I do take a few points off for writing in a non-Prologish way).  
    3. Both: you should know when to use which language as it is quite possible that I ask you to write a program in either language.  Since there are  programs that take 2 lines of Prolog vs. 2 pages of a functional language, you should choose wisely.
    For any programs you write, you are not allowed to use anything in the library nor may you assume that some other function or constant data structure is available - if you need it, you need to write code to implement it.  I will not take points off for a single minor syntactical error (e.g., a missing punctuation mark) unless it makes your program ambiguous; however, syntactic errors that reflect a major misunderstanding of the language paradigm will get points off. 
  7. Understand the theory of functional programming (i.e., lambda calculus).  This includes reduction mechanisms, the Church-Rosser theorem, and so on.
  8. Understand the relationship between Prolog and FOL, and be able to convert between the two.  This includes issues related to negation.  You should also understand how other logic programming languages (whether its one we covered or one I define on the exam) relate to Prolog and FOL.
  9. Know what strong/weak and static/dynamic typing are (and differences between them).  You should also know the different notions of type equivalence and how to do type inferencing.
  10. Be able to define abstract data types formally.
  11. For all problems, be able to cogently explain your answers!  An incorrect answer with good explanation normally gets more credit than a correct answer with poor explanation.  Of course, correct answers with no explanation get zero credit.

Format:

The test will be similar to the two class tests with the following differences:
  1. It will be about 40% as long as the second test.
  2. There will be less of an emphasis on the more subjective questions.
  3. I expect the questions will be less difficult than harder test questions, but they will mostly not be trivial either.
  4. If there are wide-open 'thought questions', you will get to pick m out of n questions.  In such cases, do not answer more than m questions, as I will only grade your first m answers regardless of how brilliant your m+1'st answer is.
Currently, I anticipate that 50% of the test will be writing/analyzing Haskell/Prolog programs, and the remaining part will be selected from the other topics summarized above.

I want to add that the test is not multiple-answer. If you give more than one answer, only the first will be graded regardless of how brilliant your other answers are.

I don't think there is too much to memorize.  However, if there are things you feel are pure memorization, please let me know soon, and I will try to find a way to relax this burden. 

Studying:

You want to go through all the homeworks during the semester. Ask yourself what the main concept behind each homework problem was and gain an intuitive understanding of it (you will get >90% if you do this). A common mistake is to memorize large quantities of examples - this seldom helps since you will still be unable to solve the next example that appears on the qualifiers.

Test Directions 


You should be familiar with Louden's toy language for the test.  Recall that there are some oddities in Louden's language, arising from the lack of non-integer datatypes (see Section 13.1). 

You will be supplied the following information on the test (if there are questions needing them), and you do not need to memorize them:
If there are questions with multiple parts, they will be designed so that you can still answer other parts if you don't know one part.

I will place a copy of the directions here soon.  You want to read it and make sure you understand it before the test - feel free to leave email. 

Directions (verbatim from test):

Directions
  • Answer ALL QUESTIONS
  • You should produce the best solution to each problem, as grades will be based on your approach as well as the correctness of your solution.
  • As a general rule, partial credit is more likely if you explain your work.
  • The test has been proofread several times to ensure that there are no errors or ambiguities. However, if you feel that a question is ambiguous, state your assumptions and solve the problem under those assumptions. If the assumptions are reasonable and do not trivialize the problem, you will get full credit.
  • Please write your answers on the supplied bluebooks (NOT on this test).
    • Directions to Programming Paradigms Part:
    Write programs for all parts. Examples are provided for some of these, and your program should be compatible with the appropriate syntax. Additionally, you must follow the following language-specific guidelines:
    In all cases, you may assume the inputs meet their specifications, and you do not need to do any error checking to ensure that they do. Your programs will not be graded on efficiency (within reason)