1. My comment has nothing to do with any of the other procedures in the
exception handling library. My problem is not with these predicates, but
with the library that they are located. Are there any other examples of
api in the base library for features that have been manifestly declared
optional according to Section 1.3.1?
2. These 2 procedures did not exist in the sixth draft. They are new in
the seventh draft. There has been no opportunity for the public to
comment on the new api and syntax created between these 2 drafts. As you
say yourself, "non-trivial changes now will be unfair to people
currently reviewing the draft under the assumption that it is almost
final", well how unfair do you believe it is that the public has had no
opportunity to have input on these "non-trivial changes". The WG should
provide the public at least 1 opportunity to discuss these novel
features before they become finalized.
Arthur
On 11/13/12 9:32 PM, Alex Shinn wrote:
On Wed, Nov 14, 2012 at 8:17 AM, Arthur Smyles <[email protected]
<mailto:[email protected]>> wrote:
Well, it's not like the spec is written in stone (yet). I've
thought of
the stub idea, but I believe that it is really ugly and unnecessary.
Since there is no change to the semantics, couldn't the WG have some
remedy (perhaps unanimous consent) to fix this issue before the
standard
is fully petrified?
Since all other exception handling and introspection is
in base, and you want to be able to detect these even
if not using file/read yourself, I'm not sure this move
would even be desirable. We would need to vote on it.
The spec is indeed not written in stone yet, but we
need to stop at some point, and further non-trivial changes
now will be unfair to people currently reviewing the draft
under the assumption that it is almost final. It's
likely the people who think this would be a horrible
change wouldn't speak up until after the 8th draft was
published :)
--
Alex
Arthur
On 11/13/12 6:00 PM, John Cowan wrote:
> Arthur Smyles scripsit:
>
>> Both read-error? and file-error? are currently part of (scheme
>> base). Since both the read procedure and file procedures are in
>> separate libraries and are optional, it does not make sense to make
>> these 2 procedures required. I propose that read-error? be part
of the
>> (scheme read) library, and that file-error? be part of the (scheme
>> file) library.
> That is an *excellent* idea, and I only wish we had thought of it.
> Unfortunately, I have to say that it just comes too late in the
process.
>
> Fortunately, implementations that don't have the read and file
libraries
> can easily use these stubs:
>
> (define (read-error? x) #f)
> (define (file-error? x) #f)
>
_______________________________________________
Scheme-reports mailing list
[email protected]
<mailto:[email protected]>
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
_______________________________________________
Scheme-reports mailing list
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
