Re: [Groff] .als problem

[Werner LEMBERG]

> > What do you expect?  Current reality is that troff bombs out with
> > 
> >   xxx:7: fatal error: input stack limit exceeded (probable infinite loop)
> 
> I didn't expect this, and set out writing this email to say it was
> wrong, but having thought about it, it's understandable.

Yeah.  Here is my addition to the documentation of .als in the info
file:

     To understand how the `als' request works it is probably best to
     think of two different pools: one pool for objects (macros,
     strings, etc.), and another one for names.  As soon as an object
     is defined, `gtroff' adds it to the object pool, adds its name to
     the name pool, and creates a link between them.  When `als'
     creates an alias, it adds a new name to the name pool which gets
     linked to the same object as the old name.

     Now consider this example.


          .de foo
          ..
          .
          .als bar foo
          .
          .de bar
          .  foo
          ..
          .
          .bar
              => input stack limit exceeded

     The definition of macro `bar' replaces the old object this name is
     linked to.  However, the alias to `foo' is still active!  With
     other words, `foo' is still linked to the same object as `bar',
     and the result of calling `bar' is an infinite, recursive loop
     which finally leads to an error.

     To undo an alias, simply call `rm' on the aliased name.  The object
     itself is not destroyed until there are no more aliases.


        Werner