| Age | Commit message (Collapse) | Author |
|---|
|
this means it's now always available
it does make evoke.hex significantly larger!
Force-Push: yes
Change-Id: I4017b2a666fd456b851dc1b77d1ee7ef5360b35b
|
|
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
|
|
this means all the build invocations are now as simple as they can be without new abstractions of some sort, such as letting evoke take command-line parameters. yay!
Force-Push: yes
Change-Id: Id877159f995662b8d226a9ad937ed73228a9af05
|
|
this was the subject of a bunch of thought. in most languages, we'd argue against having a text-based "include" feature, because there should also be a module system, and textual include subverts the module system because you can't assume everyone will use it.
however, Evocation already very strongly encourages thinking of a program as a sequence of operations (this is after all the definition of a catenative language), and in particular the transformation system already relies very heavily on programs-as-text. so, it seems appropriate for Forth in general and for Evocation in particular.
plus it was easy to implement, because all the infrastructure for it already existed to support the transformation system
Force-Push: yes
Change-Id: I76f778e44b8189ac7052890c881654d971e43c8d
|
|
now all the command-line invocations are pleasingly short :)
Change-Id: Ibe2b9f3b85ab3a51a9d95e3511b273664e6a8807
Force-Push: yes
|