Extending the Reader for a Specialized Language

Extending the Reader to process Spreadsheet Formulas

This is kind of a weird but fun experiment.  Today I altered the Awesome Sauce Java reader so an application can extend it to process symbols. The concept started as is a way to process Awesome Sauce Java forms entered into a spreadsheet cell:

(+ 1A 2A)

Note: I'm inverting the normal cell reference labels to follow row/col format. I'll probably change it, but I like the different order.

When I looked at the formula, I realized it needed to be processed either in a special reader, or in the actual reader.  The fun part about building a functional language that's modeled after Lisp is the recognition that every problem is associated with a part/component, or a function.  The structure of the language greatly simplifies the architecture.

As soon as I realized the spreadsheet had to convert a cell reference, like 1A, and convert it to the value held in cell 1A?  It became apparent the next problem was figuring out whether to write a bunch of new reader-like code, or find a way to process it at the existing reader.

The reader works and the spreadsheet formula would have to be passed to the reader at some point anyway.  I'll write more about how the reader's been designed, because it's got a lot of flexibility built in.

I decided it wouldn't hurt anything to add a hook to the reader for an application that is going to pass a form to the reader anyway.  Even if it was just to see if the application, in this case the spreadsheet, can leverage the reader while the reader can accommodate the spreadsheet.  First tests show that it works well.

All it took was adding a hook, a few functions, passing a little data, and it's just like parsing any other type.  Now the spreadsheet can install cell reference parsing code, pass (+ 1A 2A) to the reader, and the reader will check the tokens against all the normal parts along with looking for cell references.  When any cell reference is encountered, it's processed by the spreadsheet, so it can save the details associated with the formula, along with the external cell references, so edits to a cell feeding the equation will cause the formula to update.  Plus the actual value in the cell can be substituted for the cell reference in the equation, which is just like what the reader does anyway.

I don't know how many other applications will need to do this type of processing, but having one app usually means there will be others.  For now, it's enough to know the reader has been extended so applications that need to process special symbols or tokens can simply write a couple of functions; one to validate the type, and another to process it.

As experiments go, this has been fun.  Because I didn't expect to write a spreadsheet.  And I didn't expect to start writing a spreadsheet by making formulas work first.  Now I get to figure out how to leverage a spreadsheet model with Java and Lisp available to do...whatever I want with it.  I hope you'll consider contributing to my crowd funding campaign for Awesome Sauce Java on Indiegogo.  Because if I had 3 months with this language and no distractions I think it'd be possible to build a lot of very dynamic tools and methods to edit/change/evolve software that you can use to create your own fun.