bradrn wrote: ↑Mon May 03, 2021 4:30 am
I know you’re not accepting feature requests, but here’s a thought: I’m currently making a new SCA (screenshot of current progress
here) — might it be possible to integrate it with CLanC? The general design of my SCA actually looks fairly similar to yours, especially in the multigraph support. (I know it’s at least possible to compile Haskell to JavaScript, so if I ever get GHCJS working, this might actually be feasible.)
It might be possible to integrate it without compiling it to JavaScript - for which read on.
Discussion of morphology appliers elsewhere in the forum ignited the development spark even more in me, so let me daydream a bit.
I have somewhat grand plans for this piece of software. My personal wishlist for it already spans multiple years' worth of development time, and realistically will probably never all be implemented. So when work resumes sometime next year, I will look forward to address some more fundamental development issues first:
1. The thing has been a mere browser tab so far. This has been bugging me, to put it nicely.
But lo and behold, it doesn't have to be this way. Apparently, desktop javascript programs have existed for quite a while. I cannot express just how glad I am to delegate multi-OS support to something else, and for all my clumsiness in HTML and CSS, it's still the easiest way for me to define user interface. So this is going to be the first major step.
2. But it gets even better (if we have good things, why not just have better things?) -
apparently, Electron apps can use C++ libraries. Meaning currently sluggish operations in CLanC can become blazingly fast. Like applying dozens of sound changes on thousands of words in an eyeblink (somewhat of a promise, but let's see). Of course I'm going to rewrite all SCA and database code in C++ and delegate TypeScript to interface only. Heck, there are already C++ database libraries. Apparently, Electron has been made to use Haskell libraries, too.
3. Let's use some buzzwords. CLanC is going to be widget-based. Currently the interface is rather wooden, but the plan is to make each piece of functionality a widget. A widget is planned to be a separate subwindow - rescalable, movable, able to be opened and closed on a user's whim. A single piece of functionality is e.g. a lexicon table, etymology information, an inflection table, a sound changes list, conlang info etc. The future interface might or might not be inspired by Blender's interface. Also, some or all widgets might be made to use 3rd party library plugins, so that you could customise almost any aspect of the program.
4. And then, the current morphology applier could use some reworking and expanding, too. There are probably better solutions out there, or there will already be, by the time development resumes. Anyway, the grander plan is to expand the SCA into a generic Change Applier, which would be an SCA plus a user-friendly wrapper around SQL - meaning you could change almost any diachronic aspect of a conlang based on almost any other aspect of it, or of its protolang.
E.g. if you deduce that a particular sound change would introduce a new nominal declension pattern, you could write
and all decl. III nouns ending in a nasal would become a new nominal declension called 'noun IV'. But the syntax for all of this will have to be worked out.
All in all, I'm pretty excited about this project. I've already used its prerelease version for last year's relay, and mostly its release version this year's relay. It has decidedly sped up and made easier the conlanging process. One can see the result of a new or altered protolang sound change on a descendant's inflection in just a few clicks, and I have the hunch that it could be made almost realtime without any clicks necessary. It just has to be implemented...