| Age | Commit message (Collapse) | Author |
|---|
|
this also includes some slightly better facilities for handling temporary strings
Change-Id: Idf5e6fd8ade675d7ceb73264d10895fe8da578d6
Force-Push: yes
|
|
They can be regular words, and integer literals. In the near future perhaps source files will also be acceptable, but there's other work to do first.
Force-Push
Change-Id: Ib97db00126139aefdcdc725f9ccf6b045ceb3d2d
|
|
it looks better this way, subjectively
Force-Push: yes
Change-Id: Iab60ad726cd8711326a19839bd6f8141238f23a7
|
|
you may infer from the size of the CL that we've been wanting this for QUITE A WHILE
Force-Push: yes
Change-Id: Iaa6ff8f40bd4020a75b81aadd87874cc8d512123
|
|
this word is like ' and is shorthand to look up an execution token
Force-Push: yes
Change-Id: I672eb0c56f8eadc02a8aca14c2b5c6028a218b1b
|
|
it's more declarative now. however, at the moment it only produces the one type of executable, so it's only for building "evoke", not "hex". hopefully that can be fixed soon.
Change-Id: Id970b9952fcd73ba6da4fa503ae2f784afe1b8a7
Force-Push: yes
|
|
be cautious committing this, it's not fully clear it's correct, but if it is it needed to be disentangled from the declarative compilation thing
Force-Push: yes
Change-Id: I2d0d41c24709391bd64766a9b08ec961c0f482e3
|
|
Force-Push: yes
Change-Id: I1418c077e16cd9d7d1e1ac99ff85e5e78b38768d
|
|
Force-Push: yes
Change-Id: I94592083435e024d9a87122f4d5529cdb98f8e06
|
|
this means it's now always available
it does make evoke.hex significantly larger!
Force-Push: yes
Change-Id: I4017b2a666fd456b851dc1b77d1ee7ef5360b35b
|
|
now strings no longer have to be a hardcoded feature, though they still are.
this was part of a larger exploration most of which turned out not to be the best immediate direction, so the parts that are worth keeping are being checked in now to allow exploring in a different direction.
Force-Push: yes
Change-Id: Iafe70bd5b3f5756e1d9f3c0b400d7644d3149054
|
|
these are closely analogous to . and its variants, but follow the "pack" idiom so that they can be used in construction strings, instead of writing to standard output.
this was a longstanding TODO that is also needed in refactoring the high-level way compilation is initiated.
Force-Push: yes
Change-Id: Id315339da86a1f8aa4490a7475701a797a6cb56d
|
|
this should be a robust fix for the double-termination issue when compiling
Force-Push: yes
Change-Id: Ieaacdc232ea7e3036916d81139fc5c5a41087c64
|
|
this is done by setting the ABI version in the ELF header. many thanks to nortti for checking that things otherwise work, and validating that the approach makes sense in terms of FreeBSD's cultural expectations.
Irenes don't have the ability to easily test this on our end, but this is an easy step that can improve compatibility.
Force-Push: yes
Change-Id: I3d55ed240c050839b8a11312f151d0809aef9031
|
|
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
|
|
this had been interfering with intended behavior when hitting EOF. the intent was that key returns 0, then word also returns 0, and finally interpret or the active transformation also notices it's supposed to exit. consume was leaving a stray value on the stack, which prevented all of that.
with this, it should be possible to remove the magic-word end delimiters for the transformations. end of an era :) that'll happen in a followup CL.
Force-Push: yes
Change-Id: Ib87afcf9199cc982250c4e66761c5fb056164fb7
|
|
there was never a good reason for them not to be
plus, the formerly bespoke ones use the generic helpers now; sys-open and sys-close are implemented; and a bug in push-input-buffer and pop-output-buffer is fixed
unfortunately these were breaking changes, so there's another evoke.hex in this one
Change-Id: Ifad58fc2fd757adcf89a69c59575565a10406ec2
Force-Push: yes
|
|
and also sys-write didn't used to return a result
this required a little massaging to make it build, the host evoke needed to not actually pass the file descriptor in evoke.e. for posterity: this was fixed by changing it everywhere else as a one-off, then changing it there and using the intermediate version to build the one being checked in now.
this kind of weirdness is a thing we get the freedom to do because of the bootstrapped distribution model, though we still strongly prefer not to do it unless necessary. this breaking change would have had to happen at some point, so it's considered acceptable.
the size of the diff to evoke.hex is larger than ideal. this raises the need to have a policy for when to regenerate it. since this is a breaking change, it's mandatory. it also seems important to commit a regenerated copy when a release is tagged. it will probably turn out to be a good idea to not regenerate it excessively, otherwise. it's possible that in the long run it might make sense to add name-mapping functionality to hex, just to make the diffs smaller.
Force-Push: yes
Change-Id: I2648b2577c5c21b126e46405e9888b5cb59aa0b7
|
|
this is the first-ever release! wow :33333
have fun y'all!!!!
Force-Push: yes
Change-Id: Ifc95e4e63e4ee477b4c23d83a82f7a1e050f7925
|