Re: [Groff] groff data structures

[Chuck Robey]

Werner LEMBERG wrote:
>> I need to have (for an html project of mine, which you all know
>> about by now) a stack data structure.  I know one *really* klugy way
>> to do it, by having a number register which counts the depth of my
>> stack, and then having a variable which is concatenated to form a
>> name like "name0", "name1", etc, so I can automatically reference
>> the top variable when I want.
> 
> Well, I don't consider this solution `cludgy' at all.  If you have
> arguments which contain arbitrary characters, including spaces, this
> is the only way to go, AFAIK.  Have a look at the mdoc package which
> uses this all the time.
> 
> 
>     Werner

I want to reply to both of your mails here in one mail.  First, constructing the
variable names piece by piece and maintaining multiple variables to simulate
arrays does seem to me to be kludgy.  (Since that word, kludgy, is itself a bit
of a kludge, I don't believe in the existence of a standard spelling, in any
language, no matter what the dictionary makers say, so your 'cludgy' is fine
with me).  I got a reply from Tadziu Hoffman who gave me an idea of making a
real stack, and when I looked very hard at the mm code, hidden insise there were
both string and number versions of a stack.  I think I'll experiment to make
sure they work, then use them.  However, I really do understand that the groff
language is no competitor of C, and I don't want my prejudices regarding code to
stand as any sort of criticism of your code.  In a language like groff, anything
that works is beautiful.

OK, off to your 2nd email, saying roughly that you didn't think I should want to
use your www.tmac code to implement anything to fix the mm code, but you were
only too happy, anyways, to accept patches to the www.tmac code.  It left me a
bit confused ... I would *think* that a bit of extra code to the mm macros so
that they referenced your www.tmac in case of html output would be a good idea
(as long as the www.tmac code didn't any longer show the drawbacks I currently
see ... it's entirely possible I'm using the www.tmac code wrong (I couldn't
find any notes on macro usage for it) but it *seems* that while the html lists
themselves (written manually directly in html) work fine and embed multiple
levels great, the www.tmac form don't embed well at all.  I've made a set of
pseudocode replacements for all of the mm list macros (excepting LB), but these
assume that www.tmac doesn't exist.  So, they won't plug into www.tmac at all 
well.

I wouldn't mind changing things to do it, but the fixes are not exactly minor:
from what I can tell, the fact that there are only really 3 kinds of html lists
that match at all well to the mm list macros is one point, and the other being
that the html lists need to be explicitly and correctly closed, unlike the mm
list macros.  Because of this, for every list depth, I need to know the name of
the html list type being used, and if an item for that list type is currently
open.  This means 2 new stack variables (2 new stacks?)

I got the idea that you wanted me not to embroil you further, and I'm trying to
be a good boy here, in the hopes that if I find myself in a corner, unable to
advance, and if you havent' already been bothered to hell, you might still be
willing to help me out.  If I'm wrong, and you want me to keep you current in
what I'm doing, I'm only too happy to do that.  Currently, I'm slowly modifying
my pseudocode, line by line, into real groff code, and if you would like to see
my intermediate results, that's completely fine by me, just let me know, I'll
probably copy the list then also.  I KNOW I must have errors in it

My current task is to test out the mm macro stack setups, and see if they will
work for me, I have high hopes.  One name to grep for, if you're curious, is
"address@hidden", you'll see the other ones near that point.  I figured to 
preface
all of my variables with "mm-html".