[Swift-devel] Mailing lists, documentation update, etc.

[Mihael Hategan]

Looks pretty good to me. Just two questions: is that OK with MCS folk,
and is that OK with the CI (Ian?)?

Mihael

On Mon, 2015-06-29 at 18:28 -0500, Ketan Maheshwari wrote:
> About mailing lists: can we move them to MCS mailing list?
> 
> --
> Ketan
> 
> On Mon, Jun 29, 2015 at 3:57 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:
> > Hi,
> >
> > I believe that there are a few issues that need some attention.
> >
> > The first one is the email from systems that our mailing lists are going
> > to be retired. While I don't think that is a good idea, since those
> > lists provide both branding for the CI as well as a convenient/painless
> > setup for CI projects, it is probably happening for a good reason.
> >
> > So, we need to find a new place to host our mailing lists and then save
> > our archives and transition to the new lists. Ideas welcome.
> >
> >
> >
> > Second is documentation. I'm still writing, but it is now more than just
> > the skeleton that it was. You can see a snapshot here:
> > http://www.mcs.anl.gov/~hategan/docs/trunk/ug/ug.html
> >
> > I welcome feedback on the overall structure and organization at this
> > point. Also, if you want to contribute a section that is missing, or
> > find certain sections to be unpalatable, let's discuss. Please don't
> > bother noticing small things, such as broken links. Almost all links are
> > broken because I just put placeholders there. They will be fixed
> > systematically once the text is written.
> >
> >
> >
> > Finally, while writing docs I had the chance (or the mental discomfort)
> > of trying to explain why certain things just don't make much sense. For
> > example, we say that variables are single assignment, but defining what
> > exactly an assignment is can be messy. If you have some file input, you
> > don't really assign to the corresponding variable. In fact, the fact
> > that you don't make any explicit assignments is what makes the variable
> > an input variable which in turns makes it assigned though the mapping
> > declaration. This kind of Catch-22 design bothers me.
> >
> > Swift/T deals with the issue in a nice way (as far as I understand).
> > Inputs are always assigned through a file() constructor. This is more
> > elegant, at least for inputs. We should probably do the same: provide
> > file(), <T> T glob(), etc, and restrict the traditional mappers to
> > outputs. Mike will probably like the unifying idea. Anyway, I'll try to
> > write these things down once I'm done with #2 and we can discuss them.
> >
> > Mihael
> >
> > _______________________________________________
> > Swift-devel mailing list
> > Swift-devel at ci.uchicago.edu
> > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel