TITLE: Fall Semester Seems Far Away Right Now
AUTHOR: Eugene Wallingford
DATE: June 10, 2008  4:09 PM
DESC: 
-----
BODY:
I'm not yet thinking about my Programming Languages course
this fall, but I wish I were.  The first temptation came
via my newsreader and Martin Fowler's recent piece
<A HREF="http://martinfowler.com/bliki/ParserFear.html">
   ParserFear</A>.
Martin is writing a book on domain-specific languages
and blogging occasionally on his ideas.  This article
is about just what the title says, programmers' often
irrational fears of rolling a parser, which deter them
from implementing their own DSLs.  He speculates:

<BLOCKQUOTE><EM>
So why is there an unreasonable fear of writing parsers
for DSLs? I think it boils down to two main reasons.

<UL>
<LI> You didn't do the compiler class at university and
     therefore think parsers are scary.  </LI>
<LI> You <STRONG>did</STRONG> do the compiler class at
     university and are therefore convinced that parsers
     are scary.  </LI>
</UL>

The first is easy to understand, people are naturally
nervous of things they don't know about.  The second reason
is the one that's interesting.  What this boils down to is
how people come across parsing in universities.
</EM></BLOCKQUOTE>

CS students tend to learn about parsing for the first time
in a compiler class, working on a large language with a
full range of constructs.  Parsing such languages is hard.
In a few compiler courses, including my own, students still
learn to build a parser by hand and so don't even have the
chance to use parser generators as a labor- and pain-saving
device.  That's okay in a compiler course, which students
take in large part to learn how their tools really work.

Martin doesn't suggest that we change the compiler course,
and I don't either (though I'm
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2008-01.html#e2008-01-07T19_07_12.htm">
   open to possibilities</A>).
He does seem to think it's a shame that students are turned
off to parsing and language design by first, and perhaps
only, seeing them at their most complex.  I agree and think
that we should do more to introduce these ideas to students
earlier.

I introduce students to the idea of parsing in my Programming
Languages course, and ask students to write a few very small
parsers to handle simple languages.  I've been thinking for
a while that I should do more in this area, and reading
Martin's article has me itching to redesign the latter part
of my course to allow more work with parsing and parsers.
Another possibility is to use parsing as the content of some
of our early programming exercises, when students are
nominally learning to program in a functional style.  Students
can certainly apply the programming techniques they are
learning to translate simple data formats into more abstract
forms.  This might help them to begin to see that parsing is
an idea broader than just general-purpose programming languages.
It might ease their transition a couple of weeks later to
the idea of syntax-as-data structure and allow us to do some
simple work with DSLs.

I have tried the idea of parsing at its simplest with relative
novices as early as CS 1.  When I taught a
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-11.html#e2006-11-17T16_36_41.htm">
   media computation CS1</A>,
one of the last programming assignments was to write a program
to read a file of simple graphics commands and produce the
desired graphical image.  The idea was to bypass Java's
verbose syntax for doing simple AWT/Swing graphics and allow
non-programmers (artists) to make images.  I asked students
to implement a couple of simple commands, such as "draw line",
and create at least one command of their own.  I expected all
of their graphics languages to be "straight-line", with no
control or data structures, but that didn't mean that the
resulting DSLs were not useful.  They were just simple.  A
couple of students did really interesting work, creating
very high-level commands for swirls and splashes.  These
students wrote methods to interpret those command using
control and data structures that their "programmers" didn't
have to know about.

Any change to my Programming Languages needs to be
"footprint-neutral", to use
<A HREF="http://notes-from-a-sticky-wicket.blogspot.com/2008/06/footprint-neutral-curricular-change.html">
   Shriram Krishnamurthi's phrase</A>.
Anything I add has to fit in my fifteen-week course and
either displace existing material or work in parallel.
Shriram used this phrase in the broader context of
rejiggering the teaching of
<A HREF="http://www.sigcse.org/cc2001/PL.html">
   teaching of programming languages</A>
within the core ACM curriculum, which a recent
SIGPLAN-sponsored workshop tried to do.  After having just
read Martin's article on parsing, I was eager to refresh
my memory on where parsing fits into the core curriculum
proposal.  Parsing falls under knowledge unit PL3, Language
Translation, which has two hours allotted to it in the
core.  (An optional knowledge unit on Language Translation
Systems includes more.)  Interestingly, the working group
Shriram reports on recommends cutting those two hours to
<EM>zero</EM>, on the grounds that the current coverage
is too superficial, and using those hours to build up a
10-hour unit on Functional Programming.  That's a worthy
goal, though I haven't hard a chance to think deeply about
the proposal yet.

Working with constrained resources sometimes requires
making tough choices.  I know that Shriram and the people
with whom he worked think that parsing is a worthwhile
topic for CS students to know, so perhaps they have in
mind something like what I suggested above: piggybacking
some coverage of parsing on top of the coverage of
functional programming.  In any case, I think I'll work
on finding more ways for my Programming Languages students
to engage parsing and domain-specific languages.
-----