Proper file IO in HASCAL

I was writing some text file processing in Pythong using generators, you know, the usual stuff, lazily read lines, parse each line, lazily perform some grouping, etc. Then I realized that I have a problem, two requirements that don't play well with each other:

1. On one hand, I want to process lines lazily so that at any point I use just as much memory as I need to process one line or one group of lines. I don't want to intentionally or accidentally get the entire file (or any intermediate dataset) entirely into memory.

2. On the other hand, I want to deterministically close the file after I'm done reading it.

As a result I should be careful to force all my lazy stuff before I return from with open(fname, 'r') as f: .... And it's really not obvious that something is wrong with the code that doesn't do that (apart from getting "I/O operation on closed file" at runtime, of course).

How does HASCAL master race solve this problem that looms even more menacingly for them, with laziness being the default and pervasive? Or, as quick googling makes it seem, they don't stoop to such pleb things as reading files efficiently and closing them at the right time?

Haskell type system doesn't ensure proper resource disposal. Idris effects system does, though.

h
p
i

all shit
use L or C

>>3
C is useless, though.

>>1
This is a problem Haskell people used to talk about a lot, and then they developed something called "iteratees" (like inside-out iterators) so they could do lazy streaming and still properly close the file as soon as it's been read. I think there was also something else that came after that, but I don't remember what it was called.

>>5
Pipes and conduit.

>>5,6 Interesting, thanks. How does it relate to FRP (which is truly iterators turned inside-out)? It seems to me that it's not identical, because we still compose Iteratees in the usual order and only then drive them with an push-based Enumerator. I could be completely wrong, I didn't understand how that stuff works, it's pretty complicated.

Also lold at http://hackage.haskell.org/package/pipes-4.1.4/docs/doc-index.html, it implements the following operators:
+>>
//<
//>
/</
/>/
<+<
<-<
<<+
<\\
<~
<~<
>+>
>->
>>~
>\\
>~
>~>
\<\
\>\
~<
~<<
~>

OP, you need the Frames:

So with Pipes, we can neither write folds, nor can we finalize resources deterministically. Fortunately, there is a solution: Frames. Check out Control.Frame.Tutorial for an introduction to a type that enriches Pipes with the ability to fold and finalize resources correctly.

http://hackage.haskell.org/package/pipes-2.1.0/docs/Control-Frame-Tutorial.html

>>4
C is very useful... if you don't have to write it by hand.

>>7
Here's a language that could benefit from more symbols yet they have to masturbate to ASCII.

>>10
What's wrong with masturbating to ASCII?