Introduction to several major high-level programming languages and their characteristics. Programming projects are required in at least three languages.
Instructor:
William H. Mitchell
Teaching Assistants:
Alex Koltz (Undergraduate TA)
Michael Ordaz (Undergraduate TA)
Up-to-date contact information, office locations, regular office hours, and any temporary variations such as additional office hours can be found here.
If I need to contact you for any reason, I will consider mailing to your email.arizona.edu address to be a guaranteed way to contact you in a timely fashion.
The prerequisites are very modest but this is a 300-level computer science class with a lot of diverse content. As an analogy, imagine a 300-level math class with only high-school algebra as a prerequisite but that will venture into some exotic math that's not much like algebra at all. My task is to respect the prerequisites but also cover a body of material that's appropriate for a 300-level CS class.
The purpose of this course is to explore some alternative ways of specifying computation and to help you understand and harness the forces that a programming language can exert. We'll spend most of our time working with three languages: Haskell, Ruby, and Prolog. Functional programming will be studied using Haskell. Ruby will be used to explore imperative and object-oriented programming using a dynamically typed language. Prolog will transport us into the very different world of logic programming. You'll learn about some interesting elements of other languages.
Upon successfully completing the course you'll be around a "2.5" on a 1-5 scale (5 high) with Haskell, Ruby, and Prolog. You will understand the characteristics of the programming paradigms supported by those languages and be able to apply some of the techniques in other languages. You'll have an increased ability to learn new languages. You'll have some idea about whether you want to pursue further study of programming languages.
Attendance is expected but will not be recorded. Students are, however, fully responsible for all material presented in class. Class attendance is strongly recommended.
Students who appear to be chronically tardy will be required to meet with me to discuss ways to improve their punctuality.
If you miss a graded activity for circumstances beyond your control or your absence is excused by university policy, I'll be happy to meet with you and discuss ways to recover any lost points.
Here are some related UA documents:
We'll be using Piazza for announcements and discussions. If you haven't already signed up, do it now!. Go to piazza.com. and follow their instructions.
There's more about Piazza below.
The course website is https://www2.cs.arizona.edu/classes/cs372/spring18.
D2L will be used for posting grades.
A large portion of the course material will be presented using PowerPoint slides. Those slides will be available on the
course website in the form of both .pptx files and PDFs. Students will be provided handouts with 4-up, two-sided copies of all slides, in installments.
Students have three options for those handouts:
372s18@cs with your preference and we'll adjust the copy count. If your preference later changes, just let us know.
IMPORTANT: The first page of each handout set will be marked in some way with "ANSWERS" or "NO ANSWERS". When you arrive for lecture be sure to take a set (or not) in accordance with the handouts preference you've expressed.
Any leftover handouts will be placed on the metal bookshelves near the freight elevator at the west end of the eighth floor of Gould-Simpson.
No textbooks are required.
It is my intention that the lectures, handouts, Piazza postings, and various no-cost materials on the web will provide all the information needed to successfully complete the course. However, it's often good to see things explained in multiple ways. Below are some books that I recommend as good supplements but it's important to understand that the routes we'll be taking through the languages don't directly correspond to any book; the slides are the primary "text".
Prolog Programming in Depth, by Covington, Nute, and Vellino
http://www.covingtoninnovations.com/books/PPID.pdf
I'll make available on the course website an OCR'd version of Covington's book with a hidden text layer added, so it can be searched.
Note that Safari can be accessed off-campus using the VPN or by using the library's proxy. Here's the proxy-based URL for Safari: http://proquest.safaribooksonline.com.ezproxy1.library.arizona.edu/ Hit it and then click "Start Using Safari" under "Academic License & Public Library Users".
Assignments will largely consist of programming problems but other types of problems, such as short answer questions, essay questions, and diagrams, may appear as well. There will be a video project, too. As I write this I anticipate that there will be eleven assignments including the video project. Larger assignments will be assigned about two weeks before they are due; smaller assignments will have shorter "fuses".
For programming problems great emphasis will be placed on the ability to deliver code whose output exactly matches the specification. Failure to achieve that will typically result in large point deductions, sometimes the full value of the problem.
My view is that it's a Bad Thing to give any credit for code that doesn't work. Programs that don't compile or that mostly don't work will earn a grade of zero, regardless of how close to working they might be. Additionally, solutions that are non-general, with expected output hard-coded, for example, will earn a grade of zero.
Unless specifically requested in an assignment write-up, no comments are required in any code. Use comments as you see fit.
Each assignment will specify an exact due date and time. As a rule, late assignment submissions are not accepted and result in a grade of zero. There are no late days.
Extensions may be granted to the class as a whole if problems arise with an assignment or with departmental or university computing facilities.
Extensions for individuals may be granted in certain cases. The key factor that leads to an extension is that due to circumstances beyond the student's control, the student's work is, was, or will be impeded, and it is impractical or impossible for the student to make up for the lost time.
Accident, illness, friend/family crises, and significantly disruptive failures of technology are examples of circumstances that I generally consider to be beyond a student's control. On the other hand, for example, an extension due to assignments or exams in other classes is extremely unlikely. Travel, such as an interviewing trip, may merit an extension, but pre-trip discussion and approval of the extension is strongly recommended. Unexpected hours at a job, such as needing to fill in for a sick co-worker, may warrant an extension. Ultimately, however, each situation is unique; you are strongly encouraged to contact me if you believe an extension may be warranted. If you believe an extension is warranted, DO NOT work on an assignment (or even think about it) past the deadline; wait for an extension to be granted.
Extensions are granted in the form of an amount of time, such as eight hours. An eight-hour extension can be pictured as a count-down timer with an initial setting of eight hours. The timer runs whenever you are working on the assignment, whether that be typing in code or simply thinking about it.
Here's a scenario involving an extension:
Your new laptop catches fire and burns itself into a cinder eight hours before a midnight deadline on a Wednesday. I would likely grant you an eight-hour extension. On Friday, your next chance to get to the store, you get a new laptop and you're operational by Friday night. You might spend four hours Friday night working on the assignment, take off all day on Saturday and Sunday, spend two more hours on Monday and get absolutely stuck, and finish it up after a couple of questions during office hours on Wednesday.If given an extension, you'll be required to keep written track of the time spent and not exceed the amount granted.
Your solutions will be graded on the CS machine named "lectura", so be sure to test them there.
By virtue of being enrolled in this class you should already have a CS computing account with the same name as your UA NetID but with a password that's likely different. With that account you can login on any of the CS instructional machines, including lectura. The files in your home directory tree are stored on a server and appear the same no matter which CS machine you're logged into.
My UNIX slides from 352 in Fall 2015 have details about logging into lectura, resetting your password, and more. Those slides are here. See slides 14-21 for details about logging in. Slides 74-102 discuss options for editing files on lectura and tools like WinSCP and DropSync, to keep directories on lectura synchronized with corresponding directories your laptop.
The CS computing facilities are described in http://cs.arizona.edu/computing/facilities. The FAQs at http://faq.cs.arizona.edu have lots of answers.
The university as a whole and the CS department in particular is experimenting with collaborative learning. Our classroom is a Collaborative Learning Space.
Barkeley et. al studies collaborative learning in depth. A definition of theirs that I especially like is this:
Collaborative learning is two or more students laboring together and sharing the workload equitably as they progress toward intended learning outcomes."
We'll be doing some collaborative learning exercises in this class. This will be my first use of collaborative learning in a course. I anticipate some number of surprises and flops but hopefully some successes, too. I welcome your frank and honest feedback on the exercises we attempt.
Exercises will typically be done during the class period. Group size will vary and groups may be formed in various ways including random selection.
Exercises will be graded, but primarily on the basis of participation and cooperation. Exercises will be considered a form of assignment and assigned some number of assignment points.
There will be "pop" quizzes from time to time. Quizzes will typically be a handful of questions displayed on-screen, be allocated three minutes or less, and be worth 1-5 quiz points. Quizzes may be conducted at any time during the class period. In some cases a quiz may be graded simply on the basis of participation rather than correctness.
There will be two examinations: a mid-term and a final.
The mid-term exam is tentatively scheduled for Monday, March 19. It will cover all the Haskell material and some amount of Ruby.
The Spring 2018 Final Examination Schedule specifies that our final exam will be Tuesday, May 8, 2018, 3:30-5:30pm. It will be in our regular classroom. The final exam will be comprehensive but with more emphasis on Ruby and Prolog than Haskell.
My goal is to distribute language-specific points as evenly as possible between the three languages, across both assignments and exams.
For reference, Final Examination Regulations and Information is here.
My goal is for everyone to earn an "A" in this course.
The final grade will comprise the following:
| Assignments | 60% |
| Pop quizzes | 5% |
| Mid-term exam | 13% |
| Final exam | 22% |
Final grades will be based on a ten-point scale: 90.0 or better is a guaranteed A, 80.0 or better is a B, and so forth. The lower bounds may be adjusted downwards to accommodate clustering of grades and/or other factors.
It is my goal that you will need to spend, on average, no more than ten hours per week, counting lectures, to learn the course material and get an "A" in this course. If you find that you're needing to spend more time than that, let's talk about it.
Each problem on an assignment will be assigned an exact number of assignment points. Ideally, the sum of the assignment points for all of the semester's problems and collaborative learning exercises will be 600, making each assignment point correspond to 0.1% of the final grade. If for some reason the the total number of assignment points is not exactly 600, assignment points will be scaled. For example, if a total 625 points of problems appear on assignments and collaborative learning exercises, each assignment point will correspond to about 0.096% of the final grade.
Similarly, a total of 50 quiz points will ideally be assigned, making each quiz point worth 0.1% of the final grade. If that ideal isn't met, quiz points will be scaled.
My goal will be to get each assignment graded before the next assignment is due. My goal will be to get the mid-term exam graded in a week. The final exam will be graded in accordance with deadlines for final grade submission.
You are strongly encouraged to contest any assigned score that you feel is not fair. The absolute deadline for contesting a score is the moment your final exam begins but the sooner the better. Otherwise you may be faced with an incomplete, depending on the staff's end-of-semester workload.
Requests for incomplete (I) or withdrawal (W) must be made in accordance with University policies, which are available at http://catalog.arizona.edu/policy/grades-and-grading-system#incomplete and http://catalog.arizona.edu/policy/grades-and-grading-system#Withdrawal respectively.
Throughout the semester there will be a number of opportunities to earn an assignment point or two of extra credit. For example, simply providing a good estimate of the time spent on an assignment will be worth a point.
A "bug bounty" of one assignment point of extra credit will be awarded to the first student to report a particular bug in an assignment. Bugs might take the form of errors in examples, ambiguous statements, incomplete specifications, etc. As a rule, simple misspellings and minor typographical errors won't qualify for a bug bounty point; but each situation is unique—you are encouraged to report any bugs you find. Any number of bug bounty points may be earned for an assignment and will be added to the grade for that assignment.
Bug bounty points may also awarded for bugs in the slides, my Piazza postings, quizzes, exams, and this syllabus. Such points are added to the next assignment.
Please report bugs by mail or IM, not via Piazza, to give us a chance to filter any false positives.
Don't interrupt class to point out minor bugs on slides such as typos but do speak up if an error seems serious or potentially confusing.
I truly enjoy working with students. I believe that interaction with students outside the classroom is a vital aspect of teaching a course. I will do everything possible to make myself accessible to you.
I prefer to conduct office hours in a group-style, round-robin manner. You needn't wait in the hallway if I'm working with another student; just come on in and take a seat. If several students have questions, I'll typically work for 5-7 minutes with each student in turn.
If for some reason you would like to speak with me in private, let me know. Or, make an appointment to meet with me outside of office hours.
Students who make proactive, not reactive, use of office hours usually achieve the best results. Proactive use of office hours includes asking questions about material on the slides and in the texts, asking questions about how to better use tools, discussing how to approach problems, etc. If you're familiar with Covey's The Seven Habits of Highly Effective People you might recognize those as "Quadrant II" activities—important, but not urgent.
Reactive use of office hours is typically centered around simply getting code to work one way or another (Covey's "Quadrant I"—important and urgent).
As mentioned above, we'll be using Piazza. All students are strongly encouraged to participate freely. I hope you’ll post questions and comments related to the course material, recommendations for handy tools, URLs for interesting things on the web, and whatever else you think is worth mentioning as long as it relates to the course material in some way. Posts about CS-related job opportunities, and events like programming contests and hackathons are welcome, too.
The initial post in any discussion thread that a TA or I start is considered to be part of the course material—you are responsible for reading each and every one, and taking action when appropriate. For example, I might ask you to read an article, or experiment with a web site of interest. You may learn more by reading follow-ups by classmates and by me, but at exam- or quiz-time I won't expect you to have read each and every follow-up.
When answering questions on Piazza, course staff will give priority to well-focused questions. And, it's often the case that the task of developing a well-focused question will lead you to an answer on your own.
You can make anonymous posts, but be aware that such posts are only anonymous to classmates, not to course staff.
Needless to say, BE CAREFUL that Piazza posts don't give away the solution for a problem.
If at all in doubt, use email instead.
A common case for a post that gives away a solution is when a student is very close to a solution but doesn't realize it, perhaps because a tiny piece is missing. Haskell and Prolog solutions are often very short, sometimes just a line or two, so posting any code or describing any elements of a solution is very risky.
Piazza's "Private posts"—posts seen only by course staff—are disabled. Use email instead.
Part of the idea of Piazza is to facilitate students helping each other, so don't hesitate to answer questions when you're so inclined. If a post is plain wrong, I'll add a correction. If a post is great, I'll endorse it. If I'm silent, then its quality is probably somewhere in the middle.
If you post (or email) a question and later solve it yourself, BE SURE to post a follow-up saying the question has been resolved.
If you don't, we'll needlessly spend time answering your question. In turn, that might lead to us not having enough time to answer
a classmate's question. In a worst case that might cost a classmate a letter grade, and even make a pass/fail difference!
I don't like the idea of students needing to dig through dozens of Piazza posts and follow-ups to resolve questions about an assignment. On the course website there will be a FAQs and Corrections page for each assignment that addresses whatever turn out to be good questions, along with any corrections that are needed.
If everybody can get in the habit of checking the FAQs and Corrections before posting on Piazza, that'll raise the signal-to-noise ratio on Piazza.
To reduce clutter in the FAQs and Corrections, errors like typos, wrong fonts, and doubled words that don't affect meaning will
be fixed on the spot and not mentioned in the list of corrections. Errors of consequence will be ennumerated. A Git repo will
be used to record, at minimum, the initially posted version of each assignment.
For private communication with the TAs and me, mail to
If an email message asks a question or raises a point that I think should be shared with the class, I'll share it. If I think the post deserves kudos, I'll identify the author unless the post specifically requests anonymity, in which case I'll say something like "A student wrote..."
IM can be very effective, especially for short questions. At present I mostly use Skype and Discord. My IM usernames can be found in the contact information.
Don't pay much attention to my IM status—sometimes I'm not available when I'm "online", and at other times I might be invisible but happy to answer. I recommend you start with an "ayt" ("Are you there?") and then follow with your question if I respond.
In the movie comedy "Broadcast News" a 14 year-old high-school valedictorian receives a post-commencement beating from a group of bullies. After picking himself up, one of the things he shouts to wound his departing attackers is, "You'll never have an original thought!" That notion of an "original thought" has stayed with me. I hope that you'll have some original thoughts during this semester.
I offer an award of a half-point on your final average for each Original Thought. Observations, analogies, quotable quotes, and clever uses of tools and language constructs are some examples of things that have qualified as Original Thoughts in my classes. Note that an Original Thought does not need to be something that's probably never been thought of before; it just needs to be something that I consider to be reasonably original for you.
Sometimes I'll point out that something you said in class or office hours, or wrote in your observations for an assignment, strikes me as an Original Thought. If you self-identify a potential Original Thought, let me know. In some cases I'll see a glimmer of an Original Thought in something, and encourage you to explore the idea a bit more.
Of course, an Original Thought needs to be something you’ve thought up yourself—don’t send in something you found elsewhere, like a quote, just because it strikes you as being original!
The "bar" rises with each Original Thought for an individual—it's harder to earn a second Original Thought than a first, and a third is harder still.
It is unfortunate that this section need be included but experience sadly shows that some students are willing to sacrifice their integrity to obtain a grade they have not earned. For those students who would never cheat, I apologize for the inclusion of this section.
Capsule summary:
You are responsible for understanding and complying with the university's Code of Academic Integrity. Among other provisions, the Code demands that the work you submit is your own and that submitted work will not subsequently be tampered with. Copying of another student's programs or data is prohibited when they are part of an assignment; it is immaterial whether the copying is by computer, photograph or other means. Allowing such copying, thus facilitating academic dishonesty, is also a Code violation.
In addition to ruining one's grade and damaging one's future, the processing of an academic integrity case requires hours of work by myself and others.
I am happy to spend hours helping a student who is earnestly trying to learn the material, but I truly loathe every minute spent on academic integrity cases.
Even the very simplest of cases often takes 3-4 hours of my time, not to mention the time of office staff and others. In my mind, the time to handle a case is simply unpaid overtime.
A violation of the Code of Academic Integrity will typically result in ALL of the following sanctions:
When a student is caught cheating and I remind them of the above sanctions they often respond by sending me an email message that is hundreds of words long. They usually start by saying that a failing grade is surely sufficient punishment and that they have learned their lesson; they won't cheat again. They go on to say that some employers won't consider hiring a student whose transcript shows evidence of cheating. (True!) Then they talk about how a suspension from the university will cause them to lose scholarships, job offers, visas, and more. Some mention ill or aging family members who might not live to see them graduate if a suspension is imposed.
If you ever find yourself considering whether cheating is worth the risk, first imagine how the three sanctions above would impact you and your family. I'm willing to go to great lengths to help students learn the course material but if a student cheats, I'm equally willing to impose great penalties.
It is difficult to concisely and completely describe where reasonable collaboration stops and cheating begins, but here are some guidelines:
Conversely, further dishonesty when confronted, which invariably increases the time expenditure, raises the likelihood of more extensive penalties, such as a recommendation for a multiple-semester suspension or outright expulsion from the University.
Failure to take reasonable precautions to ensure the privacy of your solutions may be construed to be facilitating dishonesty, a Code violation.
For example, having a weak password such as, but not limited to, your first name, your last name, your phone number, your initials, your sweetheart's name, your pet's name, a reversed name, a sequence of consecutive keys, or a common password could be viewed as facilitation of dishonesty.
Leaving a logged-in and unlocked machine unattended in the presence of another person, even a friend, is questionable. Use a screen locker!
Be very careful when typing a password in the presence of others, be them friends or strangers. The single worst cheating case I've ever handled started when the password of a hunt-and-peck typist was surreptitiously observed. Don't hesitate to ask someone, even a friend, to turn their head when you're typing your password.
For some interesting reading about password choice, see Unmasked: What 10 million passwords reveal about the people who choose them
Things like Google and Stack Overflow are incredible resources for working professionals but when used to directly search for solutions for problems on an academic assignment they can cause learning and/or creative opportunities to be forever lost.
My expectation is that the material presented in class, practice via exercises, suggested readings, resources cited, and any prior assignments will provide everything you need to do every problem on each assignment. I challenge you to limit your Googling to searches that expand your knowledge of the material, and not try to dig up quick solutions to problems. (And, of course, using any code found in such searches would be cheating.)
Posts on websites, IRC channels, mailing lists, etc. that solicit the answer for a problem or a significant piece thereof will be considered to be cheating. Example:
Malware, short for malicious software, is any software used to disrupt computer operation, gather sensitive information, or gain access to private computer systems.—Wikipedia
In various situations my TAs and I will be running your code. Do not be tempted to slip some malware into your code, even for "harmless fun". Introducing malware into a computer system is a federal crime—see http://fas.org/sgp/crs/misc/97-1025.pdf. I will request permanent expulsion from the university for any student who submits malware, and recommend that the university notify the FBI for possible further action.
You are free to use your laptops and phones during class but only for course-related work. Further, to avoid visual
distractions for classmates who can see your screen, display of graphics of any sort, including but not limited to
pictures, should be avoided unless a class-wide activity with such material is in progress.
Note-taking apps are permitted.
To foster a positive learning environment, students and instructors have a shared responsibility. We want a safe,
welcoming, and inclusive environment where all of us feel comfortable with each other and where we can challenge
ourselves to succeed. To that end, our focus is on the tasks at hand and not on extraneous activities (e.g., texting,
chatting, reading a newspaper, making phone calls, web surfing, etc.).
At the University of Arizona we strive to make learning experiences as accessible as possible. If you anticipate or
experience physical or academic barriers based on disability or pregnancy, you are welcome to let me know so that we
can discuss options. You are also encouraged to contact Disability Resources (520-621-3268) to explore reasonable
accommodation. Please be aware that the accessible table and chairs in this
room should remain available for students who find that standard classroom seating is not usable.
The University is committed to creating and maintaining an environment free of discrimination; see http://policy.arizona.edu/human-resources/nondiscrimination-and-anti-harassment-policy.
Here is a tentative schedule for the semester. The number of assignments and their scheduling is particularly subject to change.
FAQs and Corrections for Assignments
Email
372s18@cs. To ensure quality and accuracy, I want to see all mail between students and TAs. If you're replying to a TAs response to a question, use your mailer's "Reply All" to follow the Cc:'s.
Instant Messaging
Original Thoughts
Academic Integrity
Don't cheat in my class.
Don't make it possible for anybody else to cheat.
One strike and you're out!
Cheating almost always starts when one student has easy access to the solutions of another.
You are expected to take whatever steps are necessary to guard your solutions from others in the class. For example, you should have an unguessable, uncommon password and never share it. Hardcopy should not go into a recycling bin—take it home and dump it in a recycle bin when the course is over. Personal machines, be them laptops or home desktops, should be behind a hardware firewall or running a software firewall.
"I'm learning Haskell and trying to write a function that returns True iff the parentheses in a string are properly matched. Any suggestions?"
You might think that using a disposable email address, Tor, etc. will make it impossible to connect you with an improper question but I've caught some like-minded students.
Malware is a Federal Crime
Threatening Behavior Policy
The UA Threatening Behavior by Students Policy prohibits threats of physical harm to any member of the University community, including to oneself.
See
http://policy.arizona.edu/education-and-student-affairs/threatening-behavior-students.
Laptops, Phones, and Tablets
Department of Computer Science Code of Conduct
The Department of Computer Science is committed to providing and maintaining a supportive educational environment for all. We strive to be welcoming and inclusive, respect privacy and confidentiality, behave respectfully and courteously, and practice intellectual honesty. Disruptive behaviors (such as physical or emotional harassment, dismissive attitudes, and abuse of department resources) will not be tolerated. The complete Code of Conduct is available on our department web site. We expect that you will adhere to this code, as well as the UA Student Code of Conduct, while you are a member of this class.
Classroom Behavior Policy
Accessibility and Accommodations
UA Nondiscrimination and Anti-harassment Policy
Scheduled Topics/Activities
| Week # | Week of | Topics | Assignment Due / Exam |
|---|---|---|---|
| 1 | Jan 8 | Syllabus, basic questions about programming languages, UA's programming language heritage, the idea of a paradigm, programming paradigms, value/type/side-effect | Survey |
| 2 | Jan 15 |
The functional paradigm,
Haskell basics,
getting and running Haskell (ghci),
functions and function types,
type classes,
writing simple functions,
functions with multiple arguments,
partial application
| |
| 3 | Jan 22 |
Functions as values,
type inferencing,
type specifications,
guards
if-else,
a little recursion,
list basics, lists of lists, strings, cons lists, a little output, patterns
| Language questions |
| 4 | Jan 29 |
Patterns in functions,
patterns vs. guards vs. if-else,
recursive functions on lists,
tuples,
more on patterns and functions,
the where clause,
the layout rule,
larger examples
| |
| 5 | Feb 5 |
Errors,
debugging,
excursion into infinite lists and lazy evaluation,
higher-order functions,
map,
sections,
filtering,
composition,
point-free style,
anonymous functions
| Haskell #1 |
| 6 | Feb 12 |
Hocus pocus with higher-order functions,
syntactic sugar,
DIY currying,
flip/curry/uncurry et al.,
folding,
user-defined types,
a little I/O—sequencing and actions
| |
| 7 | Feb 19 |
Ruby introduction,
getting and running Ruby (ruby and irb),
everything is an object,
simple programs,
strings, numeric types, arrays,
static vs. dynamic typing
| Haskell #2 |
| 8 | Feb 26 |
"Why" vs. "Why not?" in language design,
while,
source code layout,
logical operators,
if-then-else and modifiers,
break and next,
for,
methods and scoping,
constants
| |
| 9 | Mar 5 | Spring Break | |
| 10 | Mar 12 |
Duck typing,
iterators and blocks,
writing iterators,
Hash,
Symbol,
introduction to regular expressions
| Ruby #1 |
| 11 | Mar 19 | Character classes, alternatives, grouping, quantifiers, anchors, named groups | Mid-term exam |
| 12 | Mar 26 |
Defining classes,
monkey patching,
eval,
class methods and variables,
attr_... methods,
operator overloading,
language mutability,
inheritance,
modules and mixins,
introduction to Prolog,
facts and queries
| Ruby #2 |
| 13 | Apr 2 | Getting and running SWI Prolog, atoms, numbers, predicates/terms/structures, more on queries, unification, query evaluation mechanics, rules, instantiation as "return", | |
| 14 | Apr 9 | Arithmetic, cut, can't prove, recursive predicates, lists | Ruby #3 |
| 15 | Apr 16 |
Built-ins for lists,
member,
append,
findall,
typing in Prolog
| Prolog #1 |
| 16 | Apr 23 | Low-level list processing, "univ", database manipulation, pit crossing puzzle | Prolog #2 |
| 17 | Apr 30 | Brick laying puzzle, the Zebra puzzle, Prolog conclusion, programming language humor, SNOBOL4 and Icon by observation | Prolog #3, video project |
Information contained in the course syllabus, other than the grade and attendance/absence policy, is subject to change with reasonable advance notice, as I deem appropriate.