Lambda the Ultimate

I've been working on a library to wrap WPF dependency properties with signals so that data binding is easier to do in WPF when using C#:

http://www.codeplex.com/wpfsignals.

Dependency properties by themselves are like signals (time-varying values) but don't support direct transformation (i.e., map) or composition like signals do. Instead, you have to define verbose value converters and jump through a lot of hoops. To solve this problem, the WPF signal library creates a signal-like wrapper around dependency properties so they can support direct transformation and composition; e.g., we can directly express relationships like:

rectangle().top().bind = canvas.height() - rectangle.height()

meaning that the rectangle is stuck to the bottom of the canvas, even as the size of the canvas or rectangle changes.

This is currently a source code release only. SignalLib is a Visual Studio 2008 .NET 3.5 project, and an example application (in the SignalExample project) is provided to help introduce the library. Feedback is appreciated.

An ancient paper (July 1978: 30 years ago) from the long gone Lisp Bulletin by Harald Wertz.

The system describes attempts to improve incompletely specified Lisp programs, without however resorting to more information, in the form of specifications, test cases or the like.

A second paper on the system is Stereotyped Program Debugging: an Aid for Novice Programmers.

This question has been bugging me for a while: whats the standard practice of handling comments during parsing? Ignore them or annotate the parsetree? My first thought is to simply let the lexer discard comments. But if the goal is to reproduce the source of the program via a pretty printer or some such, the comments need to come a long for the ride?

What leads me to this line of inquiry is: If I'm a client purchasing a parser should I expect my $20,000 C++ parser (for example, I've read C++ parsers are expensive) to preserve comments?