[sword-devel] new morphology

[Chris Little]

DM Smith wrote:
> Chris, given this I don't think that it serves much purpose to put  
> this into a module.
> 
> I see two advantages in encoding this:
> 1) It is straightforward, much simpler and much smaller. Which will  
> translate into very fast (no I/O).

It's not entirely straightforward (in my experience). The individual 
code parts can be of variable length. A particular letter could stand 
for one thing in one context, another thing in another, or just be part 
of a longer abbreviation in another context.

There's also the issue of our not currently having any facility for 
virtual modules like this. I did some test code a while ago to produce a 
virtual commentary module from the current Bible's notes (i.e. all of 
the notes from the currently selected module show up in a special tab of 
the commentary pane). But that was all BibleCS-specific and we would 
need to re-implement something sensible in the API. (And we might want 
to think about it a little before leaping right into implementation.) 
Then again, a nice virtual module framework would finally let us do 
things like virtual commentaries from Bible notes, wdiff modules, etc.

A module also has the advantage of being releasable today--as opposed to 
whenever the next library rev goes out. But I do think library code is 
easier to maintain than modules are.

A module also brings with it lots of nice features to which we are 
presently accustomed. With a module, we can get a list of keys (since 
it's a static, finite list). If we do this algorithmically, I don't know 
how we would populate the key listboxes. With JSword, since I believe 
there's not even a facility for key input with LD-type modules, I don't 
see how this would work at all.

Modules also have the feature of key linking, with which we could go 
ahead and build the TVM codes (currently present in some modules) into 
the module. TVM codes couldn't even be decoded algorithmically, so 
facilitating them would require a giant lookup table. (But TVM shouldn't 
be a big factor, since I plan to phase them out, going forward.)

> 2) It can readily be internationalized. (Which in JSword would be via  
> property files.)
> 
> To me the second is the greater gain.

I had considered this, but to me it's really not of much benefit. It 
produces a bit of extra burden for translators (and a burden that 
requires somewhat specialized knowledge). But fundamentally, there are 
very few English terms in a morphology module--mostly just ordinal 
numbers (first, second, & third). And we could change those to numerals 
(1st, 2nd, & 3rd) to make it a little more transparent to a 
non-English-speaker. More importantly, if you can't understand the 
morphology when explicated in English, you probably can't understand the 
terms in your native language either.

It's not that there's no benefit to internationalizing the morphology. 
It's just that I don't see there being much benefit.

If you like, I could just translate the whole thing back into Latin, 
where it really belongs.

> My Hebrew is extremely rusty, but I hope that this would require very  
> little addition to satisfy the language differences. Perhaps if one  
> (i.e. you) could map the OT morph codes in the KJV to the appropriate  
> entry in this new morphology, then one (i.e. me) could modify the  
> KJV's OT to use these new codes.

Sorta. Hebrew has a vastly different morphological system from Greek. 
(Afro-Asiatic and Indo-European, if related, split so long ago that 
we're not really certain that they're related.)

I do have something in mind for a Hebrew morphology, but it's not quite 
ready for sharing in public. I do want to address those TVM codes in the 
OT... fear not.

> A third gain is that our (I know I said two) would be that it would be  
> less likely to be taken by other projects. It seems that our modules  
> find themselves in all sorts of projects. Maybe "they" get them from  
> the same sources.....

Indeed... this one I've found in the most interesting places.... :) But 
it does say it's public domain, and I'm not that concerned about people 
stealing one of our most uninteresting modules.

> If you would provide a Perl parser, I would find it very easy to  
> convert that into Java.

If only I still had it.... I wrote a Perl parser for the currently 
released module, but that was years ago. Now I just have a Perl 
generator that algorithmically determines all possible codes and 
generates the code plus its explication simultaneously.

Do any of these points change your leanings? I'm really not convinced 
either way--but keeping a (real) module sure does seem like the easy path.

--Chris