[Swift-devel] Streams

[Ketan Maheshwari]

Here is how I see this from Swift's point of view (may be impractical in
terms of implementation):

Swift provides a type called "stream" with the following properties:

   1. Fixed size: solves the garbage collection and resource
   over-allocation issues
   2. Always open: Fixes the contradiction with "future" variables policy
   3. Lossy: Things get overwritten as they arrive

which means that Swift allocates a *fixed* amount of memory to a
named-buffer mapped to a variable of type stream.

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.

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.


Meanwhile, as Mike suggested, it is a good idea to play with SwiftR which I
am about to do.

Regards,
Ketan

On Wed, May 2, 2012 at 1:54 PM, Ben Clifford <benc at hawaga.org.uk> wrote:

> <begin functional programming ramble - you can tune out now as this is all
> kinda pie in the sky>
>
> Relevant (at a language design level) to the problem of arrays getting
> almost-infinitely big and how to garbage collect.
>
> When you write:
>
> output = map f input
>
> then f is applied element at a time.
>
> The code in f doesn't do the indexing into 'input' or 'output' itself -
> instead the language handles that inside 'map'.
>
> 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.
>
> 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.
>
> 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".
>
> The application code can't go back and refer to the past. But that's sort
> of the point...
>
> 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.
>
> --
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>



-- 
Ketan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20120502/5e9cd1a2/attachment.html>