Towards De-icing ice-9 modules.

Towards De-icing ice-9 modules.

[Chad Albers]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

Hi,

In my attempt to assist the guile project, I thought I would share a
document on a plan to migrate some of the ice-9 modules into a more
intuitive, yet to be decided, namespace.  Before I proposed a technological
plan, I have begun really an audit of what ice-9 modules are available (and
undocumented), and other modules that guile ships with. (there are some
secrets down there).

Here's the document so far:
https://docs.google.com/spreadsheets/d/1hHAz1xRPlH2K6w_olWE6qej3lL7i4-zKdYAV1xbYHO8/edit#gid=0

(I apologize that it's a google document.  I couldn't find a
comparable,free software online collaborative alternative.  suggestions are
welcome).

It is by no means final, and in some cases, inaccurate.  Let me know if I
should continue along this path.

--
Chad

[-- Attachment #2: Type: text/html, Size: 1051 bytes --]

Re: Towards De-icing ice-9 modules.

[Christopher Allan Webber]

Chad Albers writes:

> Hi,
>
> In my attempt to assist the guile project, I thought I would share a
> document on a plan to migrate some of the ice-9 modules into a more
> intuitive, yet to be decided, namespace.  Before I proposed a technological
> plan, I have begun really an audit of what ice-9 modules are available (and
> undocumented), and other modules that guile ships with. (there are some
> secrets down there).
>
> Here's the document so far:
> https://docs.google.com/spreadsheets/d/1hHAz1xRPlH2K6w_olWE6qej3lL7i4-zKdYAV1xbYHO8/edit#gid=0
>
> (I apologize that it's a google document.  I couldn't find a
> comparable,free software online collaborative alternative.  suggestions are
> welcome).

Try etherpad:
  https://public.etherpad-mozilla.org/

> It is by no means final, and in some cases, inaccurate.  Let me know if I
> should continue along this path.

Re: Towards De-icing ice-9 modules.

[Mark H Weaver]

Hi Chad,

Chad Albers <calbers@neomantic.com> writes:
> In my attempt to assist the guile project, I thought I would share a
> document on a plan to migrate some of the ice-9 modules into a more
> intuitive, yet to be decided, namespace. Before I proposed a
> technological plan, I have begun really an audit of what ice-9 modules
> are available (and undocumented), and other modules that guile ships
> with. (there are some secrets down there).
>
> Here's the document so far:
> https://docs.google.com/spreadsheets/d/1hHAz1xRPlH2K6w_olWE6qej3lL7i4-zKdYAV1xbYHO8/edit#gid=0

I would thank you for this, but I cannot even view it without running
nonfree software on my machine.  Posting this link essentially puts
pressure on those who wish to have a voice in this discussion to use
nonfree software, and excludes those who take a principled stand against
using nonfree software.  That's not good.

> (I apologize that it's a google document. I couldn't find a
> comparable,free software online collaborative alternative. suggestions
> are welcome).

We must not collaborate on a platform where using nonfree software is a
prerequisite for entry.

Can you please send it in email as plain text?

     Mark

Re: Towards De-icing ice-9 modules.

[Chad Albers]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On Fri, Feb 12, 2016 at 4:18 PM, Mark H Weaver <mhw@netris.org> wrote:

> I would thank you for this, but I cannot even view it without running
> nonfree software on my machine.  Posting this link essentially puts
> pressure on those who wish to have a voice in this discussion to use
> nonfree software, and excludes those who take a principled stand against
> using nonfree software.  That's not good.
>
> > (I apologize that it's a google document. I couldn't find a
> > comparable,free software online collaborative alternative. suggestions
> > are welcome).
>
> We must not collaborate on a platform where using nonfree software is a
> prerequisite for entry.
>
> Can you please send it in email as plain text?
>

I adamantly agree with your sentiments. The ideal solution in my opinion
would be a wikipage, so people could comment.  Does anyone have access to
one that we all could also read, without having to create a user-account
(bonus points)?

--
Chad Albers

[-- Attachment #2: Type: text/html, Size: 1472 bytes --]

Re: Towards De-icing ice-9 modules.

[Mark H Weaver]

Chad Albers <calbers@neomantic.com> writes:

> On Fri, Feb 12, 2016 at 4:18 PM, Mark H Weaver <mhw@netris.org> wrote:
>
>
>  I would thank you for this, but I cannot even view it without running
>  nonfree software on my machine. Posting this link essentially puts
>  pressure on those who wish to have a voice in this discussion to use
>  nonfree software, and excludes those who take a principled stand against
>  using nonfree software. That's not good.
>
>  > (I apologize that it's a google document. I couldn't find a
>  > comparable,free software online collaborative alternative. suggestions
>  > are welcome).
>
>  We must not collaborate on a platform where using nonfree software is a
>  prerequisite for entry.
>
>  Can you please send it in email as plain text?
>
>
> I adamantly agree with your sentiments. The ideal solution in my
> opinion would be a wikipage, so people could comment. Does anyone have
> access to one that we all could also read, without having to create a
> user-account (bonus points)?

Another issue is that it would be good for this discussion, as well as
the drafts of your proposal, counterproposals, etc, to be archived
somewhere that we can be reasonably confident will still exist and be
easy to find in 20 years or more.

If we use a collaborative document editor implemented in Javascript,
then participants in the discussion will have no good choice but to use
that one centralized tool to edit the proposal, write comments, etc, and
I'm doubtful that the history of edits, draft proposals and discussion
will be easily reviewable in 20 years.

We have a long history of making proposals, revising them, and
discussing them here on the mailing list in plain text.  This not only
ensures that all of the relevant information is archived, but also
allows people to use their preferred email client and text editor to
modify the proposals and respond to them.

Does that make sense?

    Thanks,
      Mark

Re: Towards De-icing ice-9 modules.

[Chad Albers]

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

Mark,

That totally make sense.  I understand.

As it stands now, the document will need to be reformatted.  Can be
attached to a email to the mailing list, and still be archived? Or should I
paste it inline?

Chad

--
Chad Albers

On Fri, Feb 12, 2016 at 4:57 PM, Mark H Weaver <mhw@netris.org> wrote:

> Chad Albers <calbers@neomantic.com> writes:
>
> > On Fri, Feb 12, 2016 at 4:18 PM, Mark H Weaver <mhw@netris.org> wrote:
> >
> >
> >  I would thank you for this, but I cannot even view it without running
> >  nonfree software on my machine. Posting this link essentially puts
> >  pressure on those who wish to have a voice in this discussion to use
> >  nonfree software, and excludes those who take a principled stand against
> >  using nonfree software. That's not good.
> >
> >  > (I apologize that it's a google document. I couldn't find a
> >  > comparable,free software online collaborative alternative. suggestions
> >  > are welcome).
> >
> >  We must not collaborate on a platform where using nonfree software is a
> >  prerequisite for entry.
> >
> >  Can you please send it in email as plain text?
> >
> >
> > I adamantly agree with your sentiments. The ideal solution in my
> > opinion would be a wikipage, so people could comment. Does anyone have
> > access to one that we all could also read, without having to create a
> > user-account (bonus points)?
>
> Another issue is that it would be good for this discussion, as well as
> the drafts of your proposal, counterproposals, etc, to be archived
> somewhere that we can be reasonably confident will still exist and be
> easy to find in 20 years or more.
>
> If we use a collaborative document editor implemented in Javascript,
> then participants in the discussion will have no good choice but to use
> that one centralized tool to edit the proposal, write comments, etc, and
> I'm doubtful that the history of edits, draft proposals and discussion
> will be easily reviewable in 20 years.
>
> We have a long history of making proposals, revising them, and
> discussing them here on the mailing list in plain text.  This not only
> ensures that all of the relevant information is archived, but also
> allows people to use their preferred email client and text editor to
> modify the proposals and respond to them.
>
> Does that make sense?
>
>     Thanks,
>       Mark
>

[-- Attachment #2: Type: text/html, Size: 3145 bytes --]

Re: Towards De-icing ice-9 modules.

[Mark H Weaver]

Chad Albers <calbers@neomantic.com> writes:

> That totally make sense. I understand.
>
> As it stands now, the document will need to be reformatted. Can be
> attached to a email to the mailing list, and still be archived? Or
> should I paste it inline?

Attachments are archived, but pasting it inline might be more convenient
to read and comment on.

    Thanks,
      Mark

Re: Towards De-icing ice-9 modules.

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

2016-02-12 21:41 GMT+01:00 Chad Albers <calbers@neomantic.com>:

> Hi,
>
> In my attempt to assist the guile project, I thought I would share a
> document on a plan to migrate some of the ice-9 modules into a more
> intuitive, yet to be decided, namespace.  Before I proposed a technological
> plan, I have begun really an audit of what ice-9 modules are available (and
> undocumented), and other modules that guile ships with. (there are some
> secrets down there).
>

Hi,
maybe I'm on a bit conservative side, but as far as I can tell, there is a
recurring suggestion is to rename modules called (ice-9 xxx) as (guile xxx).
While I do agree that the "ice-9" name isn't particularly intuitive, it
does provide a metaphor that grasps the idea that inspired Guile.

Beside this little difference -- that "ice-9" might be slightly unobvious
to newcommers -- I see no cognitive advantage in that renaming, while there
is a huge disadvantage of breaking backwards compatibility of many programs
that use Guile.

If the modification was to be meaningful, we should group modules into
logical categories -- for example, rename (ice-9 and-let-star) to (syntax
and-let*),  (ice-9 threads) to (control threads) and (ice-9 readline) to
(utils readline), for instance.

What I think would be a cooler idea is to provide a mechanism for
automatically fetching the required modules (in their required versions)
from specified git repositories, so that once a program is written, one
wouldn't have to worry about its dependecies.

It would also be nice to have a tool that would be able to trace the
modifications in the source code to see whether it contains any changes
that could break the existing functionality compared to some earler version.

(this would probably be difficult to do in general, but perhaps there are
some common use cases that could be easily covered)

Best regards,
Panicz

[-- Attachment #2: Type: text/html, Size: 2433 bytes --]

Re: Towards De-icing ice-9 modules.

[Taylan Ulrich Bayırlı/Kammer]

Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> 2016-02-12 21:41 GMT+01:00 Chad Albers <calbers@neomantic.com>:
>
>     
>     Hi,
>     
>     
>     In my attempt to assist the guile project, I thought I would share
>     a document on a plan to migrate some of the ice-9 modules into a
>     more intuitive, yet to be decided, namespace. Before I proposed a
>     technological plan, I have begun really an audit of what ice-9
>     modules are available (and undocumented), and other modules that
>     guile ships with. (there are some secrets down there).
>
> Hi,
> maybe I'm on a bit conservative side, but as far as I can tell, there
> is a recurring suggestion is to rename modules called (ice-9 xxx) as
> (guile xxx).
> While I do agree that the "ice-9" name isn't particularly intuitive,
> it does provide a metaphor that grasps the idea that inspired Guile.
>
> Beside this little difference -- that "ice-9" might be slightly
> unobvious to newcommers -- I see no cognitive advantage in that
> renaming, while there is a huge disadvantage of breaking backwards
> compatibility of many programs that use Guile.
>
> If the modification was to be meaningful, we should group modules into
> logical categories -- for example, rename (ice-9 and-let-star) to
> (syntax and-let*), (ice-9 threads) to (control threads) and (ice-9
> readline) to (utils readline), for instance.

I like the idea but if we do this we might want to add 'guile' in front
of each (like (guile syntax and-let*), (guile control threads), etc.)
since we share a namespace with RnRS libraries.

> What I think would be a cooler idea is to provide a mechanism for
> automatically fetching the required modules (in their required
> versions) from specified git repositories, so that once a program is
> written, one wouldn't have to worry about its dependecies.
>
> It would also be nice to have a tool that would be able to trace the
> modifications in the source code to see whether it contains any
> changes that could break the existing functionality compared to some
> earler version.
>
> (this would probably be difficult to do in general, but perhaps there
> are some common use cases that could be easily covered)
>
> Best regards,
> Panicz

Taylan