Re: Seeking computer-programming job (Sunnyvale, CA)

"eric-and-jane-smith" <noreply@nospam.com> writes:


Yes, a good point.

I've lately decided that I really like the example of WITH-OPEN-FILE as
an example of a nice Lisp macro. OK, it's already in the language, but
the important point is that it would be something easy to add if it
WASN'T in the language. This exposition can proceed by looking at the
problem it was put in to solve, and comparing it to two Java solutions.

Problem: When you open a file, you have to remember to close it, even if
         the code using the file happens to throw an exception.

OK. The standard Java solution would be to use "try ... finally":

    OutputStream out = null; // Needs definition outside try block.
    try {
       out = new FileOutputStream(filename);
       // do stuff
    } finally {
       if (out != null) {
         try {
            out.close();
         } catch (IOException ioe) {
            // Do something like log this.
         }
      }
    }

So, this is just a bit cumbersome, because you have to remember to
declare the variables in the correct place, remember to put in the
finally block, with appropriate safety checks. Note that because the
close() method can also throw an exception, you have to wrap it in its
own exception handling block. That's a lot of infrastructure that you
need to write around the file handling code that you really care about,
namely the "// do stuff" part.

Note in particular, that STATIC TYPING DOES NOTHING to enforce this type
of good programming practice. That's because it isn't a type error, but
an oversight in program strucure. Macros, on the other hand, allow you
to easily capture such good practice.

[Aside: There has of late been a lot of "excitement" about pattern-based
design. This is all well and good, but it is something that,
essentially, Common Lisp has had all along through the judicious use of
macros. In fact, lisp has gone beyond the notion of mere patterns and
instead calls this aspect the process of building a Domain Specific
Language (DSL)]

Now, you can, in fact, write the same thing in Common Lisp, yielding a
program that looks kind of like this:

   (let ((out nil))
     (unwind-protect
       (progn
          (setq out (open filename :direction :output))
           ;; Do stuff
          )
       (unless (null out)
         (close out))))

where we set up the same basic structure. Now, since we nearly always
want to do something like this when we open the file, we would like to
have a safe way to do this that is convenient and gets the details
right. So we take the basic outline of what we want and write a macro
that embodies this particular idiom:

 (defmacro with-open-file ((var filename &rest open-options) &body body)
   `(let ((,var nil))
      (unwind-protect
        (progn
          (setq ,var (open ,filename ,@open-options))
          ,@body)
        (unless (null ,var)
           (close ,var)))))

So now we have a macro that automatically handles the task of opening a
file and remembering to close it. That simplifies our code to the more
perspicacious and correct, because the macro has been carefully
constructed:

  (with-open-file (out filename :direction :output)
     ;; do-stuff
    )

This also allows us to concentrate our attention on the actual DO-STUFF
part, which is the variable part of this endeavor and the place where
logic bugs can occur. We don't have to bother ourselves looking at all
of the boilerplate and making sure we got it right, since we've already
gotten the boilerplate parts correct in our macro.

So, how would one go about doing something similar in Java. The real
crux of the matter is that there isn't any facility in the language that
allows you to introduce a new control structure that allows you to
insert your actual program into the middle of some combination of
existing constructs.

As near as I can tell, the method one would need to use involves
encapsulating the program you want to execute inside a (possibly
anonymous) class with a defined "run" interface so that it can be
executed. That would involve something along the lines of

public interface FileProcessor {
   public void processFile (OutputStream out);
}

public class ProcessFile {
  public static void processOpenFile (String filename, FileProcessor worker) {
    OutputStream out = null;
    try {
       out = new FileOutputStream(filename);
       worker.processFile(out);
    } finally {
       if (out != null) {
         try {
            out.close();
         } catch (IOException ioe) {
            ioe.printStackTrace();
         }
      }
    }
  }
}

OK. With this infrastructure defined, we can now write code that looks
sort of like this:

ProcessFile.processOpenFile(filename,
                            new FileProcessor () {
                              public void processFile(OutputStream out) {
                                // do stuff
                              }
                             });

where we create a new anonymous class instance to encapsulate the body
of the code that we want to execute.

So, it is possible to build up such abstractions in Java, but to my eyes
that looks a lot clunkier and less integrated than the Lisp macro
solution. You see, there isn't any way of introducing new forms into
Java that look like the language itself. So there isn't any way to add
your own control structure construct that looks like

 with_open_file (out, filename) {
    // do stuff
  }

which would be the real equivalent of the Common Lisp macro solution.

So this is a very simple example of what is meant when lisp programmers
talk about using macros to write code that is correct, and a very
simplistic example of how we go about writing DSLs to solve problems, by
removing the superstructure required by the programming language from
sight so we can concentrate on getting the actual business logic right.

--
Thomas A. Russ, USC/Information Sciences Institute