... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)


Extracting Mathematica Notebook Content

The following Mathematica expression will extract all non-input cells from a notebook and create a new notebook that contains only those cells:

  Cases[NotebookGet@EvaluationNotebook[],Cell[_,Except["Input"],___],Infinity] ]

Iterating Through Mathematica Notebook Cells

The following snippet will iterate through the all the cells in a Mathematica notebook and close all Input cells:

Module[{nb, cell},
 nb = Notebooks["mynotebook.nb"][[1]];
 SelectionMove[nb, Before, Notebook];
 While[SelectionMove[nb, Next, Cell]; cell=NotebookRead[nb]; {}=!=cell,
  If["Input" == cell[[2]], 
   SetOptions[NotebookSelection[nb], "CellOpen" -> True] ]


Scala and Haskell Combinators

In Scala, I find the syntax used in for comprehensions a bit confusing.  Specifically, the use of the keyword for.  Clearly, this is a concession to simulating looping constructs from other languages, particularly looping over collections.  The fact that for constructs compile to map, flatMap, filter and foreach reinforces this view.  However, the facility is more general.  Consider the use of for comprehensions in the Parser library.  The code style looks more like a Haskell do block.  It relies on the fact that the parser combinators return "collections" that are either empty or contain one element.  Thus, the "loops" are really a chain of expressions, the chain being broken by the first parse failure.  This is analogous to looking at an SQL inner join and realizing that the cardinality of all of the relations involved in the join have cardinality zero-or-one.

Haskell's do seems to suffer from a similar problem.  The construct is intended to be used with the celebrated Monad type.  But the word do suggests simple sequencing -- not general combinators.  It doesn't help that the monadic unit operation is named return.  No wonder people get confused by monads.

In both Scala and Haskell, I think that the mixed metaphors cause grief.  At least in my case, the supposedly helpful choices of keywords made it harder to understand the deeper truth.  In both cases, perhaps it would have been better to have two levels of abstraction: an upper level that uses only friendly keywords like for, do and return, and a lower level that only uses monadic or combinator terms.  Keep the two worlds separate.

Why Java Makes Me Stupid

My recent work in Mathematica has re-awakened some of my LISP sensibilities -- intuitions that I lost while working in Java.  What is it about Java that makes me forget about symbolic programming?  Well, I suppose it would be nice if Java had:

  • a symbol type
  • a "data" syntax
  • lightweight lists
  • less verbose collection syntax (e.g. for operations like fold/reduce)

The list could grow longer, of course.  Where are higher-order functions or even simple lambdas?

Having said all that, it is not impossible to do symbolic programming in Java.  It is just unpleasant (contrast the LISP and Java LabEngines, for example).  Also, the whole Java culture is "do this, then this, then this...", not "compose this and this and this".  Java makes the function call a significant event.  Not as significant as it was in the Fortran days, to be sure, but still way more significant than in LISP or Smalltalk or Mathematica or Haskell or Scala or ...


Scala XML Book

The official Scala documentation for the XML facilities are poorly documented (just like everything else in the Scala library).  However, the Scala XML Book fills in some of the blanks.


Ceteva's XMF is a container language that glues together code fragments written in many different languages, in a style reminiscent of C ASM blocks.  It is hard to pin down the target application of XMF.  The core language contains more than glue.  "Undo" is a native concept, and there appears to be a sizable core library.  The documentation emphasizes language-oriented programming and meta-modelling.  Many language constructs are available to define DSLs.

Blog Archive