Follow-up Comment #6, bug #60954 (project groff): [comment #5 comment #5:] > I suppose the overarching question is how much time to devote to a difficult problem the solution of which serves only to appease a sense of orthogonality rather than solve a real-world problem.
A fair point, but this is not nearly the most difficult problem in the groff bug list. :) When I comment on tickets it is often to record information to help spin myself (or another contributor) up on the underlying issue at some undetermined future date. Chatting to the ticket is often, but not always, a sign that I'm trying to do something about it for my next push. (Because I am a rat who wants to mash the endorphin-release button with a minimum of effort in a now-discredited study[1], when I comment on a ticket while passing over it, it is often to record the particulars of the difficulty I encountered before moving on to the next, easier, thing.) > If you decide to allow deletion of active environments (and I agree that the simplest solution is to disallow it, as it wouldn't even have helped with the problem Werner thought he needed to solve back in '06), it shouldn't require any pointer manipulation upon the delete itself: it's only upon popping back to the now-nonexistent environment that some evasive action need be taken. I think that's the problem. We don't know where to go in our evasion if we traverse into a deleted node. In a horrible implementation, we'd follow a pointer to deallocated storage; in a less-bad one, we'd see a null pointer marking the node's deleted status, but have no way to locate the node that the deleted node pointed to (and if _that_ node had also been deleted, we'd _still_ have a problem, hence my musing about sequences of deleted nodes). I was, however, I think, incorrect about multiple arguments to this notional `evrm` request being a problem; it would simply process them serially and no extra complications should arise. My career has gotten me more and more preoccupied with concurrency problems, and I sometimes forget that a *roff formatter is a comparatively simple machine. > (There's no requirement that the stack be empty upon program exit, One of the things that bothers me about the current implementation; is that the stack can ever be empty at all. In documenting it for the manual I wrote as if the current environment is the stack top even if there is nothing below. As _implemented_, that isn't really true; there's a current environment and if environments beyond the initial one are ever created, the pointer `env_stack` never becomes non-null. This grates on me, but I admit it's pretty much a philosophical complaint. > so a user might delete an active environment knowing full well that they'll never pop back to it.) Right. If they're not crazy, those two notions should be coupled. :) > Deleting the _current_ environment raises thornier questions and I presume would be disallowed in any case. Agreed. I _want_ to think in terms of a chain of biconditionals. There is always a current environment. <=> There is always an environment stack. <=> The current environment is always at the top of the stack. ...but when we get down to C++ data types, that's just not how James Clark wrote it. It works _as if_ these were the case, but they're not. Thus my Nolanesque adventure in bug #62036. Another thing I wanted was a simplified version of `pev` that lists _only_ the environment names in the stack, in order. The present implementation (1) lists them in dictionary order, which is useless for all practical purposes and (2) sprays dozens of lines of output detailing each environment's state to the terminal, which is great if you need to debug environment _contents_, but bewildering if all you needed to know was whether you'd screwed up the stack arrangement--as (1) notes, it can't tell you that except in trivial cases anyway. Regards, Branden [1] https://en.wikipedia.org/wiki/Rat_Park _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?60954> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
