I just posted a very scratchy initial RFI at:

http://selmer.warwick.ac.uk/RFI-1.pdf

The tex file for this is here:

http://selmer.warwick.ac.uk/RFI-1.tex

It took me just on an hour to write.

I think these sorts of things only become useful if they are collated
centrally somewhere, e.g. on the project website, if they are kept
up-to-date by the proposer(s) and if developers are actively
encouraged to comment on them.

The SRFI's seem to be widely implemented by Scheme
compilers/interpreters, so they seem to have been on-the-whole
successful:

http://srfi.schemers.org/srfi-implementers.html

Scheme R6RS on the other hand has not been completely successful. The
Scheme community had a big split over whether the language should be
very minimal and elegant, or whether it should be "batteries
included".

I understand that the Scheme steering committee proposed last year to
split the language into two: a minimal core language for the purists
and a very large modern language like Common Lisp.

I haven't looked into whether the SRFI's contributed to this. My
impression is these are separate issues because even Schemes written
by purists seem to implement many of the SRFI's. Of course there
aren't many Sage's yet, etc., so maybe this isn't of great concern
just yet.

Bill.

On 2 November 2010 03:07, William Stein <[email protected]> wrote:
> Hi,
>
> Bill Hart posted this to the flint and bsdnt lists, and it's also
> relevant to sage-devel, since though we have "SEP's" = Sage
> Enhancement Proposals, we rarely use them.  Maybe we should use them
> much more and make things much more systematic.   For example, it
> would make a lot of sense to have a SEP about making a "library
> version of Sage".
>
> ---------- Forwarded message ----------
> From: Bill Hart <[email protected]>
> Date: Mon, Nov 1, 2010 at 6:30 PM
> Subject: [bsdnt-devel] White papers
> To: flint-devel <[email protected]>, [email protected]
>
>
> Hi all,
>
> I'm writing to flint-devel and bsdnt-devel as the issues are relevant
> to both projects. Apologies for any duplication.
>
> I'm becoming convinced that eventually we'll need to have some form of
> "Enhancement Proposal" system for flint and bsdnt.
>
> For an example of what this is, take a look at the Scheme Requests for
> Implementation (SRFI), e.g:
>
> http://srfi.schemers.org/srfi-4/srfi-4.html
>
> Many large projects have such a system, including the Linux kernel,
> Python, and many others. In fact, I would argue that they become
> important to any sufficiently serious project.
>
> Even for small projects, they can serve a use (when used judiciously):
>
> * They provide information to potential developers about what major
> features are currently being worked on.
>
> * They expose major new functionality to careful scrutiny and comments
> by experts before the proposed feature becomes part of the project.
>
> * The can serve to attract new developers who want to work in a team
> to implement various proposals they get excited about.
>
> * They serve to identify the developers working on any given component
> under active development, when they started, what progress has been
> made and where they are going with it.
>
> Secret development projects always have to exist for various reasons,
> but sometimes it is better to have a small number of RFI's as well for
> more public projects/modules.
>
> I definitely don't want to get bogged in bureaucracy, but it might be
> fun to write these things some times. For example, someone just
> requested a module for polynomials mod large moduli on flint-devel. As
> it happens, such a module has been under development for a while. But
> this would ordinarily present a great opportunity to write a short
> (say 2 page) white paper describing how such a module should work,
> what functionality it would implement, what algorithms will be used,
> and invite comment from the original requester.
>
> I think these RFI's should be limited to the level of full modules or
> very large subprojects only in bsdnt and flint2.
>
> In bsdnt we might have RFI's already for:
>
> * A high level memory managed module for integer arithmetic (fmpz or
> something equivalent)
> * A module for low level multiprecision floating point arithmetic
> * Factorisation of integers??
>
> all of which have been requested.
>
> For flint2 we might have RFI's for:
>
> * Matrices over Z/pZ for small p
> * Matrices over Z/nZ for large n
> * Some other things that have been suggested lately
>
> all of which are currently under development.
>
> I would envision the main developer who is going to work on said
> module would write the RFI doc and keep it up-to-date in keeping with
> comments made on the devel list in response. I don't think there is
> any point in writing RFI's for modules we already have well under way,
> and of which there is plenty of discussion going on already. This
> would be for future things.
>
> How do people feel about RFI's? Do you see value in them? Would you
> personally write them and maintain them if you were excited about
> working on a new module? It almost seems to happen anyway on our devel
> lists, but in a haphazard sort of way which is difficult for potential
> users/contributors to keep track of. But I'm interested to know how
> current developers would feel about writing these. Would it just put
> you off?
>
> Bill.
>
>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
>

-- 
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to