At a basic level, the discipline of computer science seeks to solve problems that people care about; that is, computer science focuses on problem solving. Over the years, computer scientists have found at least four, fundamentally different views of problem solving to be particularly helpful. Each approach involves a distinct way of thinking, and each is supported by a range of computer languages. These paradigms may be outlined as follows:

• Functional Paradigm:
  Supported by such languages as Scheme, LISP, ML, Miranda, Haskell
• Imperative Paradigm:
  Supported by such languages as Pascal, C, FORTRAN
• Object-Oriented Paradigm:
  Supported by such languages as Smalltalk, C++, Java
• Declarative Paradigm: Supported by such languages as Prolog, Gödel

(Beyond the languages listed above, some programming languages try to combine several approaches within an integrated framework. As is common with many compromises, such hybrid languages may work nicely in approaching some problems, but also have substantial difficulties when used to address other problems.)

An investigation of these paradigms concludes that each is particularly good for working with some types of problems, but no paradigm consistently works well when solving all types of problems. Thus, people involved with computing need to become comfortable with several of these paradigms.

Since introductory courses at the University of Puget Sound highlight object-oriented problem solving with Java, student work with individual data fields and methods also provides modest experience with imperative problem solving.

This course focuses on two new and contrasting paradigms, which are quite different from the object-oriented and imperative worlds, supported by languages that may seem dramatically different from Java.

Paradigms and languages for this section of CS 291:

• Functional Problem Solving
  transformating data via functions (no assignment statements)
  supported by
  • Scheme
    • Not strongly typed
    • Flexible lists
    • Higher-order procedures
  • Haskell
    • Strongly typed
    • Higher-order procedures
    • Pattern matching
    • Lazy evaluation
  Declarative Problem Solving
  developing rules and applying the rules to data (no assignments or functions)
  supported by
  • Prolog
    • Logical inference built in
    • Extensive search of outcomes, based on rules

Henry M. Walker

Office: Thompson 104
Telephone: extension 3562
E-mail: walker@cs.grinnell.edu, henrywalker@pugetsound.edu

Office hours are posted weekly on the bulletin board outside my office, with additional hours possible by appointment. Please feel free to stop by during office hours; I will strive to work with students on a first-come, first-served basis—as time permits.

Materials for this course largely are on-line.

Scheme

• Compilers/Interpreters:
  • Chicken Scheme: https://www.call-cc.org/
  • racket: https://download.racket-lang.org
  • Chez Scheme: See link at http://scheme.com/download/ for current version
