LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Emmanuel Beffara <[log in to unmask]>
Fri, 21 Aug 2020 12:04:23 +0200
text/plain (51 lines)
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,

-- 
Emmanuel

ATOM RSS1 RSS2