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.
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.
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.
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.
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.