Major stuff:

Note that I'm currently allowing you to dim with Expressions!
(This actually isn't so bad, as long as expressions use constants.
Variables are all zero, though.)

Expression TODO:
- add/mult to "exp" in Arith/Mult. (in 1.20)
- classes inherit from LBE::String/Numeric (in 1.20)
- parse blesses. new returns $obj=$class->parse($self) (in 1.20)
- If arith. has only one mult. exp., return the ME (in 1.20)
- LogicalAnd/LogicalOr exps (easy).
- LBE::Boolean class that LogicalAnd/LogicalOr inherit from. Be careful with
  string_or_numeric stuff! Actually, Arith/Mult will automatically return
  Booleans rather than blessing them to A/M so that should be safe. But
  what about other things that call string_or_numeric? E.g., INT((A>B)).
  ("int(A>B)" would be an error since Arglist looks for arith. exps. But
  extra parens would make Unary call Cond.) Should Boolean be an error?
- Or do we want to get rid of String/Numeric & just move to "type" field?
  Kind of nice to be able to say new LBE::Foo::Numeric. OTOH, I don't think
  we're really doing testing right now! E.g., if you look for an
  LBE::Arithmetic::Numeric, is there any check for that? We may be able
  to do type checking by examining the class name & testing for 
  isa String, Numeric or Boolean.
- Add NOT to rel op
- add "is_nested" to Unary if parens. (in stuff/Exp_Try). But note that if an Or
  is in a Unary, we should return the Or so that Rel. Exp. sees it.
  (Alternatively, Rel. Exp. could test for Unary's "expression" field. (We
  know we won't have to delve into subexps to find out if it's boolean.) 
  Or just have a Unary::Boolean class!
- Unary calls LogicalAnd with "maybe_arithmetic". Which passes it down to
  Relational. if Relational is called with "maybe", then if there's no
  rel. op. it just returns the exp., which gets passed through Logicals
  to Unary again. This handles IF (1+1) > 2
- If Rel. Exp. gets a Unary that's conditional, it returns it (possibly along
  with a leading NOT!). (Don't even look for a rel. op. since it would be
  illegal!) This handles IF NOT (A>B) THEN as well as IF (A>B) AND...

If statements also need to suck up stuff if they're multistatements.
Different BASIC programs I've got seem to allow ELSE right after a
colon OR right after the last THEN statement. Others allow IF/THEN within
an ELSE. (It doesn't make sense in a THEN because the ELSE would slurp up the
other else.) Do we allow that? (If not, make it an error to get a Statement::If
when "parsing_if" is set!)

Indent in subs created from DEF using same code as main Program::output_perl.

    Note that we may want to parse Input/Data stuff intelligent, e.g. to
have non-quoted strings. Could we use nexttok with that too?

Can we make all expressions either string, numeric, or logical? Note that
arithmetic exps need to be string or numeric, since + is handled differently.
And mult. needs to be s or n so that arith. can inherit its datatype from it.
Unary, too.  But conditionals are really neither string nor numeric. They have
string or numeric expressions *in* them (and e.g. both exps need to be the
same type) but there's really no difference between a string & numeric exp.
Which means we should be able to get rid of LBE::Conditional::String &
::Numeric packages, which never need to be used!
    We're actually going to need LogicalOr and LogicalAnd classes if we
