Draft of Red Edition document
37 views
Skip to first unread message
Vincent Manis
Feb 11, 2020, 6:28:05 PM2/11/20
to srfi-d...@srfi.schemers.org, scheme-re...@googlegroups.com
I have been working on a formal R7RS-Large Red document, which is
intended to be a precise specification of the libraries included in
the Red Edition. I have taken the various SRFIs, converted them to
LaTeX, and am in the process of trying to make everything consistent.
For the reason stated in the first bullet point below, I am not
posting the draft just yet, but if we can get the copyright issue
resolved, I would hope to have a draft up soon for comment. However,
there are a number of unresolved issues that I'd like comment
on. Addressing all these issues will take time, but I wanted to get
people thinking about them.
* UNRESOLVED: the original SRFIs each contain a copyright notice of
the form “Copyright © 20xx, YYY. All rights reserved.” This notice
technically makes the distribution of this document illegal!
Ideally, I believe that R$^7$RS-Large should be placed essentially
in the public domain, as was R$^7$RS-Small (which makes the
statement “We intend this report to belong to the entire Scheme
community, and so we grant permission to copy it in whole or in
part without fee.”)
- We need to get written permission of the SRFI authors to use
their work in this way.
- Future SRFIs intended for incorporation into R7RS-Large
should probably bear a different copyright (or permission
notice).
- I intend to move all the copyright notices from the SRFIs
onto a copyright page at the beginning. The existing copyright
notice (found in all the SRFIs) seems to be about “Software”,
and thus might not be relevant to this Report.
IANAL, so there may be other copyright issues I don't know about.
* UNRESOLVED: I have only removed the administrivia (SRFI
status) and local tables of contents, and have left the Rationales
unchanged. In some cases, there is material that belongs here
(e.g., the definition of “linear update” from SRFI~1), but much of
the Rationale material is about why things are done a certain
way. Nothing like that appears in R7RS-Small, so I'm not sure
it's a good idea to include it here. Possible courses of action:
- delete it all, with the exception of material needed for
understanding the specifications, and refer readers to the
original SRFI.
- delete it all, with the above exception, and extract the
remainder to a separate Rationale document (as was done with
R$^6$RS).
- retain it, perhaps with some editorial compression.
I'm pretty neutral on these alternatives, but would note my
preferences for clarity and concision.
* UNRESOLVED: Some of the SRFIs contain “Procedure Indexes”. I have
commented these out (though left them in the LaTeX source); we can
decide whether just to leave them out or to reformat/replace them,
or perhaps use a mini-TOC or an overview paragraph in each
section.
* UNRESOLVED: there is wide inconsistency in the notation of
individual entries, in particular in type signatures. Some
sections use the conventions of the Scheme reports in using
specific kinds of names for specific types, while others use a
notation reminiscent of ML/Haskell type signatures. Presumably, we
should use a consistent notation, but what should that be? Also,
authors of future SRFIs should be encouraged to use the same
signature notation.
* UNRESOLVED: The SRFIs have “Issues” sections, many of which
are empty. Any remaining issues should be addressed in the body of
the specification, and the Issues sections themselves removed.
* UNRESOLVED Should the Implementation sections be removed, or
extracted to
a separate document?
* UNRESOLVED: What about References and Bibliography? Preserve?
Remove? Bibliography at end?
* UNRESOLVED: Do we want to publish the final report in the “ALGOL
60” format used in R7RS? I'm OK with that, but I'd probably
arrange to do that after fixing everything else. (Argument for:
consistency with the Scheme reports, argument against: this report
doesn't really have much to do with ALGOL 60.) Some type signature
notations would really be difficult in a two-column format, so the
two decisions aren't independent.
-- vincent
intended to be a precise specification of the libraries included in
the Red Edition. I have taken the various SRFIs, converted them to
LaTeX, and am in the process of trying to make everything consistent.
For the reason stated in the first bullet point below, I am not
posting the draft just yet, but if we can get the copyright issue
resolved, I would hope to have a draft up soon for comment. However,
there are a number of unresolved issues that I'd like comment
on. Addressing all these issues will take time, but I wanted to get
people thinking about them.
* UNRESOLVED: the original SRFIs each contain a copyright notice of
the form “Copyright © 20xx, YYY. All rights reserved.” This notice
technically makes the distribution of this document illegal!
Ideally, I believe that R$^7$RS-Large should be placed essentially
in the public domain, as was R$^7$RS-Small (which makes the
statement “We intend this report to belong to the entire Scheme
community, and so we grant permission to copy it in whole or in
part without fee.”)
- We need to get written permission of the SRFI authors to use
their work in this way.
- Future SRFIs intended for incorporation into R7RS-Large
should probably bear a different copyright (or permission
notice).
- I intend to move all the copyright notices from the SRFIs
onto a copyright page at the beginning. The existing copyright
notice (found in all the SRFIs) seems to be about “Software”,
and thus might not be relevant to this Report.
IANAL, so there may be other copyright issues I don't know about.
* UNRESOLVED: I have only removed the administrivia (SRFI
status) and local tables of contents, and have left the Rationales
unchanged. In some cases, there is material that belongs here
(e.g., the definition of “linear update” from SRFI~1), but much of
the Rationale material is about why things are done a certain
way. Nothing like that appears in R7RS-Small, so I'm not sure
it's a good idea to include it here. Possible courses of action:
- delete it all, with the exception of material needed for
understanding the specifications, and refer readers to the
original SRFI.
- delete it all, with the above exception, and extract the
remainder to a separate Rationale document (as was done with
R$^6$RS).
- retain it, perhaps with some editorial compression.
I'm pretty neutral on these alternatives, but would note my
preferences for clarity and concision.
* UNRESOLVED: Some of the SRFIs contain “Procedure Indexes”. I have
commented these out (though left them in the LaTeX source); we can
decide whether just to leave them out or to reformat/replace them,
or perhaps use a mini-TOC or an overview paragraph in each
section.
* UNRESOLVED: there is wide inconsistency in the notation of
individual entries, in particular in type signatures. Some
sections use the conventions of the Scheme reports in using
specific kinds of names for specific types, while others use a
notation reminiscent of ML/Haskell type signatures. Presumably, we
should use a consistent notation, but what should that be? Also,
authors of future SRFIs should be encouraged to use the same
signature notation.
* UNRESOLVED: The SRFIs have “Issues” sections, many of which
are empty. Any remaining issues should be addressed in the body of
the specification, and the Issues sections themselves removed.
* UNRESOLVED Should the Implementation sections be removed, or
extracted to
a separate document?
* UNRESOLVED: What about References and Bibliography? Preserve?
Remove? Bibliography at end?
* UNRESOLVED: Do we want to publish the final report in the “ALGOL
60” format used in R7RS? I'm OK with that, but I'd probably
arrange to do that after fixing everything else. (Argument for:
consistency with the Scheme reports, argument against: this report
doesn't really have much to do with ALGOL 60.) Some type signature
notations would really be difficult in a two-column format, so the
two decisions aren't independent.
-- vincent
John Cowan
Feb 11, 2020, 7:58:43 PM2/11/20
to scheme-re...@googlegroups.com, srfi-d...@srfi.schemers.org
Don't worry about "All Rights Reserved"; it is 100% noise and does not override the explicit SRFI license. It used to be required to maintain international copyright, but now that essentially all countries have joined the Berne Copyright Convention, it can freely be left out.
--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/bc6d472f-e972-4da2-ac27-7762d561fc88%40telus.net.
Vincent Manis
Feb 11, 2020, 8:58:50 PM2/11/20
to srfi-d...@srfi.schemers.org, scheme-re...@googlegroups.com
Thanks, Arthur and John.
I will also the individual copyright notices to the same page, with the
note “This Report is based upon the following SRFIs.”
I had already put the three-paragraph notice on the copyright page of
the draft. I propose to add a sentence at the beginning that says “The
SRFIs on which this Report is based each bear the following notice.
(Software files are not distributed with this Report.)”.
I had misunderstood “All rights reserved.”.
With that, I regard the copyright issue as resolved, and therefore look
forward to comments on other issues.
-- vincent
I will also the individual copyright notices to the same page, with the
note “This Report is based upon the following SRFIs.”
I had already put the three-paragraph notice on the copyright page of
the draft. I propose to add a sentence at the beginning that says “The
SRFIs on which this Report is based each bear the following notice.
(Software files are not distributed with this Report.)”.
I had misunderstood “All rights reserved.”.
With that, I regard the copyright issue as resolved, and therefore look
forward to comments on other issues.
-- vincent
Vincent Manis
Feb 11, 2020, 9:00:09 PM2/11/20
to srfi-d...@srfi.schemers.org, scheme-re...@googlegroups.com
On 2020-02-11 5:58 p.m., Vincent Manis wrote:
> I will also the individual copyright notices to the same page, with
> the note “This Report is based upon the following SRFIs.”
I will MOVE the ..
> I will also the individual copyright notices to the same page, with
> the note “This Report is based upon the following SRFIs.”
John Cowan
Feb 14, 2020, 10:45:34 AM2/14/20
to srfi-d...@srfi.schemers.org, scheme-re...@googlegroups.com, Ciprian Dorin Craciun
+1
On Fri, Feb 14, 2020 at 10:44 AM Lassi Kortela <la...@lassi.io> wrote:
> I have been working on a formal R7RS-Large Red document, which is
> intended to be a precise specification of the libraries included in
> the Red Edition. I have taken the various SRFIs, converted them to
> LaTeX, and am in the process of trying to make everything consistent.
Thank you very much for this work.
There was a long discussion on the srfi-discuss list last year about
converting all of the SRFI documents into a common HTML structure. (We
chose to stick with HTML since that's what's always been used, and there
was no consensus on what other format would be favored.)
If you have some good ideas about what kind of HTML structure or markup
would make an aggregation project such as yours easier, they would be
very useful.
> * UNRESOLVED: the original SRFIs each contain a copyright notice of
> the form “Copyright © 20xx, YYY. All rights reserved.”
As the others said, don't worry. Both the letter and the spirit of the
MIT license encourage unlimited distribution with or without modifications.
According to the license, you do have to include its full text (the 3
paragraphs) at the end of your document. What to do about the "Copyright
(c) <person> <year>" lines is a good question. You can probably collect
them all and stack them above the 3 paragraphs:
Copyright © Person A (year A)
Copyright © Person B (year B)
Copyright © Person C (year C)
Copyright © Person D (year D)
Permission is hereby granted, etc...
Reply all
Reply to author
Forward
0 new messages