2010-01-12
- Introduction to Programming Languages (CS4400/CS5400)
- Introduction to (PLT) Scheme

========================================================================
>>> Introduction to Programming Languages (CS4400/CS5400)

* General plan for how the course will go.

* Administrative stuff.  (Most of the stuff from the web page.)
  >>> http://pl.barzilay.org/ <<<

* Why should we care about programming languages?  (Any examples of big
  projects *without* a little language?)

========================================================================

* What defines a language?
  - syntax
  - semantics
  - libraries
  - idioms

* How important is each of these?

  - libraries give you the run-time support, not an important part of
    the language itself.  (BTW, the line between "a library" and "part
    of the language" is less obvious than it seems.)

  - idioms originate from both language design and culture.  They are
    often misleading.  For example, JavaScript programmers will often
    write:

      if (isExplorer)
        document.onmousemove = explorer_move;
      else
        document.onmousemove = mozilla_move;

    or

      if (isExplorer)
        document.onmousemove = function () { ... };
      else
        document.onmousemove = function () { ... };

    or

      document.onmousemove =
        isExplorer ? function () { ... }
                   : function () { ... };

    How many JavaScript programmers will know what this does:

      function foo(n) {
        return function(m) { return m+n; };
      }

  - Compare: a[25]+5                   (Java: exception)
             (+ (vector-ref a 25) 5)   (Scheme: exception)
             a[25]+5                   (JavaScript: NaN or undefined)
             a[25]+5                   (Python: exception)
             $a[25]+5                  (Perl: 5)
             a[25]+5                   (C: <<<BOOM>>>)
             a[25]+5                   (ML: not an array ref at all)
    -> syntax is mostly in the cosmetics department.
    -> semantics is the real thing.

* How should we talk about semantics?

  - A few well-known formalisms for semantics.

  - We will use programs to explain semantics: the best explanation *is*
    a program.

  - We will use Scheme for many reasons (syntax, functional, simple,
    formal, statically typed, environment).

  - Ignore possible philosophical issues with circularity (but be aware
    of them).  (Actually, they are solved: Scheme has a formal
    explanation that can be taken as a translation from Scheme to logic,
    which means that things that we write can be translated to logic).

========================================================================
>>> Introduction to (PLT) Scheme

* General diagram of the parts of PLT Scheme:

  - MzScheme: a Scheme implementation (an extension of "the standard"
    scheme, for any value of "standard");

  - MrEd: an extension to MzScheme that uses wxWindows for a
    portable GUI environment, written in both C and Scheme;

  - DrScheme: a MrEd application (written completely in Scheme);

  - Our language(s)...

* Documentation: the PLT documentation is your friend (But beware that
  some things are provided in different forms from different places)

========================================================================

Side-note:

E.W. DIJKSTRA

"Goto Statement Considered Harmful."

This paper tries to convince us that the well-known goto statement
should be eliminated from our programming languages or, at least (since
I don't think that it will ever be eliminated), that programmers should
not use it.  It is not clear what should replace it.  The paper doesn't
explain to us what would be the use of the "if" statement without a
"goto" to redirect the flow of execution: Should all our postconditions
consist of a single statement, or should we only use the arithmetic
"if," which doesn't contain the offensive "goto"?

And how will one deal with the case in which, having reached the end of
an alternative, the program needs to continue the execution somewhere
else?

The author is a proponent of the so-called "structured programming"
style, in which, if I get it right, gotos are replaced by indentation.
Structured programming is a nice academic exercise, which works well for
small examples, but I doubt that any real-world program will ever be
written in such a style.  More than 10 years of industrial experience
with Fortran have proved conclusively to everybody concerned that, in
the real world, the goto is useful and necessary: its presence might
cause some inconveniences in debugging, but it is a de facto standard
and we must live with it.  It will take more than the academic
elucubrations of a purist to remove it from our languages.

Publishing this would waste valuable paper: Should it be published, I am
as sure it will go uncited and unnoticed as I am confident that, 30
years from now, the goto will still be alive and well and used as widely
as it is today.

Confidential comments to the editor: The author should withdraw the
paper and submit it someplace where it will not be peer reviewed.  A
letter to the editor would be a perfect choice: Nobody will notice it
there!

========================================================================