3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
5 _The k8 project was effectively a Java SE 8 operating system and as such_
6 _all of the notes are in the context of that scope. That project is no_
7 _longer my goal as SquirrelJME is the spiritual successor to it._
11 Figured out how the label statements work, the labels only are visible within
12 the following statement, and that can be any statement. However, since labels
13 are only able to be used by break and continue they are not as useful outside
14 of loops except for declaring some blocks of code or similar.
18 Throwing all of the tokenization stuff in a single file is going to be very
23 However, writing a compiler and a tokenizer in one will just needlessly
24 duplicate the work I am doing. Some of the language stuff is the same, perhaps
25 I can create a kind of syntactic like thing that can read a file. Something
26 that can be described with annotations and such, and then that is used to
27 parse the file and such. I believe what I should do first is after having
28 basic tokenization words is to build a tree-like structure of the source code
29 with bounds and such, ignoring any keywords. Basically this will be something
30 on the level of using only scope, generic brackets, array brackets, and
31 parenthesis. So it would essentially become a tree-like structure of
32 statements where some known structure is easier to parse. So basically each
33 statement would be on its own line. There would need to be special handling
34 for stuff such as fields and default values in annotations. However, that
35 would just duplicate it as I would have the tree building then a parser for
36 that tree. So what I really need is a smarter and cleaner Tokenizer that will
37 not be a gigantic mess.