So, here are some questions which I figure will be frequently asked
once I release this code. I'm going to try to answer them before they
become asked.


1.  Why did you implement RPN instead of the more familiar notation
used by other companies?

Well, I prefer RPN. I always goof up on the other kind of calculator,
losing my intermediate results. RPN is faster and more efficient when
you're used to it. Also, it's easier to program, as the parser doesn't
have to be very robust.


2.  Why isn't there an X interface?

There may be one later.


3.  Why did you write this in C++?

I wrote this code as a learning project for C++. Armed with two
excellent online documents, Frank Brokken and Karel Kubat's "C++
annotations", and Peter Muller's "Introduction to Object-Oriented
Programming using C++", and a C++ compiler, I endeavoured to learn the
language and write something useful. This is the result of that first
attempt. I apologize to any more experienced C++ programmers if the
source code offends them, but this is my first C++ program, and my
first object-oriented effort.


4.  Will you provide a complex data type in the future? Built-in
hyperbolic functions?

Perhaps. Probably.


5.  What about an explicit matrix type?

Less likely, but possible.


6.  What's with the source code? Why are some pure methods defined but
then the subclasses used explicitly?

This is a future expansion issue. Those pure methods represent
generalizations which I may implement at a future time.


7.  What's that "dummy()" function for in main.cc?

Wish I knew. When I take it out the code won't link, the virtual
tables for the stack and memory are not properly completed. This seems
to be because of the fact that those template classes are otherwise
only used to define global variables.


8.  Don't you know that C++ includes hash and stack classes in the
standard includes?

Yes, I know, but I found them painful to use in this context, where I
wanted the classes to have significantly more functionality. I started
out subclassing from the standard classes, and finally decided it was
cleaner to write my own from scratch. And don't get me started on
'genclass', I had all these big nasty filenames sitting around my
source directory, and I wasn't sure that the resulting code would be
portable to non-GNU C++ compilers.


9.  Can you get the mouse to work on the Linux text console?

No. Rather, that's something for ncurses developers. When ncurses
supports it, the calculator will too, without modification to the
source code.


10. Can you get the parser to accept the more traditional input? I
want to be able to type "sin (3 + 4)" and get an answer.

Maybe, some day. What this would be, though, would be a re-parser, to
accept input in that form and then pass it through to the calculator
internals in the form "3 <ENTER> 4 + sin". There would still be a
visible stack, and the calculator would still "believe" itself to be
an RPN calculator.


11. Can the calculator be used in a pipeline?

Not yet, but that would be a useful addition. If I do it, what output
strategy would seem most useful to people?
A) the X-value is output after each operation
B) the X-value is output only once, after the input runs out
C) the X-value is output when a particular keyword is delivered


12. I like the programmability, but I'm worried about name collisions
when I load more than one subroutine into memory at one time. Can you
set up a system of reduced name scoping and local variables?

If enough people express an interest, I might do this. I have a syntax
and method in mind (basically, memory labels and branch targets would
have a scoping operator, '::'). If I suspect that I am the target of a
world-wide conspiracy to get me to write a Forth compiler, then I will
become annoyed.
