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

[Ketan Maheshwari]

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