[R6RS] end game---getting really close

[dyb at cs.indiana.edu]

> - Ticket #45 just contains a bunch of "should"s.  Does that mean I make
>   those changes?  I'm assuming yes.

Yes.  I think we should include a rationale saying that its return value
is unspecified (rather than the unspecified value) to allow
implementations to use a tail call for the last call to the procedure.

> - Where do the sorting procedures go?  I'm assuming a separate library
>   (r6rs sorting)?

Sounds good to me.

> - Where do `file-exists?' and `delete-file' go?  I'm assuming a
>   separate library (r6rs files)?

Sounds good to me.

> - What are we going to call the bytes objects?  This should be a
>   simple matter of making a list of candidates and voting on the
>   favorite, right?

Yes.  Let's hear some nominations.  Here are some to get things started:

  bvector
  bstring
  bector
  bytevector
  bytevec
  bytestring
  bvec
  blob
  bob
  bitvector
  bitvec

> - What can I do wrt. Ticket #87?  It has six specific examples.
>   Presumably "library phasing" and "script syntax" will be taken care
>   of as a result of addressing other tickets.

We explicitly punted on any specifics wrt Ticket 87, so we're going to
have to deal with that.  Thanks for the reminder.

>   o Can I make the suggested change wrt. immutable objects?

I assume you mean these as described in Ticket #87:

    Fixing the problem is easy. The R6RS should give an
    implementation-independent definition of immutable objects, as the
    objects that result from evaluation of a literal constant together
    with the strings returned by symbol->string (and perhaps a few other
    objects). The R6RS should say that correct programs do not try to
    mutate immutable objects, and that implementations should (not "must")
    raise an exception when mutation of an immutable object is attempted.

I believe that this is essentially what we voted for; see Item 3 in
adendum.20060517 (sic) in the repository minutes directory.  So yes, I
believe that you can make this change.

>   o Did you discuss on how to resolve the unspecified-value issue?
>     Re-start community discussion?

We did not resolve the unspecified-value issue.  At this point, I think
the unspecified value remains unless someone makes a motion to the
contracry and we vote for its removal.  I think it's reasonable to specify
that write and put-datum are not permitted to use a representation that
coincides with any other datum, but again we probably need a motion for
that.  (I so move, in fact.  Is there a second?)  We can also agree not to
use the unspecified value on a case-by-case basis, as we have for
for-each.

>   o Can I make changes along the lines of what I posted?

I think we can treat your note as a motion and Will's response as a
second, so all that's left is to vote.  I vote yes.  Will?  Matthew?
Mike?  Anton?

> - Somebody else will need to write up the new I/O proposal.  I'm all
>   out of those.

Can we have a volunteer?  Will perhaps?

> - Kent: What's the story with a more formal description of macro
>   expansion?

I believe that the algebra we had intended to use overspecifies the
algorithm in the sense that it precludes Andre's shallow binding
implementation, which, is in some ways superior because it obviates the
antimark.  I'm not sure how to address this---perhaps for now saying only
that the algebra in Oscar's thesis is one possible semantics.

> - Kent, Matthew: Can you guys also (in addition to the phasing stuff)
>   make the changes to the description of the expansion algorithm
>   mentioned in the responses?

Yes.

> - Please read the conditions proposal here:
>
> http://lists.r6rs.org/pipermail/r6rs-discuss/2006-November/001181.html
>
>   and either agree to it or poke holes in it or suggest alternatives.

Okay.  Will, I'd like to know if Mike's response to your concern is
adequate.  I can dig up message numbers if you need them.

Kent