LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Wed, 2 Sep 2020 11:21:46 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID: <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <20200821120423.GI26860@grihete>
Content-Type: text/plain; charset=utf-8; format=flowed
From: Joseph Wright <[log in to unmask]>
Parts/Attachments: text/plain (63 lines)
On 21/08/2020 11:04, Emmanuel Beffara wrote:
> Hello,
> I have been reading this list for some time and I must say that I am
> impressed and enthusiastic on the recent work done on LaTeX3 and that it
> did renew my interest in TeX programming.
> I am developing the ebproof package using expl3. The point of this
> package is to typeset proof trees made of inference rules, as people do
> in logic and computer science, which involves precise alignment
> operations and construction of boxes with precise dimensions. I just
> uploaded a bugfix release to CTAN because it broke with the new LaTeX
> release (this is my punishment for using a private function from the
> kernel although I knew I should never have done that) and it reactivated
> a few questions I had regarding the proper way of programming with
> boxes, so I thought I would finally ask here.
> Firstly, the basic object that my package manipulates is a box equipped
> with extra information about the position of some elements inside, used
> for alignment. This is clearly the situation that coffins are designed
> to address and I would love to use coffins with extra poles for the
> operations I use. However I cannot do that currently (so I use boxes and
> property lists by hand) because there is apparently no way to extract
> information about the poles, a feature that is required for my use case.
> Essentially, I need to be able to compute the distance between two
> poles. More generally, I think getting the coordinates of a given handle
> would be a very useful thing to add to the public interface of coffins.
> Do you think it would make sense?
> Secondly, the package works logically by manipulating a global stack of
> annotated boxes (this follows the tree structure of the material to be
> typeset and it is pleasant to work with). However, there is no natural
> way to implement stacks of structured data, the seq type only provides
> this functionality for balanced token lists. So my implementation uses
> (1) a global hbox to act as a stack of boxes, which works thanks to
> \box_set_to_last:N, and (2) a global seq that acts as a stack holding
> property lists, but that uses the fact that the prop type is actually
> implemented using tokens, and I am not sure this is good practice.
> Besides, if (when?) I move to using coffins, this will not work anymore.
> Do you think of a better approach to manipulate a stack of objects?
> The only robust approach I can think of is to allocate numbered
> variables on demand (like \g__stack_item_N) and use that as storage for
> the stack, but this unorthodox use of registers might cause problems I
> fail to think of right now.
> Would someone have thoughts or insights on all this ?
> Cheers,

Hello Emmanuel,

Others are more qualified than me to comment on trees, etc. What I would 
note is that coffin poles are *relative* structures: if the coffin is 
resized, the absolute gap between them will alter.

Probably once the next LaTeX release is out, other team members will 
chip in.