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 "m...@push", you'll see the other ones near that point. I figured to preface all of my variables with "mm-html".
