File tables have some pretty interesting implications for persistent processes. (This would be even better if you could use data structures other than just strings as values.)
Would it be possible to associate file tables with specific directories? In the current implementation, the directory for the file table changes whenever you use change the working directory, so you can't really have file tables in multiple directories at the same time.
Should be possible if you give a fully qualified path (file-table "/home/eds/somewhere")
Anyway it's probably better to figure out how Arc can get the fully qualified path from a path string, i.e. (get-fully-qualified-path ".") => "/home/eds/arc-installation/". Probably by ($ ...)
Unless you're referring to something else?
As for "other values".... the only real problem anyway is serialization. Ordinary Arc values that can be input into Arc via text are of course trivially serializable, but something created via:
(= x (cons nil nil))
(= y (cons x x))
(= (cdr x) y)
Its not that serialization is difficult, but this seems like repetitive code that should be abstracted away. Maybe we should have one type/mode/version of file-table that reads everything as a string, and another that automatically prints a readable representation so that the object can be read back in later.
Of course, the above doesn't memoize, so repeated calls to ftab!fname will return different ((iso ftb!fname ftb!fname) => t, (is ftb!fname ftb!fname) => nil) objects.
And of course, you're not supposed to write circular objects with the above.
And then someone will want to use temload and friends... hmm. Need a good way of abstracting the abstractions...
Then memoization will be done on the file-contents (ct and mt) tables instead of actual file-table objects.
It would be useful also to have non-memoized versions, accessible via 'nocache:
(def grep* (rex path)
(zap re rex)
(accum collect
(ontable k v (file-table path 'nocache)
(if (re-match rex v) (collect k)))))
'nocache would be useful for such cases where you want to scan through files but not cache their actual contents.
It might also be useful to store cached contents only for a certain time, to preserve memory (but then gc will get run anyway).
p.s. supporting tagged options will make an optional path argument difficult. I suppose I can check if the first argument is a string, though, and treat it as the path if it is.