[Silgraphite-devel] New engine feature proposal

[Martin H. <mar...@si...>]

Dear Sharon,

In my thinking about signwriting, I am realising that trying to do all of the associating of diacritics to base characters is going to end up in a complete nightmare of regular expressions. But if we could add a feature of being able to store slot references as an attribute (well a set of slot reference attributes) on a slot, then life could become a whole lot simpler. I don't know how interested other scripts would be in this. Perhaps it would save walking backwards through nastaliq text for example.

Anyway my proposal is to add a slot attribute class .ref as in:

cBase cAttach { ref1=@1 };

I think I won't need more than 16 of these.

In opcode terms we are thinking the best thing is to have a separate stack onto which pointers to slot are put. This stops people doing math on pointers, for example. It also gets around the 32-bit/64-bit problem and the question of storing 64-bit pointers in user attributes which are 16 bit. Using absolute pointers is much easier for GDL authors since they can delete stuff in between and not worry about having to update things.

This would require a new opcode:

PushSlot slot_ref : finds the point to the given slot and push it onto the slot stack
SetISlotRefAttr slot_ref index : pops the slot stack and stores in the given slots given slot reference attribute
GetISlotRefAttr slot_ref index : gets the slot reference attribute from the referenced slot and pushes it onto the slot stack.

The immediate thought is that all opcodes involving a slot_ref are now going to need slot stack based versions. But an alternative is to say that a slot_ref = 0x7F would mark that the slot_ref is to come from the slot stack rather than as an index into the slot array. This works because rules can't be longer than 64 slots long anyway so you shouldn't be up that high.

While this approach will make doing signwriting possible, it's not completely ideal since I would quite like a non-popping stack of these slot_refs. But I think that is overkill for one script. I can see that having a generalised ability to add slot refs to a slot is going to be useful elsewhere. In addition, it would still be needed even if I had my non-popping stack. So I suppose this is the minimum necessary to make signwriting feasible.

What do people think? Would you rush out and use/abuse this feature? If so, what would your use case be?

Yours,
Martin