Considerations

Items I'm not sure whether adding or implementing those would be of advantage.

• save-system

  I tend towards building from source, possibly from a load- and configure-file, rather than saving a snapshot which may be harder to recreate, and am therefore inclined to skip such a feature.

• rename yoda to 0x18afde

  this would make it unnecessary to come up with some weird wording for what the acronym "yoda" stands for - yoda would then merely be the numeric radix 36 representation of the name 0x18afde and mostly used because of matter of convenience.

• tick invokes satisfy when word not present

  allows ticking not yet resolved and compiled words: when tick doesn't find a word, it attempts to compile it through the satisfy mechanism, then produces the now existing xt. word not found will still be produced if satisfy can't resolve the word. Counter indication: tick is sometimes used to interactively check presence of a specific word. It may be unwanted to include and compile the word as consequence of such a test.

• wondering whether zshell may be preferable for using git

  as bash appears to be capable of correcting minor errors in directory names only. I've been typing "gut push" and now also for a change "gut pull" so many times, and while it is comforting to know that bash doesn't know how to pull guts, the mere thought of pulled guts makes me feel uneasy.

• memory

  Thinking of examining what ways and methods exist to allocate memory and access it by displacement/offset, by pointing a variable to base address of allocated RAM, as alternative to virtualising memory through a bash array.

• combining flags instantresolve and forwardrefs to a single variable with

  two levels of forward resolving. 0: no forward resolving at all. Word must exist, or an error is thrown 1: resolve from library only: if a word can be resolved from library: interpretation: compile and execute compilation: mark as forward reference, compile the dangling reference, resolve when finished compiling. 2: interpretation: like 1 compilation: mark always as forward reference

• should I consider all headers in lib files transient unless listed in provides:

  As those libraries inform dependency generator about the words they supply, those not specified will appear in dictionary without a clear indication why they're there. Currently, those clearly not overly useful words are manually marked as discardeable, using "transient". I wonder whether it makes sense to consider all words transient unless marked as those the library file provides.

• convert and convert$ should swap names

• I think of trying to drop line parsing words, in favour of string

  stack item consuming words. For many words, both variants exist, which seems unnecessary. string item consumers seem to me more Forth-like than input parsing words, and parameters are more easily passed. 10 "ten" constant may look a tad unusual, just as "10 for i . next" "foo" : but consider that "filename" from is easier to pass filename to than from filename, making for example adding extensions, trying different directories as path a lot, or inserting a test of file existing easier. As Forth users ought to be familiar with the notion of operand preceding operator, extending that principle to strings seems to be a very logical step, increasing consistency: "wordname" '

  An issue may arise because of possible needed nested double quotes.

  "["wordname"] [']" "foo" : "[ "wordname" ] [']" "foo" : "[ "wordname" ' ] literal" "foo" :

• Trying out scalar type data structures, by undimensioned default behaving

  like variables or values, but being resizeable in "rho". Just the same, operators taking account of underlying operand dimensions, with some added specifically for multi dimensionals, like rotation, intersection etc. A bit APL like, but processed from left to right, rather than from right to left. Possibly with the difference that if there's no final assignment, results will stay on stack rather than being printed to output. As this would be sort of APL backwards, the proper name might be LPA.

• lists of wordlists may not only contain wordlists (by wid)

  but also other lists of wordlists.

• wordlist properties per wordlist: case sensitivity, implied search prefix,

  event hooks, visibility, rw/ro