I have several questiong regarding Dialog as a platform. I have no experience with it, other then reading the manual and performing the simplest of tests.
Is it true that Dialog handles individual files by basically concatenating them together?
Is there a way to limit the visibility of certain predicates so as to ensure better modularity and avoid name collisions (i.e. make a library have an inner set of “private” predicates and only expose the “public” predicates to the outer code)?
Is there any kind of a maintained registry, or at least a general dump, of the third-party Dialog libraries?
Regarding the issues at large dictionary sizes (as discussed here), what is deemed to be the largest practical vocabulary?
3. 1. More specifically, would a scribblenauts-esque library of objects (hundreds if not thousands of rather generic objects with serially defined properties, so as to cover all the common words for objects) be implementable in Dialog?
Are there any known forks of Dialog? In particular,
4. 1. Is there a fork that splits the standard library into more digestible chunks, so that one can more easily read it, edit it or disable the unneeded parts?
4. 2. Are there any “must-have” forks that fix some discovered bugs or introduce otherwise missing behaviour to the standard library and/or the compiler?
4. 3. Is there a maintained registry, or at least a general dump, of the forks?
1.1 no there is no visibility or scoping mechanism. For the size of projects built with Dialog, it isn’t really needed (in my humble opinion).
2. and 3. I don’t know.
4. I don’t think there are any forks of Dialog. The people here has been discussing a version maintained by the community (mainly for bug fixes, and potentially some small feature enhancements), but not much has happened yet (AFAIK).
4.1 I think the idea of Dialog’s standard library is a resource which you add to your project, then adapt it to whatever you need (add stuff, remove stuff, etc). While it is not small, it is not massive either, so that is feasible.
2. There are few enough third-party libraries at this point that I don’t think anyone’s made something like that yet. I had a repo at one point with some little extensions in it, but it was long enough ago I don’t think they work any more.
Still, that would be a good idea to make!
3. Unfortunately not. These sorts of issues don’t seem to have really been a concern when designing the language, and now it’s no longer maintained.
3.1. Currently, Dialog only compiles to 16-bit platforms, so anything involving hundreds or thousands of generic things is probably going to struggle with memory limits.
4. Not yet, but we’re hoping to make one that can compile to 32-bit platforms, which should ease many of these restrictions!
4.1. This one doesn’t really require a full fork; the intent of the standard library is that you’ll edit and modify it as needed for each project you make, and since Dialog handles multiple files on the command line by just concatenating them together, I don’t think there’d be any issue with creating something like this on its own. The main issue is that there’s no “include” mechanism so you have to supply every single filename on the command line every time you compile.
Libraries: I’m organizing my threaded conversation, scene, and tutorial mode libraries into a single repo, with tests and documentation. I’m still working on the right name for this collection.