RE: List container strawman 1.2

["Steven Deller" <deller@smsail.com>]

> After sleeping on this issue, here are my current thoughts. A 
> safe active iterator would probably be *logicaly* more 
> appropriate to this package, while a faster unsafe "Index" 
> would be more appropriate for Containers.Bounded.Lists. 
> However, as coded, that would completely destroy the ability 
> to use this package in real-time systems. Currently any use 
> of an active iterator (eg: First, Next), creates a new 
> iterator, which would force dynamic allocation of a new 
> iterator node on the List's iterator list. 
Ted,

I don't believe this conclusion follows.  I would think the Index type
could have suitable links to allow it to be "associated" with a list
(probably want it to be limited private).  There would also have to be
handling when the object goes out of scope, to prevent dangling
references, but that should be possible using controlled types.

>In many (most?) real-time systems start-up heap allocations 
> are OK, but runtime heap operations are verboten. Again, for 
> those unfamiliar with the issues, speed isn't necessarily the 
> problem (although that may well be too). Its an issue of 
> time-determinism. There's just no way to tell up front how 
> long a heap op is going to take. It may be quite quick on 
> average, but if we miss a deadline once, the whole system is hosed.
> 
> This issue could be mostly fixed by changing the 
> iterator-returning functions into procedures. However there 
> is another issue, which is that our theoretical 
> Containers.Lists.Bounded *cannot* use this method (well...I 
> guess it could if we limited the number of allowable 
> iterators per List). Obviously the packages will need to have 
> some differences, but having different iterator/location 
> methods seems a smidge on the extreme side.

Same method works for bounded as well.  The iterators are "bounded" only
by the number of objects created by the user.

Regards,
Steve
deller@smsail.com
Smooth Sailing LLC