>>77
Excuse that this reply isn't better. I've been tired lately.
The latter makes me wonder if you've considered persistent recollection at all (e.g. saving deltas to disk)?
No. That belongs in the operating system. On this note, a recollection system is equivalent to these version control systems, but of course better in every way. There's no particular reason why it should only be possible to recall earlier changes from one session, rather than all sessions, and having such a system in place makes it obvious the VCS is unnecessary. That is, these should be the same things, in the same sense IRC and email should be, because the only distinctions are the queer disjoint features and intent.
It seems to me the system could be a little more than a shell with regards to efficiently implementing CHANGE and RECALL on objects with assessors. CHANGE could have SETF style semantics and interface.
The issue is how I can't transparently intercept everything, so it's more explicit than I'd want. Ultimately, I should just implement an MMC recollection system at some point, and then reflect on it to continue.
You could then have a NEW-MEMORY procedure which takes an optional INVERSE procedure, it establishes a new group of entries in the history to be undone at once, which would be filled with calls to CHANGE between it and the next call of NEW-MEMORY or RECALL.
That NEW-MEMORY name is unworkable. I chose CHANGE and RECALL so they'd be equal lengths.
Groups would then be either a record of variables to old values CHANGE'd or an inverse function. The RECALL system then mutates the variables to the old values or calls the inverse function and then pops off the last element of the history. The inverse function could be of course replaced by an encoding in the history for a more efficient representation.
Perhaps I didn't make it clear the history should be traversable both ways.
In Elision does this indicate a willingness to reify roots and cases (even Chinese characters have radicals)?
Yes. I'd like to store infinitives and have declining rules and a list of exceptions, for languages such as Latin and Esperanto; this would result in text being stored as a list of such infinitives and other bases, with the particular rule to apply attached with the particular usage. For English, this may be less reasonable, and at least the initial version of that targeting will simply have a code for every possible word; English may benefit more from separate tables which hold such information, with which to perform analysis.
I learned Latin to improve mine English, and it slowly but certainly showed me how deformed and sickly it has become.
You lose some of the efficiency of a compression scheme without the constraint of semantic significance, but you gain easier semantic analysis and addition of new words derived from roots and cases but not yet in the dictionary.
It's not necessarily less efficient, if the quantities align correctly.