Here is how I see this from Swift's point of view (may be impractical in terms of implementation):<div><br></div><div>Swift provides a type called "stream" with the following properties:</div><div><ol><li>Fixed size: solves the garbage collection and resource over-allocation issues</li>
<li>Always open: Fixes the contradiction with "future" variables policy</li><li>Lossy: Things get overwritten as they arrive</li></ol></div><div>which means that Swift allocates a *fixed* amount of memory to a named-buffer mapped to a variable of type stream.</div>
<div><br></div><div>Swift implements read and write primitives on streams. Write overwrites on the stream and read returns what is current in the stream. Swift does not hang when stream types are open.</div><div><br></div>
<div>Agreed this would be a 'lossy' implementation but could suite many types of applications where each bit of input data is not important, just the ones that were captured on best effort basis.</div><div><br></div>
<div><br></div><div>Meanwhile, as Mike suggested, it is a good idea to play with SwiftR which I am about to do.</div><div><br></div><div>Regards,</div><div>Ketan</div><div><br></div><div>On Wed, May 2, 2012 at 1:54 PM, Ben Clifford <span dir="ltr"><<a href="mailto:benc@hawaga.org.uk" target="_blank">benc@hawaga.org.uk</a>></span> wrote:</div>
<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><begin functional programming ramble - you can tune out now as this is all kinda pie in the sky><br>

<br>
Relevant (at a language design level) to the problem of arrays getting almost-infinitely big and how to garbage collect.<br>
<br>
When you write:<br>
<br>
output = map f input<br>
<br>
then f is applied element at a time.<br>
<br>
The code in f doesn't do the indexing into 'input' or 'output' itself - instead the language handles that inside 'map'.<br>
<br>
What makes that interesting in this case is that you can change input/output to be something that isn't an indexable array - a "stream", for example.<br>
<br>
So the function f can only ever deal with the 'current position' in the stream - it can't go off trying to access either the future or the past.<br>
<br>
Which means, then, that the runtime system can assume more about how data will be used, and what it can forget about - once "now" has been processed completely, then the runtime can forget about "now".<br>

<br>
The application code can't go back and refer to the past. But that's sort of the point...<br>
<br>
There are other things on top of this to allow bounded access to the past so that you can do things like compare to the previous timestep, but they are bounded so that the runtime can still make useful inferences about when data is no longer needed.<br>

<span class="HOEnZb"><font color="#888888"><br>
--<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><font face="'courier new', monospace">Ketan</font><br><br><br>
</div>