this week in comp.lang.lisp

• Paolo Amoroso pointed out a great resource in <877iyp350t.fsf@plato.moon.paoloamoroso.it>:

  For MOP nirvana and enlightenment, see:
  
    Open Implementations and Metaobject Protocols
    by Gregor Kiczales and Andreas Paepcke
    http://www.parc.com/csl/groups/sda/publications/papers/Kiczales-TUT95/for-web.pdf
  
  If I had to pick a subtitle, I would say "MOPs demystified".  Print
  the document and read it on your favorite chair in a quiet room.
  

  From the "Introduction" section of the referenced PDF:

  The work presented in this book is based on the observation that much of the complexity in current application programs comes from the application programmer having to 'code around' deficiencies in the underlying operating system, programming language, object system or other substrate software. This happens when the application programmer would like a specific feature or behavior that the substrate does not provide.

  But this book does not propose that substrate software should just "have more features to please more programmers." Instead, it suggests that substrates should be open in a way that allows programmers access to and control over the substrate's implementation in a way that allows the programmer to tailor the substrate to the needs of a particular application. This is called open implementation.

  Looks good.

• Much of the time on comp.lang.lisp, novices react to criticism with defensiveness and hostility, and treat any questioning of their behavior as a personal attack. That's why it was refreshing to see <1161788613.364200.98730@e3g2000cwe.googlegroups.com>:

  > I saw your explanation to other noobs. Made no sense to me. Instead of
  > searching for a pithy way of synopsizing what is going, it actually
  > would be easier simply to learn what is going on. In full. The shortcut
  > thinking of your synopsis is too lossy, and macro-writing requires
  > precise understanding of what is going on.
  
  You remind me of my early experiences learning French. It was often the
  case that students who thought they were speaking French could easily
  understand eachother while the francophones around them found them
  difficult to understand. This was caused by the students having access
  to English grammar and phonetics when interpreting the "French"
  utterances. For example, beginners have no trouble with, "le brun
  chaisses" even though the gender of the article is wrong, the adjective
  is in the wrong place, and so on.
  
  All that to say, I'm sorry that it seems I still have not entirely
  figured out defmacro's treatment of arguments. I thought I had, and I
  thought I was putting it in terms other newbies could understand.
  Thanks for pointing out that I'm still missing something.
  

• Robert Strandh gave the best summary I've yet seen of CLIM in <6wodrywdsw.fsf@serveur5.labri.fr>:

  CLIM has a "command loop" that is at a higher level than an event loop
  and that:
  
    * acquires a command.  You might satisfy this demand by clicking on
      a menu item, by typing the name of a command, by hitting some kind
      of keystroke, by pressing a button, or by pressing some visible
      object with a command associated with it ;
  
    * acquires the arguments required by that command.  These arguments
      are often associated with a "presentation type", and visible
      objects of the right presentation type can be clicked on to
      satisfy this demand.  You can also type a textual representation
      of the argument, using completion, or you can use a context menu ;
  
    * calls the command on its arguments, usually resulting in some
      significant modification of the "model", i.e. the data structure
      representing your application logic ;
  
    * calls a redisplay routine (which might use incremental redisplay)
      to update your views of the model.
  
  Writing a CLIM application therefore consists of:
  
    * writing CLIM commands that modify the model independently of how
      those commands are invoked, and which may take application objects
      as arguments ;
  
    * writing display routines that turns the model (and possibly some
      "view" object) into a collection of visible representations
      (having presentation types) of application objects ;
  
    * writing completion routines that allows you to type in application
      objects (of a certain presentation type) using completions ;
  
    * independently deciding how commands are to be invoked (menus,
      buttons, presentations, textual commands, etc). 
  
  By using CLIM as a mediator of command invocation and argument
  acquisition, you can obtain some very modular code indeed. 
  

Keep digging for the ponies!