want to get precedence right. And change Conditional to Relational (not quite
like C, which separates equality-expression from relational, because in BASIC
<> and > have the same precedence (and you can't have more than one in a 
relational expression anyway)). (NOT will be a field for Relationals 
like the "minus" field for Unary's.)
    But note that in that Unary expressions can actually be string,
numeric, OR logical! 
E.g., (x>2) or (y>1)
(x>2) is a unary logical exp., which should be passed up the 
mult. -> arith -> Relational
chain, so that the LogicalOr object sees that indeed it's Or-ing relational
exps rather than arithmetic ones.
    PROBLEM: if we tell Unary that a paren begins an LBE::LogicalOr, then
even an expression like (3+2) will be a LogicalOr. But it's a LogicalOr that's
numeric! 
    Options: (1) have LogicalOr->new return a regular arithmetic if
that's what it reads, or (2) allow LogicalOrs to be numeric. 
In the case of (1), we avoid having a gazillion expressions to evaluate just
to do 2+2. In face, maybe I should do this anyway, including having an
arithmetic exp. just be Unary + Unary if there aren't actually any mult.
exp.s in it. For (2), that's actually doable. It just means that Relational
exps CAN in fact be string, numeric or logical, not just automatically
logical. (Basically, they'd be string/numeric if they have only one term; same
for LogicalOr/And. And if a LogicalAnd has two terms but one is numeric,
that's a BUG. ("x>2 AND 17")

Case insensitivity in strings? 

Test suite should also translate each to perl & run it & make sure we get the
same output, in order to test output_perl functionality.

Better errors. E.g., instead of using die, we should have a different kind
of error function that says something like "Internal Error on line...". I.e.,
it'll be useful for us to know what line we're on.

----------------------------------------------------------------------
Enhancements to BASIC:

If I want to parse unquoted strings, then I either need to call 
new LBE::Constant directly, or call Unary with some flag set s.t. we're
not allowed to interpret the string as a new variable.

I should have an error if we try to assign a string expression to a numeric
variable. Similarly, there should be a problem if we're parsing & find a
string expression when we expect a numeric one. And e.g., Arithmetic
Expression parser should complain if it finds a mix of numeric and
string expressions.

----------------------------------------------------------------------
BASIC things to implement for The Secret Project:
- LINE INPUT command
- Make sure we can handle a string with value '"'. (Just take ASC(A$)=34?
or do we need to use \" or something? But then we need to quote \ too!)
- LOAD function of some sort? Not *really* needed

----------------------------------------------------------------------
BASIC things to implement for the betterment of mankind:
More complicated conditional expressions
: (i.e. several statements in a line)
Exponentiation
More functions: ABS, SQR, string functions, etc.
file read/write
GET, GET$
RESTORE
NEXT I,J
scientific notation, integer variables
correct handling of RND.

----------------------------------------------------------------------
Things we need like a hole in the head (but implemented anyway):

- output PERL E.g.:
From Tom Phoenix:
    But if a line isn't recognized, you could just throw it in to the Perl
    source, marked with a special comment like "#??" at the start of the line.

Since every line in BASIC is just one line, we could even handle
unsupported commands. In fact, we could overload Exit_Error to output
"#??$Original_Line" instead of exiting. (Note that this does require
storing the original line!)

There should be subs that act exactly like basic PRINT & INPUT, since the
behavior is kind of complicated. Then just call those subs. (And write
the subs into the program!) Except that that may be Hard. Can one write a sub
that handles PRINT "3" differently from PRINT 3? Maybe. E.g., if you're
printing a numeric variable or a number, then print a space. But the
complicated part is expressions. How does this sub, which only gets the output
of $foo->output_perl, know if the '3' that was returned is the string 3 or the
number 3? I can't imagine how it does. Which means that numeric & string
Constants can't be differentiated.

Better AI to print nicer code.
* Ugliest thing now may be do loops, which have convoluted code to allow for
  upward or downward loops. Unfortunately, LBS::Next can't actually access the
  information it needs in order to decide whether to test for > or <. I
  *could* maybe change the way Next is stored. But it would be convoluted. We
  could always use something like
      $test_for = sub {$step_for_k < $limit_for_k}, 
  and then at the end of the loop just test for &$test_for. But it's arguable
  whether that's less convoluted.
* Any way to definitely know when to add \n's to separate blocks of code? 
  Maybe I could only leave whitespace if we're not indented? Same with ifs? (In
  that case, testing has to be done in LBP::output_perl, which may be a
  dangerous (or impossible, if it's calling all the statemeout outputters)
  place to do it.) Have a MAYBENEWLINE command to put space iff we're not
  currently indenting?
* Put ifs on one line if there's no else & it's short? Note that I can test
  length of the string representing the "then" statement (and whether it has
  \n's in it). Alternatively, put extra \n before else if it's more than one
  line.
* Remove all labels but those that are goto'ed to?  Note that (a) this doesn't
  work if there are any computed gotos/gosubs (but who really uses those?) It
  requires keeping a list of the lines that are goto'd to during parsing, so
  that we know which line numbers we need to output before we actually output
  any lines.
* my() variables. Or at least setting some to "" or 0? Otherwise we get
Uninitialized value errors from perl -w.

- output BASIC? In theory, that could be useful for debugging. Right now,
we can't print out lines after we've parsed them.
