Mike Schaeffer's Blog

Articles with tag: lisp
August 24, 2005

I literally dreamed about this last night. It would be wonderful if Excel supported formulas like this:

=LET(value=MATCH(item,range,0), IF(ISERROR(value), 0, value))

If you're into Lisp-y languages, it'd look like this:

(let ((value (match item range 0)))
  (if (is-error? value) 0 value))

The function call =LET(name=binding, expression) would create a local range name named name, bound (equal) to the value returned by binding, to be used during the evaluation of expression. In the example above, during the evaluation of IF(ISERROR(value), 0, value))<, value would be bound to the value returned by MATCH(item, range, 0).

It's worth pointing out that this is slightly different from how normal Excel range names work. Range names in Excel work through textual substitution. With textual substitution, the initial expression would be logically equivalent to this:

=IF(ISERROR(MATCH(item, range, 0)), 0, MATCH(item, range, 0)))

In other words, Excel would treat every instance of value as if MATCH(item, range, 0) was explictly spelled out. This means there are two calls to MATCH and two potential searches through the range. While it's possible that Excel optimizes the second search away, I'm not sure that anybody outside of Microsoft can know for sure how this is handled.

Microsoft's current reccomendation for handling the specific ISERROR scenario in the first expression is this VBA function:

Function IfError(formula As Variant, show As String)

    On Error GoTo ErrorHandler

    If IsError(formula) Then
        IfError = show
        IfError = formula
    End If

    Exit Function

    Resume Next

End Function

This isn't bad, but it requires that spreadsheet authors and readers understand VBA. It also imposes significant performance costs: calling into VBA from a worksheet takes time.

August 8, 2005

Paul Graham solicited comments on his Arc programming language a few years ago. These comments are online, and are very interesting reading. Lots of good comments.

June 30, 2005

I've been playing around with how to map XML to S-Expressions nFor a while, I had been considering a mapping like the following:

From:<phonebook name="Jenny">867-5309</phonebook>
To:(phone_book ((name . "Jenny")) "867-5309")

In other words, a symbol for the tag name in the car of the list, an association list of attribute values in the cadr, and then the subelements in the cddr. This seems reasonable, aside from the fact that attributes and tag values are still wierdly disjoint.

On the way to lunch today, I came up with another mapping that might be more reasonable:

From:<phonebook name="Jenny">867-5309</phonebook>
To:(phone_book (name "Jenny") :end-of-attribute-marker "867-5309")

This is simpler in that a tag is modeled as a list containing the tag symbol and then all of the sub-items, attributes or not. Data stored as an attribute doesn't get special treatment relative to data stored as a tag value. The symbol :end-of-attribute-marker makes it possible to still distinguish between attributes and tags. If you don't care, a simple call to remove can remove the marker symbol.

It's a subtle design point, but this'll probably end up in vCalc in the XML support... I've had XML for vCalc on the back-burner for a while now, but due to some real work obligations, I might have to make it a higher priority.

March 2, 2005

I'm in the middle of developing a Scheme compiler for a future release of vCalc. While I've been developing the code, I've peppered it full of debugging print statements that look something like this:

(format #t "compiling ~l, tail?=~l, value?=~l" form tail? value?)

with the output statements in place, the compiler takes about 250-300ms to compile relatively small functions. Not great, particularly considering that there's no optimization being done at all. Anyway, on a hunch I removed the format statements, and execution time improved by a couple orders of magnitude to a millisecond or two per function. That's a lot closer to what I was hoping for at this stage of development.

On the other hand, I hadn't realized that my (ad hoc, slapped together in an hour) format function was running quite that slowly. I think it'll end up being an interesting optimnization problem sooner or later.

February 8, 2005

vCalc is the other side project I have going on right now. It's a simple RPN style calculator written for Win32. Underlying vCalc is a Scheme interpreter that I talk about a little here. The ultimate goal for vCalc is to have a calculator that can be easily extended with Scheme functions, in addition to the keystroke sequences you might expect. As it turns out, there are a lot of interesting problems that crop up trying to make this work right. I hope to blog more on this in the future.

Like Noisemaker, vCalc is shareware available through IceGiant.

February 8, 2005

One interest of mine is programming languages, and more specifically, Lisp and Scheme. Lately, the blogosphere has produced a couple interesting blogs that tie to this interest:

  • Lambda the Ultimate
  • Planet Lisp

    Planet Lisp aggregates a bunch of Lisp-related blogs, while LtU is more general and more of a discussion site.

    Related, I came to LtU via Eric Lippert's Blog over on Weblogs @ASP.Net. Eric is a developer at Microsoft who's done a lot of work on Windows scripting and the Windows script languages.