Frank J. Lhota wrote:
"Steve Wampler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Hi Frank,
I finally got time to read your entire original post. I think your analysis of the situation is spot on, and a good explanation of the 'memory-leak' that can arise from co-expressions.
Although I commented on the variable() function, it's my
general feeling that its ability to access 'hidden' dynamic
variables from within a co-expression is entirely an
artifact of how co-expressions are currently implemented
and *not* a language feature. There is no requirement
that such access must exist, and I'd be willing to bet that
no one has every made use of this feature from within
a co-expression [and they shouldn't, since it's solely
an implementation artifact!].
On several occasions I've encountered what looked like memory problems with co-expressions. It's very frustrating when this happens and its not at all obvious.
Firstly, I agree that the ability to get at hidden information is a implementation artifact with punishing side-effects. Good analysis. I think the cost of this artifact is simply too high for most folks. Any discussion of whether this capability *might* be desirable is another issue and one that would probably need to seriously consider including ways to explicitly clean up. Either way you cut it the current implementation is broken/flawed here. Either it shouldn't tramp around the hidden baggage or there should be a way to clean up. Pick your poison.
Secondly, there is another concern where folks working with the language can reasonably expect certain behavior.
As an example, a (pre-Unicon) program I wrote provided a framework for easily simulating many different electromechanical cipher machines (enigma, purple, typex, sigaba, etc.). It used map heavily and also made use of co-expressions to implement "components". The first version of it suffered from severe memory problems. It easily overflowed the garbage collection counter on simple tests (Ralph Griswold even described this behavior as "impressive" which I took to mean pathological).
There were two problems and neither would be particularly obvious to someone not deeply involved in the language.
(1) Repeatedly concatenating a single character generated from applying map many times in succession abused the string area horribly. The procedure map(s1,s2,s3) does not try to optimize string storage by returning a substring in the case where s1 is a single character. I solved this either by adding an rtl procedure that mapped a single character as a substring or used lists to defer concatenation. The general problem and solution by deferal was described in a very useful (prior to 1995) Icon Analyst/Newsletter article.
(2) The program also experienced unexplained "collections" of the "co-expression area" and apparent memory leaks. (I may have bits of this wrong as I'm doing this from memory. ) Some tinkering with the co-expressions and encapsulating them in very small procedures that simply returned a created expression helped immensely. The keyword &collections generates values for garbage collection for the string and block regions along with another number that had been documented as being associated with co-expressions. After several exchanges on the Icon list and offline I came to understand that the numbers reported for the co-expression region are phantoms and an artifact of a change in the implementation at some point previoulsy. The question of what was being counted was left as an unanswered curiosity.
The first case was a surprise became quickly appearent and I think most people would consider it resonable behavior. The second is far more obscure, tricky and I think most people would consider unreasonable behavior.
There is probably other examples of odd or unexpected memory behavior, but I can't think of any more now.
David Gamey
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
