On Feb 4, 6:55 am, Frantisek Sodomka <fsodo...@gmail.com> wrote:
> Streams were also intended for I/O. Is lazier addition also able to
> cope with I/O successfully?
Yes. After full laziness, most of the issues with I/O have to deal
with resource management, which I plan to deal with a la carte with
the scope construct.
> Can we have both - streams and lazy-seq?
>
I'm not sure we'll have either. I've been working on streams, fully-
lazy sequences and left fold enumerators in an effort to resolve what,
if any, breaking changes would be required to address the problems
they solve:
1) Resource management in lazy contexts
2) Memory consumption in recursive lazy contexts (the filter retains
skipped range issue)
3) Full laziness in I/O and other side-effect contexts, and for ease
of understanding
4) Performance/elegance
1 - As I said, the resource management is orthogonal and solved with
scope.
2 - I can probably back-port the 'clear closed-overs on tail call' in
once-only closures to the current lazy-cons model.
3 - I thought the demand for full laziness was greater than it
apparently is, given the lack of feedback on these features.
4 - Right now there is a plain tradeoff of elegance for performance,
and I'm not satisfied with that.
> My thought about streams is that if they get included, they could be
> looked at as unsafe operations in Java/C# or unchecked math operations
> - as long as programmer knows what he is doing, it is fine...
>
While unsafe math ops live in the bowels of tight loops, streams are
interface points. That's why the API I've come up with for them is
safe.
Rich
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
