move all the source files into subdirectories

and rename one, linux-dynamic.e to language/dynamic/linux.e.

also make sure all references in comments and documentation refer to the new locations and names.

this directory structure reflects code organization which had existed in Irenes' head, but was likely not obvious to other readers. now hopefully it is more discoverable.

Force-Push: yes
Change-Id: Icfef3eae812a50fe20202191999e68e1f7db445a

1 files changed, 41 insertions, 38 deletions

diff --git a/README.txt b/README.txt
index 55ba61b..ce7a254 100644
--- a/README.txt
+++ b/README.txt
@@ -129,7 +129,8 @@ lexer feature for that sort of thing. Evocation doesn't do that, because
 eventually fancy syntax and grammar will be implemented at a higher layer,
 using the experimental parsing formalism that doesn't exist yet. If you want
 to see where this feature would be if it were implemented in the simpler way,
-you can read the definition of the word named "word", in interpret.e.
+you can read the definition of the word named "word", in
+language/dynamic/interpret.e.
 
   If you went to look at that and you're wondering: Yeah, Evocation's lexer
 really is that short and simple. Part of why it's able to be that easy is that
@@ -207,45 +208,47 @@ evoke.e. It's really short, and worth a quick glance right now. It lists all
 the other source files and the order they get loaded in and how they're
 processed.
 
-  The files that do the work to make Evocation run at all are execution.e and
-core.e. It's worth reading through both of them slowly. After you've read
-core.e, you'll know a lot of basic words that can be used as commands within
-Evocation.
+  The files that do the work to make Evocation run at all are
+compilation/execution.e and language/static/core.e. It's worth reading through
+both of them slowly. After you've read core.e, you'll know a lot of basic
+words that can be used as commands within Evocation.
 
   A lot of Evocation is written in Evocation's version of assembly language.
-The file amd64.e is the one that implements all the assembly instructions.
-Writing a real program in assembly also requires resolving labels, which are
-a special syntax that gives names to addresses. The behavior of labels is all
-implemented in labels.e.
-
-  On the assembly language front, there's also linux.e which contains assembly
-words for doing things specific to the Linux operating system, such as reading
-input, and there's elf.e which contains words for outputting the special file
-headers that let the operating system understand that a file is an executable
-program.
-
-  In terms of the Forth-y bits, input.e and output.e are concerned with
-getting text into and out of the language. The infrastructure to define words
-is in dynamic.e, and the syntax for it is in interpret.e. The high-level flow
-control words are in flow-control.e. Some of the features of execution.e had
-to be separated out into their own file, because of details about how the
-compiler works; that stuff is in execution-suport.e.
+The file language/static/amd64.e is the one that implements all the assembly
+instructions. Writing a real program in assembly also requires resolving
+labels, which are a special syntax that gives names to addresses. The behavior
+of labels is all implemented in compilation/labels.e.
+
+  On the assembly language front, there's also language/static/linux.e which
+contains assembly words for doing things specific to the Linux operating
+system, such as reading input, and there's compilation/elf.e which contains
+words for outputting the special file headers that let the operating system
+understand that a file is an executable program.
+
+  In terms of the Forth-y bits, language/dynamic/input.e and
+language/static/output.e are concerned with getting text into and out of the
+language. The infrastructure to define words is in language/dynamic/dynamic.e,
+and the syntax for it is in language/dynamic/interpret.e. The high-level flow
+control words are in language/dynamic/flow-control.e. Some of the features of
+compilation/execution.e had to be separated out into their own file, because
+of details about how the compiler works; that stuff is in
+language/static/execution-suport.e.
 
   So, there's all those relatively normal compiler internals in those various
 files, which are all fairly self-contained... and then there's the
 transformation facility. This is Evocation's most unique architectural
-decision, and it's in transform.e. It's well documented, but it's also
-extremely conceptually dense. Feel free to give it a skim, that's the only way
-to build familiarity with these things, but you should probably have a solid
-understanding of the rest of the internals before you place any high
+decision, and it's in compilation/transform.e. It's well documented, but it's
+also extremely conceptually dense. Feel free to give it a skim, that's the
+only way to build familiarity with these things, but you should probably have
+a solid understanding of the rest of the internals before you place any high
 expectations on yourself around understanding the transformation facility.
 
   It's okay, you can benefit from it before you understand it: Transformation
 provides the core tricks that make it possible to compile Forth code into
 standalone executables. The call to label-transform in evoke.e, and the call
-to log-load-transform in execution.e, are the two spots where compilation is
-handed off to the transformation facility, and you can pretty much just take
-it for granted that it works, until you feel ready.
+to log-load-transform in compilation/execution.e, are the two spots where
+compilation is handed off to the transformation facility, and you can pretty
+much just take it for granted that it works, until you feel ready.
 
   If you want examples of programs that are smaller than Evocation itself,
 quine.e is a tiny program written in proper Evocation that outputs its own
@@ -305,13 +308,13 @@ created.
 
   The binary bootstrapping strategy rests on something called the
 "hex transform", the most complex of the transformations provided as part of
-Evocation's transformation facility in transform.e. The hex transform has the
-task of transforming an entire compilation process, which would otherwise
-produce an executable binary, and instead output a commented hex dump of that
-binary which describes its internals and their purpose, byte by byte, in
-sufficient detail to allow a human reader to audit their correctness. It will
-do this by passing through comments and call-stack information from the
-compilation process to the resulting output.
+Evocation's transformation facility in compilation/transform.e. The hex
+transform has the task of transforming an entire compilation process, which
+would otherwise produce an executable binary, and instead output a commented
+hex dump of that binary which describes its internals and their purpose, byte
+by byte, in sufficient detail to allow a human reader to audit their
+correctness. It will do this by passing through comments and call-stack
+information from the compilation process to the resulting output.
 
   In order to turn this commented hex dump into a binary, there is a tiny
 program called "hex" which handles comments in Evocations ~ syntax, and
@@ -359,8 +362,8 @@ do in the  near future, now that bootstrapping is complete.
   Nearly all of this runtime is attributable to the log-load transform; if
 you're working on something that doesn't involve the log-load transform, you
 may find it useful to temporarily comment out the call to log-load-transform
-in execution.e, replacing it with two invocations of drop. This will not
-produce a working compiler, but it will finish faster.
+in compilation/execution.e, replacing it with two invocations of drop. This
+will not produce a working compiler, but it will finish faster.
 
   Now get debugging! :)