Incorrect literal with base-switching prefix changes the base for numerical conversions.

[wzab]

Forth allows certain base-setting prefixes in literals:
e.g.,:

• & – decimal
• # – decimal
• % – binary
• $ – hexadecimal

unfortunately, it seems that in swapforth the error in parsing of the literal after the prefix leaves the base modified according to the prefix. Below is an example of session demonstrating the issue:

>decimal
  ok
>%101 .
 5  ok
>$32 .
 50  ok
>%fggdg
 error: F3 +
  ok
>$32 .
 110010  ok
>

In gforth, an attempt to parse the incorrect literal doesn't lead to changed base:

Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
decimal  ok
%101 . 5  ok
$2 . 2  ok
$32 . 50  ok
%fggdg 
:5: Undefined word
>>>%fggdg<<<
Backtrace:
$7F0C14C6EA68 throw 
$7F0C14C84DB0 no.extensions 
$7F0C14C6ED28 interpreter-notfound1 
$32 . 50  ok

Similar problem in swapforth occurs also for other base-setting prefixes. Below is an example of unintended switching to hex mode due to entering the incorrect literal with "$" prefix:

>decimal
  ok
>$fgdds
 error: F3 +
  ok
>$32 .
 32  ok
>#51
  ok
>.
 33  ok