Major stuff:

I should be able to get rid of the '=' in &lex now, since we always join
& the find the = by parsing stuff one by one.

Maybe lex can remove all whitespace EXCEPT put spaces around keywords?
Because we don't want to get LETA=2. Or "2>XTHEN" while parsing an IF. Can we
do that by just splitting on (".*?" and) whitespace, then 
    grep {if /^\w+/ {$a=$&; grep {$_ eq $a} @Keywords}} @tokens?
We could even give each statement its own lex, and run $statement->lex before
$statement->parse. Then it would only look for the particular keywords in its
own statement. Or maybe we can get rid of LEX and just have a nexttok sub
that effectively does the same thing, & cat_until calls nexttok until it
hits something interesting. In fact, I might even be able to use nexttok
in parsing, so that I don't eat something before I'm supposed to -- e.g.
we can't eat a function name when testing it, since it might actually be
a variable name. We could have an eating & a non-eating nexttok. Might I
even be able to have nexttok have a local string that it eats from (which
can be set by set_tok) s.t. we don't have to pass textref around everywhere?
I guess nexttok would be in LB::Common. We could also make nexttok be
intelligent, returning EITHER whitespace separated words (where $ counts
as a word character!), string constants, or tokens like (,;).
    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?
    Far in the future, we could even have a cat_until_eos, which looks for
either : or \n.

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")

Note that variable->{"goto_line"} never gets initialized, because Variable::new
just blesses to Variable::Numeric. Should I have a "refine" subroutine that'll
set some new stuff?

Case insensitivity in strings? 

Ugly kludge in LB::Expression::Constant::parse. See TODO there.

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.

If we ever get good enough, we should test that there's no text left
in a statement when we're done parsing it or there's an error.

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.
GET, GET$
RESTORE
NEXT I,J
float numbers (4.3e-3 et al.), 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? End
  of a do block looks dumb when it's in a nested loop. 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.)
* 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).
* 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.

- An interpreter using Term::Readline where you could actually input stuff
line by line, load new programs, run them, etc. (David Glasser started this)
