74b5a9cbbathis 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
29 lines
869 B
Text
29 lines
869 B
Text
: prepare
|
|
here @ dup
|
|
s" core.e" pack-file-contents
|
|
s" linux.e" pack-file-contents
|
|
s" output.e" pack-file-contents
|
|
s" amd64.e" pack-file-contents
|
|
s" execution-support.e" pack-file-contents
|
|
s" log-load.e" pack-file-contents
|
|
s" dynamic.e" pack-file-contents
|
|
s" input.e" pack-file-contents
|
|
s" interpret.e" pack-file-contents
|
|
s" flow-control.e" pack-file-contents
|
|
s" linux-dynamic.e" pack-file-contents
|
|
s" files.e" pack-file-contents
|
|
s" labels.e" pack-file-contents
|
|
s" elf.e" pack-file-contents
|
|
s" transform.e" pack-file-contents
|
|
s" execution.e" pack-file-contents
|
|
s" evoke.e" pack-file-contents
|
|
0 pack16 8 packalign here !
|
|
s" evoke-source" variable
|
|
|
|
1024 1024 4 * * allocate s" evoke-binary" variable
|
|
1024 1024 4 * * allocate s" evoke-metadata" variable ;
|
|
|
|
prepare
|
|
evoke-metadata evoke-binary dup evoke-source hex-transform
|
|
bye
|
|
|