• Readings:
  • Largely on-line— see links on the class schedule
  • Scheme Progress Reports (Brief history of current Scheme Standard (revised version 7 "small language")
  • Revised⁷ Report on the Algorithmic Language Scheme (current Scheme Standard, "small language")

Haskell

• Compiler/Interpreter:
  • Glasgow Haskell Compiler: https://www.haskell.org/platform/
• Readings:
  • Learn You a Haskell for Great Good! (sorry about the book's title!)
  • Real World Haskell by Bryan O'Sullivan, Don Stewart, and John Goerzen
  • Tutorial Listing

Prolog

• Compiler/Interpreter:
  SWI Prolog: https://www.swi-prolog.org
• Readings:
  • Learn Prolog Now! by Patrick Blackburn, Johan Bos, and Kristina Striegnitz
  • Haskell: The Haskell Programming Language

While the schedule for this course is expected to evolve, a detailed Tentative Class Schedule is posted with readings, labs, assignments, examples, etc. This schedule will be updated as the course evolves.

This course includes a variety of activities, including class preparation (reading), labs and projects (started in class and finished for homework), and supplemental problems (some required and some available for extra credit), as well as quizzes, tests, and a final exam. From past experience, the time required for these activities will likely vary substantially from student to student and from one part of the course to another. For example, a student may need to devote considerable time and effort when starting a new or different topic, but the workload may drop noticeably when that material is mastered.

Such variation in student experiences complicates any estimation of the time individual students may need to devote to homework for this course. However, from past experience, students working steadily on the course likely should expect to allocate 10-15 hours per week to homework. Some students may require additional time for some weeks; some students may complete work in less time for some weeks. Conversations with computer science faculty and others suggest this time allocation is consistent with expectations for many courses at Grinnell College.

All programming for this course must meet reasonable standards for clarity, readability, maintainability, and efficiency. Also, submitted programs must compile appropriately, tests should demonstrate program correctness, and some commentary is needed to explain why programs produce correct answers. See Notes on Program Standards for details on writing and testing programs according to basic standards.

Course Work will involve a combination of the following activities.

• Projects: Each of the main segments of this course (e.g., involving Scheme, Haskell, and Prolog) concludes with a project that integrates several key elements of that problem-solving approach and language.

• Laboratory sessions introduce specific features of a problem-solving perspective and provide experience with elements of a supporting language. Together these labs highlight concepts and constructs introduced in readings and class, allow instructor assistance in a "hands-on" setting, and supplement normal office hours.

  Although students are responsible for material in every lab, the course requires students to complete selected labs most weeks—usally on Mondays. These labs require a formal write-up, explaining what work you have done, showing any programming you have done, indicating tests or experiments run, and giving your conclusions. Specific submission deadlines are given on the day-by-day schedule.

  Many lab activities should be done in groups of two or three, although you may work individually on labs after September 20. Only one write-up is expected per group.

  Lab Write-ups are due for specified labs. Turning in a lab involves two parts:

  • Turn in printed copies of all materials at the start of class:
    • Commentary from steps of the lab:
      • A title and list of co-authors at the top of the first page.
      • Answers to steps involving questions and explanations.
      • Test cases used, with results obtained.
      • Although the lab questions need not be repeated, the numbers of the questions should be given, and the material should be in the order of the lab.
    • Code Listings
      • Of course, formatting and comments are part of all work!

• Quizzes: A 15-20 minute quiz will be scheduled about every other week, usually (but not always) every other week at the beginning Wednesday classes. Altogether 7 quizzes are scheduled throughthe semster; in grading, the lowest quiz score will be dropped. These quizzes will focus on basic topics covered in recent past class sessions and/or the basic topics from the reading(s) for the day.

• Mid-semester Test: An in-class test is scheduled for Friday, March 13.

• Exam: The Registrar's Office has scheduled the exam for this course for 8:00-10:00 am on Monday, May 11.

Deadlines are shown on the Tentative Class Schedule, and work is due at the start of each class specified. A penalty of 25% per class meeting will be assessed for any assignment turned in late, even work submitted at the end of a class. However, an extension of at least one class period is automatically granted if the department's Linux network is down for an unscheduled period of three or more hours during the week preceding the assignment. Normally, a program or laboratory write-up is due every third class meeting.

Although dates for labs, programming assignments, tests, and the final exam are firm, I understand that circumstances arise when you are not able to attend class.

• When circumstances are known ahead of time (e.g., academic activities, athletic events), I expect you to make arrangements with me before the activity occurs. Normally, we will identify an alternative date for the due date or test.
• When circumstances cannot be reasonably anticipated (e.g., illness, family emergencies), I expect you to notify me as soon as is reasonably possible. (Email is fine.) In the case of medical problems, I expect a written note from a medical professional or counselor that indicates that your health interfered with the course activity. (I do not need to know any details of the medical problem, but I do need to know that you sought help and that the medical professional believed meeting the deadline would likely interfere with your health.)

Absolute Deadline: All homework must be turned in by Wednesday, 6 May at 5:00 pm;
laboratory reports or programs received after that time will not be counted in the grading of the course.

Collaboration often will be allowed on laboratory exercises, but collaboration normally will NOT be allowed on supplemental problems and tests. To avoid confusion, the rules for collaboration on homework are included in the specification of each assignment.

Cell phones, text-messaging devices, and other social-networking connections may not be used in this class. If you bring such equipment to the classroom, it must be turned off before the class starts and stay off throughout the class period. Use of such equipment is distracting to those nearby and will not be tolerated.

If you have specific physical, psychiatric, or learning disabilities and require accommodations, please let me know early in the semester so that your learning needs may be appropriately met. You will need to provide documentation of your disability to the Director of Academic Advising. Feel free to talk to me if you have questions or want more information.

For more information, see the Academic Handbook, pages 34-35.

In addition to course policies identified in this syllabus, the University of Puget Sound has asked instructors to highlight the following university policies:

• Classroom Emergency Response Guidance
• Student Bereavement Policy: See the Academic Handbook, page 9.

This instructor's grading philosophy dictates that the final grade should ultimately be based upon each student's demonstration of her or his understanding of the material, not on the performance of the class as a whole nor on a strict percentile basis. The following scheme is proposed as a base for how the various assignments and tests will be counted in the final grade.

created 24 June 2019 revised Summer-Fall 2019 grading clarification 29 February 2020
For more information, please contact Henry M. Walker at walker@cs.grinnell.edu.