Alex Shinn <xxxxxx@gmail.com> writes:

> On 8/25/05, Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> wrote:
>>
>> I don't understand why it would be a lot of work---that's what the
>> reference implementation is for.  Just drop it in.  You mainly have to
>> adapt the primitive I/O layer, which is usually pretty simple.  (You
>> could even build it easily on a pre-existing ports layer.)
>
> You also have to rewrite your existing ports layer to distinguish
> between the original native ports and the new stream-based ports.

That doesn't seem to be a lot of work.

> There's also still a lot missing from SRFI-68 since it doesn't provide
> more than some trivial transcoders, and in cases like C's wchar
> implementation there is no direct way to transcode wstrings - you
> have to use an external library like iconv.

Sure---but you were asking about the effort it takes to add SRFI 68 to
an existing ports system.  Presumably, you would already have the
transcoding machinery you need.  If more people would contribute
portable code for more transcoders, so much the better.

>> The bottom two layers are there because they're useful.  If all layers
>> are required, portable code could use whatever layer it wants to.  I
>> don't see why the lower layers (especially the primitive layer) would
>> necessarily be extremely slow---maybe you can elaborate why you think
>> this is the case?
>
> If you aren't using a systems-level language (or don't want to go through
> the effort), then you have to base the lower-levels on an existing upper
> level, which implies all text gets buffered twice.

Well, sure, if you don't want to go to the effort, almost anything can
be slow.  Sorry, but this kind of argument doesn't cut it with me.

Moreover, if you really want high performance, no ports layer of the
kind described in the SRFI will do the job at all---only the primitive
I/O can.

> I also have concerns about the stream-layer in general.  I really like
> the idea of being able to treat a port like a list (although given the
> choice I'd rather work with car and cdr than car+cdr).  However, it
> requires either large amounts of buffering

That depends on what you mean by "large amounts."  You do get lots of
transient allocation, which advanced GC's deal with very well.

> If the record is the last element of a 10GB file we would need
> 10GB of memory to do this.  A smart compiler and gc could
> determine the older streams aren't re-used and reclaim them
> in this case, but what if they were re-used?  Or what if they
> aren't but the compiler can't prove it?

Then you're out of luck, as with any continual allocation.  Thank
goodness we have proper tail recursion.

> Likewise we need SET-PORT-POSITION!.

That's true.  I never considered it because it isn't in the SML Basis.
I'll see what I can do for the next revision.

> Another issue is that buffering doesn't account for mutations
> performed between reads, so libraries like C provide explicit
> buffering controls, including non-buffering.

Can you show me how the C library does it?  I can't find it offhand.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla