BUG LIST for BASEC v0.20
---------------------------------------------------------------------------
Contact author: William Yu <voxel@edmc.net>
BASEC homepage: http://www.basicguru.com/abc/basec.html

There are some bugs which are actually design decisions, but you should be
aware of what they are anyway (they're denoted with '+').
Some design decisions were carried over from my previous version 0.02
All other versions were a partial rewrite of the older compiler.
To patch some of these bugs would require another partial rewrite.

Some known bugs (denoted '*'), these are the most noticeable:

* Expressions need to be of the SAME TYPE for the ENTIRE expression:

  Example:
    IF i>0 AND a$="huh?" THEN
      ?"whatever"
    END IF

  Need to be separated to:
    IF i>0 THEN
      IF a$="huh?" THEN ?"whatever"
    END IF

  This is a major flaw that I overlooked.

* Undeclared string variables...
  Although I can't quite explain it, there are such events when an
  undeclared string variable may cause problems, especially when reading
  from input (inkey$, input$, get$).
  Try TICTAC.BAS but remove the key$="" on line 13.
  In other cases it poses no problems at all.


+ BASEC doesn't recognize the NULL character, ie. chr$(0)
  So when you use INKEY$ to read extended keys, like upArrow, it won't
  return the NULL character.  Although considered a flaw, I never intended
  to support the NULL character, just to make life easier...
  Okay fine, it's a flaw ;-)


* IF THEN ... ELSE ...
  At the moment, ELSE cannot be on the same line


+ RND(n)
  If you choose to use the RND function without the n argument, the random
  number will be returned to 5 decimal places (.12345) unlike the 7 for
  QB/PB.  This is a design decision, I could extend this to 10 or more
  decimal places, but it would eat up CPU time.  I think 5 is good enough.


* No fixed string array
  At the moment all string arrays are fixed to 255 characters...
  This is not really a bug, just a laziness on my part.


+ TIMER bug?
  This is not really a bug, but I have no idea where QB/PB gets their
  TIMER value from... BASEC's TIMER begins at 0 everytime the program
  starts.


+ PRINT does not accept commas as a formatting statement
  All numbers are printed as is, with no formatting, or extra spacing.
  These aren't flaws, just design decisions.
  For compatibility reasons, the comma has the same functionality as
  using the semi-colon.


+ EXTENDED data type is there for PB compatibility reasons, it has the
  same functionality as DOUBLE, but eats up 10 bytes nonetheless.
  So if you had GET #1,,Extended##  It would read 10 bytes.


+ STEP can only take one argument (numeric variable or a number)
  Example:
     FOR I = 1 to 100 STEP 52 MOD 50  ' only takes the 52

     n = 52 MOD 50                    ' use this instead
     FOR I = 1 to 100 STEP n

  This is a design issue from my previous version that I'm too lazy to resolve.
  If it's a variable, it cannot be an array.


+ INPUT a$
  For the time being, INPUT will have the same functionality as LINE INPUT.
  That means INPUT will only take one return value, and commas will not be
  excluded from the string.  Again, this is due to my laziness.
