Re: [Silgraphite-devel] New engine feature proposal

[Sharon C. <sha...@si...>]

So you're saying that we would create 16 built-in slot attributes 
called ref1, ref2, ref3, whose values are expected to be a slot 
reference. (I assume these could be #defined to have more meaningful 
names just like user1, user2, etc.)

This seems fairly easy at the compiler level. I must be missing 
something. :-)

Do the values need to be computed (eg, @user1+someglyphattr), or will 
they always be simple integers (@1, @2, etc)?

More questions below...

On 11/20/2012 2:23 AM, Martin Hosken wrote:
> 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.

Is this what you are calling the "slot stack"?

> 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

I assume you mean the pointer...

> 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.

I don't understand this. Are you saying that AttrSetSlot and 
IAttrSetSlot need to be able to pop from the new slot stack as well as 
the standard stack (in order to set slot-ref slot attributes on the 
current slot)? But if so, how does the 0x7F play in, where does it go? 
Or does this refer to PushAttToGlyphAttr and PushAttToGlyphMetric? 
(but I'm not clear why that would be needed).

> 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.

Isn't the whole purpose of a stack to handle arbitrarily 
complex/nested arithmetic operations? So if there is no arithmetic 
being done on a slot-reference value, why have a stack at all? Why not 
just 16 "registers"? Is that what you're suggesting? Or is arithmetic 
in fact needed to calculate the index of the slot?

(And what is a non-popping stack, anyway? Aren't pushing and popping 
inherent in the definition of a stack? :-) )

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

It's not immediately clear how this would be useful in other scripts, 
but I haven't had time to think about it.