Re: Issue: STREAM-CAPABILITIES (Version 1)

[Dan L. Pierson <pierson@mist>]

A long delayed reply, now that Moon woke me up.

    Yes, its not so much the necessity of STREAM-SAME-xxx-P as it is the
    likelihood of them being correctly implementable for any of the likely
    operating systems, especially in the presence of network file systems,
    pipes, streams, indirects, redirects, etc.
    
Would it help if the functions returned the cannonical two values:
 T   T	    means Yes
 Nil T	    means No
 ?   Nil    means can't find out or not sure

It would be legitimate for an implementation to always return {Nil, Nil}
if either stream led to a network file.  However some network file
systems (and some implementations) might be able to answer the question
accurately in all cases.

    I think adding something that cannot be correctly implemented will
    lead to more rather than less portable code.
    
I don't think this is what you meant to say.

    Dans reasoning "Pierson supports STREAM-CAPABILITIES:NEW-PREDICATES
    because he is concerned that it may be hard for implementations to
    provide the list functions efficiently because the natural token type
    for multiple, disjoint types of streams may be integers.  The
    implementation would have to coerce these integers in to some other
    type of token that would be guaranteed unique across all possible
    stream types."
    
    doesn't follow from the proposal, does it? Some streams could have
    integers as tokens (are you thinking of their inode number or
    something?), and others not.
    
Well, I tried to explain this in more detail and ended up convincing
myself that I was wrong so please consider the objection withdrawn.

Would a new draft based on LIST-FUNCTIONS be useful?

Does this *have* to be broken up into two issues?