> I just found that in exercise 5, there was a typo in the example program:
> 
> let x = 3 in { print x; ... } ...
> 
> Should be:
> 
> {let x = 3 in print x; ... }

The program typed out in the middle of exercise five uses indentation to
resolve how the ";" operator binds (hence the bit about the curly braces
being syntactic sugar). If you wanted to pass it to the interpreter you are
building, you would use something like:

  x := 1 ;
  y := 2 ;
  { let x = 3 in
    print x ;
    print y ;
    x := 4 ;
    y := 5
  } ;
  print x ;
  print y
  // "3 2 1 5"

... just to be safe. It's not a typo per-se, but I'll update it so that it
is clearer. Good spotting.

        - Wes

---

> So, I just spent a while unsuccessfully trying to prove that if A is a
> single function mapping X to P(Y), then there is a bijection from
> A to P(X \times Y).

Sorry about that.

> I had actually typed out a disproof of this and was about to email it to
> you, but then I looked at the book's version of the problem and realized
> that I probably misread what you meant.

I added the names to the sets so that people would use them when solving
the problem rather than inventing their own -- that should (I hope) make it
easier for me to grade solutions rapidly. Unfortunately, I appears that I
have caused extra confusion.

> Am I correct in assuming that you actually want us to produce a bijection
> between "the set of all sets A:X->P(Y)" and "the set B" instead?

A is a set of functions. Each element a in A is a particular function from
X to P(Y).

B is a (or can be viewed as a) set of relations. Each element b in B is a
subset of X*Y. That is, each element in b is a set of pairs (x,y) with x in
X and y in Y.

Your mission, should you choose to accept it, is to give me a bijection
that will take any 'a' and yield a unique 'b' (etc.). You might do this by,
for example, constructing a function f that maps B to A and then proving
that it is an injection and a surjection.

        - Wes

---

> I checked the lexer and parser but didn't see any code processing
> indentations..

Right. Your correction is required before the example code can be typed in
and fed to the interpreter.

> Do you mean you used indentation just for the "imaginary" interpreter, or
> the toy interpreter we're using now?

Ignore the bit about indentation. I have updated the problem on the
webpage. Your version is clearer all around.

I don't want you to waste any time worrying about concrete syntax in the
course if you don't want to.

> By the way, I heard that Haskell relies on indentation to work.

I haven't heard anything about that.

However, you may be refering to Python or FORTRAN. See, for example:

http://en.wikipedia.org/wiki/Python_programming_language#Indentation

Since I'm pretty sure Haskell doesn't care about indentation, I'll answer
your question about Python.

> What's your opinion on this decision?

It is my personal opinion that I wouldn't choose such a feature in a
general-purpose programming language -- I use different editors (e.g., vi,
emacs) and pretty-printers (e.g., indent), and I would have to pick
Python-supporting tools if I programmed in Python (to avoid indenting
errors).

That said, programming languages and scripting languages are not designed
to appeal to PL professors (well, sadly, they often are, but that's another
story) -- the visual appeal of indenting is undeniable to new programmers.
"All whitespace is equivalent" is actually a fairly complicated concept. On
the other hand, I've never actually seen anyone (even a beginner) make the
"if with no curly braces" mistake that is often mentioned at this point.

As a PL professor, I would like it to be easy to writer parsers and
pretty-printers for languages. That would argue against required indents.
On the other hand, I'm writing those parsers and pretty-printers to do
program analyses and transformations in order to understand programs and
improve software quality. If the forced-indentation prevents bugs and
yields more reliable software, more power to it! I have not seen any hard
numbers that argue one way or another (e.g., vaguely controlled experiments
in which two otherwise-equal beginner classes are taught Normal-Python and
Whitespace-Doesn't-Matter-Python and then somehow evaluated later).

> What's the background of this decision?

Guido, the Python guy, worked on ABC (another language with forced
indentation) before making Python:

http://en.wikipedia.org/wiki/ABC_programming_language

        - Wes

---

> 1) wanted to letcha know there is a slight mistake in the readme.txt for
> the hw1 assn in step 6 you have the code { if x < 9 then { x := x - (5 -
> 3) } else print x } ; but this won't parse as we use <= and not <...not a
> biggie

Fixed, thanks. 

        - Wes

---

> [ Do I have to do anything for this question, or is it ] already
> contained in [ the ] code?

> > Extend the set of redexes and contexts for the contextual-style
> > operational semantics that we discussed in class to account for the let
> > command.

My apologies, I guess the question was not clear. The intent was for you to
write out new contexts (e.g., H ::= ...) and redexes (e.g., r ::= ...) for
let. Yes, that information is implicit in your interpreter (which must know
which parts of 'let' to evaluate in what order), but the question was to
make sure that you understood the formalism. You should write out something
formal (just a few glyphs, actually). 

        - Wes