From hategan at mcs.anl.gov  Mon Feb  2 01:01:10 2015
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Sun, 1 Feb 2015 23:01:10 -0800
Subject: [Swift-devel] Standard Library, take II
Message-ID: <1422860470.23859.29.camel@echo>

Hi,

This is to summarize what maybe we might agree on so that we can wrap
things up a bit.

For the immediate purpose of having a standard library:
- allow overloading for library functions; we already allow it to some
extent, so I don't see much reason why we should cherry-pick
- any user function with the same name as an already defined function
(user or library) is a compile-time error; this is no different from
what is currently happening

For the future maybe, with the will of the gods of software engineering:
- allow overloading of user-defined functions
- any overloads that can potentially be ambiguous should generate a
compile-time error (aka. when {positionals1} = {positionals2} and
{keywords1} ? {keywords2} != 0).
- support function pointers/references
- unqualified references to overloaded functions are compile-time errors
- support lambda expressions
- possible support for overloaded function reference disambiguation
(e.g. casting, inference; exact method TBD).

Do we have agreement on the first part? The second isn't relevant for
the task at hand, but I thought I'd mention it.

Mihael



From tim.g.armstrong at gmail.com  Mon Feb  2 15:46:48 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Mon, 2 Feb 2015 15:46:48 -0600
Subject: [Swift-devel] Standard Library, take II
In-Reply-To: <1422860470.23859.29.camel@echo>
References: <1422860470.23859.29.camel@echo>
Message-ID: <CAC0jiV7bTpq2HZSDSgjziKNs2B8CtTAKEmwbDbzv2rB3h8Wjdg@mail.gmail.com>

I think that sounds good to me.

I think with overloading, I might attempt to implement overloading in the
generic way (such that it would support user-defined functions), but only
enable it for library functions by default.  This would let us experiment
with it to see how it works, but reduces the possibility of bugs for the
time being.

I think the keyword arguments needs some discussion.   I was thinking that
we'd have optional positional arguments only (like C++).  I think in any
case I'd like to put keyword arguments into the "future" category.  I'm
open to discussion but I think we can put that off too.

- Tim

On Mon, Feb 2, 2015 at 1:01 AM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> Hi,
>
> This is to summarize what maybe we might agree on so that we can wrap
> things up a bit.
>
> For the immediate purpose of having a standard library:
> - allow overloading for library functions; we already allow it to some
> extent, so I don't see much reason why we should cherry-pick
> - any user function with the same name as an already defined function
> (user or library) is a compile-time error; this is no different from
> what is currently happening
>
> For the future maybe, with the will of the gods of software engineering:
> - allow overloading of user-defined functions
> - any overloads that can potentially be ambiguous should generate a
> compile-time error (aka. when {positionals1} = {positionals2} and
> {keywords1} ? {keywords2} != 0).
> - support function pointers/references
> - unqualified references to overloaded functions are compile-time errors
> - support lambda expressions
> - possible support for overloaded function reference disambiguation
> (e.g. casting, inference; exact method TBD).
>
> Do we have agreement on the first part? The second isn't relevant for
> the task at hand, but I thought I'd mention it.
>
> Mihael
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150202/67df389e/attachment.html>

From hategan at mcs.anl.gov  Mon Feb  2 16:18:34 2015
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Mon, 2 Feb 2015 14:18:34 -0800
Subject: [Swift-devel] Standard Library, take II
In-Reply-To: <CAC0jiV7bTpq2HZSDSgjziKNs2B8CtTAKEmwbDbzv2rB3h8Wjdg@mail.gmail.com>
References: <1422860470.23859.29.camel@echo>
	<CAC0jiV7bTpq2HZSDSgjziKNs2B8CtTAKEmwbDbzv2rB3h8Wjdg@mail.gmail.com>
Message-ID: <1422915514.584.5.camel@echo>

On Mon, 2015-02-02 at 15:46 -0600, Tim Armstrong wrote:
> I think that sounds good to me.
> 
> I think with overloading, I might attempt to implement overloading in the
> generic way (such that it would support user-defined functions), but only
> enable it for library functions by default.  This would let us experiment
> with it to see how it works, but reduces the possibility of bugs for the
> time being.
> 
> I think the keyword arguments needs some discussion.   I was thinking that
> we'd have optional positional arguments only (like C++).  I think in any
> case I'd like to put keyword arguments into the "future" category.  I'm
> open to discussion but I think we can put that off too.

They are already in K, but noted.

I'm inclined to change most library functions with keyword args (such as
substring(str, start, [end =...]) to overloaded ones, since there is no
good reason to write:

s1 = substring(s, 0);
s2 = substring(s, 1, end = 5);

rather than

s2 = substring(s, 1, 5);

I think that, from this perspective, overloading is roughly equivalent
to optional positional arguments. 

Mihael



From tim.g.armstrong at gmail.com  Mon Feb  2 16:56:26 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Mon, 2 Feb 2015 16:56:26 -0600
Subject: [Swift-devel] Standard Library, take II
In-Reply-To: <1422915514.584.5.camel@echo>
References: <1422860470.23859.29.camel@echo>
	<CAC0jiV7bTpq2HZSDSgjziKNs2B8CtTAKEmwbDbzv2rB3h8Wjdg@mail.gmail.com>
	<1422915514.584.5.camel@echo>
Message-ID: <CAC0jiV7gcasY8aFmVMikC_E_KpHqobDe_EQHRTsbWcXnd+KTGw@mail.gmail.com>

Oh I didn't realise there were keyword args in K.  So K supports optional
arguments but the caller has to specify them by name, not position?

- Tim

On Mon, Feb 2, 2015 at 4:18 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> On Mon, 2015-02-02 at 15:46 -0600, Tim Armstrong wrote:
> > I think that sounds good to me.
> >
> > I think with overloading, I might attempt to implement overloading in the
> > generic way (such that it would support user-defined functions), but only
> > enable it for library functions by default.  This would let us experiment
> > with it to see how it works, but reduces the possibility of bugs for the
> > time being.
> >
> > I think the keyword arguments needs some discussion.   I was thinking
> that
> > we'd have optional positional arguments only (like C++).  I think in any
> > case I'd like to put keyword arguments into the "future" category.  I'm
> > open to discussion but I think we can put that off too.
>
> They are already in K, but noted.
>
> I'm inclined to change most library functions with keyword args (such as
> substring(str, start, [end =...]) to overloaded ones, since there is no
> good reason to write:
>
> s1 = substring(s, 0);
> s2 = substring(s, 1, end = 5);
>
> rather than
>
> s2 = substring(s, 1, 5);
>
> I think that, from this perspective, overloading is roughly equivalent
> to optional positional arguments.
>
> Mihael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150202/10c3ad02/attachment.html>

From hategan at mcs.anl.gov  Mon Feb  2 17:26:37 2015
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Mon, 2 Feb 2015 15:26:37 -0800
Subject: [Swift-devel] Standard Library, take II
In-Reply-To: <CAC0jiV7gcasY8aFmVMikC_E_KpHqobDe_EQHRTsbWcXnd+KTGw@mail.gmail.com>
References: <1422860470.23859.29.camel@echo>
	<CAC0jiV7bTpq2HZSDSgjziKNs2B8CtTAKEmwbDbzv2rB3h8Wjdg@mail.gmail.com>
	<1422915514.584.5.camel@echo>
	<CAC0jiV7gcasY8aFmVMikC_E_KpHqobDe_EQHRTsbWcXnd+KTGw@mail.gmail.com>
Message-ID: <1422919597.1526.3.camel@echo>

On Mon, 2015-02-02 at 16:56 -0600, Tim Armstrong wrote:
> Oh I didn't realise there were keyword args in K.  So K supports optional
> arguments but the caller has to specify them by name, not position?

Yep. See
http://swift-lang.org/guides/trunk/userguide/userguide.html#_procedures

It's even funny at times:
"...both positional parameter and named parameter passings can be
passed..."

Mihael

> 
> - Tim
> 
> On Mon, Feb 2, 2015 at 4:18 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:
> 
> > On Mon, 2015-02-02 at 15:46 -0600, Tim Armstrong wrote:
> > > I think that sounds good to me.
> > >
> > > I think with overloading, I might attempt to implement overloading in the
> > > generic way (such that it would support user-defined functions), but only
> > > enable it for library functions by default.  This would let us experiment
> > > with it to see how it works, but reduces the possibility of bugs for the
> > > time being.
> > >
> > > I think the keyword arguments needs some discussion.   I was thinking
> > that
> > > we'd have optional positional arguments only (like C++).  I think in any
> > > case I'd like to put keyword arguments into the "future" category.  I'm
> > > open to discussion but I think we can put that off too.
> >
> > They are already in K, but noted.
> >
> > I'm inclined to change most library functions with keyword args (such as
> > substring(str, start, [end =...]) to overloaded ones, since there is no
> > good reason to write:
> >
> > s1 = substring(s, 0);
> > s2 = substring(s, 1, end = 5);
> >
> > rather than
> >
> > s2 = substring(s, 1, 5);
> >
> > I think that, from this perspective, overloading is roughly equivalent
> > to optional positional arguments.
> >
> > Mihael
> >
> >




From tim.g.armstrong at gmail.com  Mon Feb  2 17:30:24 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Mon, 2 Feb 2015 17:30:24 -0600
Subject: [Swift-devel] Standard Library, take II
In-Reply-To: <1422919597.1526.3.camel@echo>
References: <1422860470.23859.29.camel@echo>
	<CAC0jiV7bTpq2HZSDSgjziKNs2B8CtTAKEmwbDbzv2rB3h8Wjdg@mail.gmail.com>
	<1422915514.584.5.camel@echo>
	<CAC0jiV7gcasY8aFmVMikC_E_KpHqobDe_EQHRTsbWcXnd+KTGw@mail.gmail.com>
	<1422919597.1526.3.camel@echo>
Message-ID: <CAC0jiV4xO7S=fdxy8cucKwksDoV0aw6URSQw76srjGrhXXNiQg@mail.gmail.com>

Ah thanks, I didn't do a good job of ctrl-Fing the docs.

- Tim

On Mon, Feb 2, 2015 at 5:26 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> On Mon, 2015-02-02 at 16:56 -0600, Tim Armstrong wrote:
> > Oh I didn't realise there were keyword args in K.  So K supports optional
> > arguments but the caller has to specify them by name, not position?
>
> Yep. See
> http://swift-lang.org/guides/trunk/userguide/userguide.html#_procedures
>
> It's even funny at times:
> "...both positional parameter and named parameter passings can be
> passed..."
>
> Mihael
>
> >
> > - Tim
> >
> > On Mon, Feb 2, 2015 at 4:18 PM, Mihael Hategan <hategan at mcs.anl.gov>
> wrote:
> >
> > > On Mon, 2015-02-02 at 15:46 -0600, Tim Armstrong wrote:
> > > > I think that sounds good to me.
> > > >
> > > > I think with overloading, I might attempt to implement overloading
> in the
> > > > generic way (such that it would support user-defined functions), but
> only
> > > > enable it for library functions by default.  This would let us
> experiment
> > > > with it to see how it works, but reduces the possibility of bugs for
> the
> > > > time being.
> > > >
> > > > I think the keyword arguments needs some discussion.   I was thinking
> > > that
> > > > we'd have optional positional arguments only (like C++).  I think in
> any
> > > > case I'd like to put keyword arguments into the "future" category.
> I'm
> > > > open to discussion but I think we can put that off too.
> > >
> > > They are already in K, but noted.
> > >
> > > I'm inclined to change most library functions with keyword args (such
> as
> > > substring(str, start, [end =...]) to overloaded ones, since there is no
> > > good reason to write:
> > >
> > > s1 = substring(s, 0);
> > > s2 = substring(s, 1, end = 5);
> > >
> > > rather than
> > >
> > > s2 = substring(s, 1, 5);
> > >
> > > I think that, from this perspective, overloading is roughly equivalent
> > > to optional positional arguments.
> > >
> > > Mihael
> > >
> > >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150202/749e6246/attachment.html>

From tim.g.armstrong at gmail.com  Tue Feb  3 16:54:31 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Tue, 3 Feb 2015 16:54:31 -0600
Subject: [Swift-devel] Feature proposal: struct constructors
Message-ID: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>

Hi All,
  While designing a location-aware feature for Swift/T Justin and I came
across a scenario where we wanted to use Swift structs, but where it was
very painful to assign each element individually.  To give you an idea:

type foo {
  int x;
  int y;
}

foo bar;
bar.x = 1;
bar.y = 2;

I'm looking at adding a feature where we can fill in a structs fields with
a single expression.

We could do them the C-style way, but that doesn't allow us to use them
without defining a new variable (the issue is that {} doesn't specify the
intended type, meaning it needs to come from context):

foo bar = { 1, 2 };

I was thinking  that we should just have types function as named
constructor functions.  There's precedent both in object-oriented languages
and with Haskell's algebraic data types.  Now you can just use this
expression wherever needed:

foo(1, 2)

Thoughts?  I'm reluctant to add new incompatibilities with Swift/K, but
this seems like it would be really clunky otherwise.

- Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150203/db933869/attachment.html>

From wozniak at mcs.anl.gov  Wed Feb  4 10:50:23 2015
From: wozniak at mcs.anl.gov (Justin M Wozniak)
Date: Wed, 4 Feb 2015 10:50:23 -0600
Subject: [Swift-devel] Feature proposal: struct constructors
In-Reply-To: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>
References: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>
Message-ID: <54D24DCF.3030101@mcs.anl.gov>


There's also this compact style:

foo bar(1,2);

Is it ambiguous?  C++ has issues with this.

On 02/03/2015 04:54 PM, Tim Armstrong wrote:
> Hi All,
>   While designing a location-aware feature for Swift/T Justin and I 
> came across a scenario where we wanted to use Swift structs, but where 
> it was very painful to assign each element individually.  To give you 
> an idea:
>
> type foo {
>   int x;
>   int y;
> }
>
> foo bar;
> bar.x = 1;
> bar.y = 2;
>
> I'm looking at adding a feature where we can fill in a structs fields 
> with a single expression.
>
> We could do them the C-style way, but that doesn't allow us to use 
> them without defining a new variable (the issue is that {} doesn't 
> specify the intended type, meaning it needs to come from context):
>
> foo bar = { 1, 2 };
>
> I was thinking  that we should just have types function as named 
> constructor functions.  There's precedent both in object-oriented 
> languages and with Haskell's algebraic data types.  Now you can just 
> use this expression wherever needed:
>
> foo(1, 2)
>
> Thoughts?  I'm reluctant to add new incompatibilities with Swift/K, 
> but this seems like it would be really clunky otherwise.
>
> - Tim
>
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel


-- 
Justin M Wozniak

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150204/7e5abf54/attachment.html>

From tim.g.armstrong at gmail.com  Wed Feb  4 11:14:02 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Wed, 4 Feb 2015 11:14:02 -0600
Subject: [Swift-devel] Feature proposal: struct constructors
In-Reply-To: <54D24DCF.3030101@mcs.anl.gov>
References: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>
	<54D24DCF.3030101@mcs.anl.gov>
Message-ID: <CAC0jiV7LQxCtT1C+BXakTmbQdv7F4t91y=PLrorRre2=CR2DVA@mail.gmail.com>

I don't think it's ambiguous syntactically - the two space-separated id
tokens are unambiguously the start of a variable declaration, so the open
paren can be interpreted unambiguously.

I think the main downside would be that users have remember a special-case
way to assign a struct at declaration time.

Swift/T also has (I think 100% consistently) a rule that the only way to
assign a variable is for it to be on the LHS of a = .  I think the
consistency of that is good.

With the expression syntax plus automatic variable declaration, it's
actually possible to shorten:

foo bar = foo(1,2);

to:

bar = foo(1,2);

- Tim


On Wed, Feb 4, 2015 at 10:50 AM, Justin M Wozniak <wozniak at mcs.anl.gov>
wrote:

>
> There's also this compact style:
>
> foo bar(1,2);
>
> Is it ambiguous?  C++ has issues with this.
>
>
> On 02/03/2015 04:54 PM, Tim Armstrong wrote:
>
>   Hi All,
>    While designing a location-aware feature for Swift/T Justin and I came
> across a scenario where we wanted to use Swift structs, but where it was
> very painful to assign each element individually.  To give you an idea:
>
> type foo {
>    int x;
>    int y;
>  }
>
>  foo bar;
> bar.x = 1;
> bar.y = 2;
>
>  I'm looking at adding a feature where we can fill in a structs fields
> with a single expression.
>
>  We could do them the C-style way, but that doesn't allow us to use them
> without defining a new variable (the issue is that {} doesn't specify the
> intended type, meaning it needs to come from context):
>
>  foo bar = { 1, 2 };
>
>  I was thinking  that we should just have types function as named
> constructor functions.  There's precedent both in object-oriented languages
> and with Haskell's algebraic data types.  Now you can just use this
> expression wherever needed:
>
> foo(1, 2)
>
>  Thoughts?  I'm reluctant to add new incompatibilities with Swift/K, but
> this seems like it would be really clunky otherwise.
>
>  - Tim
>
>
> _______________________________________________
> Swift-devel mailing listSwift-devel at ci.uchicago.eduhttps://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
>
>
> --
> Justin M Wozniak
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150204/3fd17f10/attachment.html>

From wozniak at mcs.anl.gov  Wed Feb  4 11:22:40 2015
From: wozniak at mcs.anl.gov (Justin M Wozniak)
Date: Wed, 4 Feb 2015 11:22:40 -0600
Subject: [Swift-devel] Feature proposal: struct constructors
In-Reply-To: <CAC0jiV7LQxCtT1C+BXakTmbQdv7F4t91y=PLrorRre2=CR2DVA@mail.gmail.com>
References: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>	<54D24DCF.3030101@mcs.anl.gov>
	<CAC0jiV7LQxCtT1C+BXakTmbQdv7F4t91y=PLrorRre2=CR2DVA@mail.gmail.com>
Message-ID: <54D25560.6020302@mcs.anl.gov>

On 02/04/2015 11:14 AM, Tim Armstrong wrote:
> With the expression syntax plus automatic variable declaration, it's 
> actually possible to shorten:
>
> to:
>
> bar = foo(1,2);

I forgot about that!

-- 
Justin M Wozniak



From wozniak at mcs.anl.gov  Wed Feb  4 11:39:21 2015
From: wozniak at mcs.anl.gov (Justin M Wozniak)
Date: Wed, 4 Feb 2015 11:39:21 -0600
Subject: [Swift-devel] Feature proposal: struct constructors
In-Reply-To: <CAC0jiV7LQxCtT1C+BXakTmbQdv7F4t91y=PLrorRre2=CR2DVA@mail.gmail.com>
References: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>	<54D24DCF.3030101@mcs.anl.gov>
	<CAC0jiV7LQxCtT1C+BXakTmbQdv7F4t91y=PLrorRre2=CR2DVA@mail.gmail.com>
Message-ID: <54D25949.3000105@mcs.anl.gov>


Did we discuss optional or named parameters wrt constructors?

type v {
   int x = 0;
   int y = 0;
}

e2 = v(y=1);

On 02/04/2015 11:14 AM, Tim Armstrong wrote:
> type foo {
>   int x;
>   int y;
> }
>
> foo bar;
> bar.x = 1;
> bar.y = 2;


-- 
Justin M Wozniak



From tim.g.armstrong at gmail.com  Wed Feb  4 11:43:28 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Wed, 4 Feb 2015 11:43:28 -0600
Subject: [Swift-devel] Feature proposal: struct constructors
In-Reply-To: <54D25949.3000105@mcs.anl.gov>
References: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>
	<54D24DCF.3030101@mcs.anl.gov>
	<CAC0jiV7LQxCtT1C+BXakTmbQdv7F4t91y=PLrorRre2=CR2DVA@mail.gmail.com>
	<54D25949.3000105@mcs.anl.gov>
Message-ID: <CAC0jiV511_ZfZWoqdOVi=1g-4nhUzJLAyTLb=ReSdCstx-OK1w@mail.gmail.com>

Not that I remember.

- Tim

On Wed, Feb 4, 2015 at 11:39 AM, Justin M Wozniak <wozniak at mcs.anl.gov>
wrote:

>
> Did we discuss optional or named parameters wrt constructors?
>
> type v {
>   int x = 0;
>   int y = 0;
> }
>
> e2 = v(y=1);
>
> On 02/04/2015 11:14 AM, Tim Armstrong wrote:
>
>> type foo {
>>   int x;
>>   int y;
>> }
>>
>> foo bar;
>> bar.x = 1;
>> bar.y = 2;
>>
>
>
> --
> Justin M Wozniak
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150204/f31a2980/attachment.html>

From hategan at mcs.anl.gov  Wed Feb  4 12:56:39 2015
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Wed, 4 Feb 2015 10:56:39 -0800
Subject: [Swift-devel] Feature proposal: struct constructors
In-Reply-To: <54D25949.3000105@mcs.anl.gov>
References: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>
	<54D24DCF.3030101@mcs.anl.gov>
	<CAC0jiV7LQxCtT1C+BXakTmbQdv7F4t91y=PLrorRre2=CR2DVA@mail.gmail.com>
	<54D25949.3000105@mcs.anl.gov>
Message-ID: <1423076199.1056.9.camel@echo>

I like the general idea of struct constructors and I am for it.

I also think that I like keyword arguments to struct constructors.
Presumably there could be cases when you don't want to initialize all
fields of a struct.

Also, we should probably encourage a naming convention that avoids
possible conflicts between function invocations and struct constructors.
Using capitalized names for user-defined types comes to mind.

Mihael

On Wed, 2015-02-04 at 11:39 -0600, Justin M Wozniak wrote:
> Did we discuss optional or named parameters wrt constructors?
> 
> type v {
>    int x = 0;
>    int y = 0;
> }
> 
> e2 = v(y=1);
> 
> On 02/04/2015 11:14 AM, Tim Armstrong wrote:
> > type foo {
> >   int x;
> >   int y;
> > }
> >
> > foo bar;
> > bar.x = 1;
> > bar.y = 2;
> 
> 




From ketan at mcs.anl.gov  Wed Feb  4 13:05:38 2015
From: ketan at mcs.anl.gov (Ketan Maheshwari)
Date: Wed, 4 Feb 2015 13:05:38 -0600
Subject: [Swift-devel] Feature proposal: struct constructors
In-Reply-To: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>
References: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>
Message-ID: <CAMUuvip3WeAq7hSr0STq1Ps2DdLXvV=gbMw5BGsro+tV0=_spw@mail.gmail.com>

I would suggest we change the naming from constructors to something else as
it has some associated OO connotations.

On Tue, Feb 3, 2015 at 4:54 PM, Tim Armstrong <tim.g.armstrong at gmail.com>
wrote:

> Hi All,
>   While designing a location-aware feature for Swift/T Justin and I came
> across a scenario where we wanted to use Swift structs, but where it was
> very painful to assign each element individually.  To give you an idea:
>
> type foo {
>   int x;
>   int y;
> }
>
> foo bar;
> bar.x = 1;
> bar.y = 2;
>
> I'm looking at adding a feature where we can fill in a structs fields with
> a single expression.
>
> We could do them the C-style way, but that doesn't allow us to use them
> without defining a new variable (the issue is that {} doesn't specify the
> intended type, meaning it needs to come from context):
>
> foo bar = { 1, 2 };
>
> I was thinking  that we should just have types function as named
> constructor functions.  There's precedent both in object-oriented languages
> and with Haskell's algebraic data types.  Now you can just use this
> expression wherever needed:
>
> foo(1, 2)
>
> Thoughts?  I'm reluctant to add new incompatibilities with Swift/K, but
> this seems like it would be really clunky otherwise.
>
> - Tim
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150204/396dd537/attachment.html>

From tim.g.armstrong at gmail.com  Wed Feb  4 13:51:47 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Wed, 4 Feb 2015 13:51:47 -0600
Subject: [Swift-devel] Feature proposal: struct constructors
In-Reply-To: <CAMUuvip3WeAq7hSr0STq1Ps2DdLXvV=gbMw5BGsro+tV0=_spw@mail.gmail.com>
References: <CAC0jiV7MWtGmm60nHHZo7_58O3AVatx8hCOJBFpvx=X3DgShjQ@mail.gmail.com>
	<CAMUuvip3WeAq7hSr0STq1Ps2DdLXvV=gbMw5BGsro+tV0=_spw@mail.gmail.com>
Message-ID: <CAC0jiV4Lk4xaOmzZAFLURDqUK9hmuLC17bOur87x5-W8sf+wHQ@mail.gmail.com>

I guess it may cause some confusion, but it's the standard term in
functional programming too, e.g.
https://wiki.haskell.org/Constructor#Data_constructor

Mihael, in Swift/T types and functions are in the same namespace so it
isn't possible to have a function with the same name as a type.

This is something else we should probably standardise on - does Swift/K has
separate namespaces for functions and types?  I think we could solve the
ambiguity by just having struct definitions automatically define a function
in the function namespace.

Regardless, CamelCase is probably reasonable for user-defined types.
Thoughts?

- Tim

On Wed, Feb 4, 2015 at 1:05 PM, Ketan Maheshwari <ketan at mcs.anl.gov> wrote:

> I would suggest we change the naming from constructors to something else
> as it has some associated OO connotations.
>
> On Tue, Feb 3, 2015 at 4:54 PM, Tim Armstrong <tim.g.armstrong at gmail.com>
> wrote:
>
>> Hi All,
>>   While designing a location-aware feature for Swift/T Justin and I came
>> across a scenario where we wanted to use Swift structs, but where it was
>> very painful to assign each element individually.  To give you an idea:
>>
>> type foo {
>>   int x;
>>   int y;
>> }
>>
>> foo bar;
>> bar.x = 1;
>> bar.y = 2;
>>
>> I'm looking at adding a feature where we can fill in a structs fields
>> with a single expression.
>>
>> We could do them the C-style way, but that doesn't allow us to use them
>> without defining a new variable (the issue is that {} doesn't specify the
>> intended type, meaning it needs to come from context):
>>
>> foo bar = { 1, 2 };
>>
>> I was thinking  that we should just have types function as named
>> constructor functions.  There's precedent both in object-oriented languages
>> and with Haskell's algebraic data types.  Now you can just use this
>> expression wherever needed:
>>
>> foo(1, 2)
>>
>> Thoughts?  I'm reluctant to add new incompatibilities with Swift/K, but
>> this seems like it would be really clunky otherwise.
>>
>> - Tim
>>
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150204/86784c2c/attachment.html>

From tim.g.armstrong at gmail.com  Sat Feb  7 14:36:37 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Sat, 7 Feb 2015 14:36:37 -0600
Subject: [Swift-devel] Java Code Coverage
Message-ID: <CAC0jiV6UKw26=Pjccshw=GPUxjC4cUb0cVxD_4b=hPa=Adt8wQ@mail.gmail.com>

I spent a while on Friday chasing a subtle optimiser bug and that finally
spurred me to do something I've been meaning to do for a while: check to
see how much of the STC codebase the test suite actually exercised. The
results were actually better than expected - a little over 80% and a lot of
the remainder was trace-level logging statements that were disabled.

I thought I'd share with the list - maybe it would be of use for Swift/K
too.

Some browsable sample results are here:
http://people.cs.uchicago.edu/~tga/stc-test-coverage/

This is the tool I used: http://www.eclemma.org/jacoco/ . It was easier to
set up than I thought - you can enable coverage output to files by setting
JVM flags (e.g. when the swift launch script runs java), then generate a
report via an ant task.

- Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150207/99a21b63/attachment.html>

From tim.g.armstrong at gmail.com  Sat Feb  7 16:10:08 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Sat, 7 Feb 2015 16:10:08 -0600
Subject: [Swift-devel] Keyword Args and Overloading
Message-ID: <CAC0jiV6eUSnrvEHyr=0MvQ7ygEAMZQfS_EsP3ThWK-m0GYzj8w@mail.gmail.com>

Hi All,

  So we had a bunch of useful discussion about what we wanted to support in
functions.  There was a pretty clear decision to only support overloading
for library functions at this stage, but I think a few things were left
unspecified, since there are a lot of potential variations.


To pin it down, I'm going to attempt to define some terms and precisely
talk about what design decision we're making.

Definitions
========

Function definition: a single function definition that specifies the types
and names of arguments, plus info for any additional features about
arguments
Composite functions: functions with a Swift body
Function callsite: a place in the program where the function is called with
a list of arguments.  In general, we can have f(1, 2, 3, argname1=4,
argname2=5)
Overloaded function definitions (Overloads): where multiple function
definitions with the same name exist, and they are disambiguated at the
function callsite based on the callsite arguments

Callsite argument categories:
Positional Arguments (PosArgs) - when the the caller only specifies
position.  e.g. f(1,2,3)
Keyword Arguments (KWArgs) - when the callsite specifies the name of the
argument, e.g. f(x=1, y=2).  This allows them to be specified out of order
or with some omitted

Function definition argument categories:
Required Arguments(ReqArgs) - arguments that are required
Variadic Arguments (VarArgs) - the last argument in the function definition
can match 0 or more PosArgs
Optional Arguments (OptArgs) - when a default value is provided for an
argument, e.g. f(arg=2)
Polymorphic Arguments (PolyArgs) - when a argument in the function
definition can be one of set of types (e.g. wildcard type, type variables,
union types)

Matching rules (I've marked the ones up for discussion with a ??? and
uncontroversial ones with :)):
PosArgs -> ReqArgs - :)
PosArgs -> VarArgs - :)
PosArgs -> OptArgs - ???
KWArgs -> ReqArgs - ???
KWArgs -> VarArgs - ???
KWArgs -> OptArgs - :)

Restrictions
=========
Overall restrictions that I think we agree on, for now:
* VarArgs and OptArgs cannot be used in same function definition.
* Any OptArgs must be followed only by other OptArgs
* VarArgs cannot be used in composite function definitions
* PolyArgs cannot be used in composite function definitions

So now I think there are a few somewhat different ways we can allow the
other features to be combined.  The baseline features, that I will assume
for the rest are:

  ReqArgs + PosArgs. + VarArgs + (PosArgs -> ReqArgs) + (PosArgs -> VarArgs)

My understanding of the current states of Swift/T and Swift/K are:

  T -VarArgs|OptArgs + PolyArgs
  K -VarArgs|OptArgs + PolyArgs (sorta) + KWArgs + (KWArgs -> OptArgs)

If we want to extend things, first, this would be the attempt to support
everything in combination.

  PolyArgs + VarArgs|OptArgs + KWArgs +(PosArgs -> OptArgs) + (KWArgs ->
ReqArgs) + (KWArgs -> VarArgs) + Overloading

I think we agree that this is not reasonable to implement.  I'm not totally
clear on which subset we are planning to support though.  One restriction
that seems reasonable is to disallow the combination of PolyArgs and
Overloading:

 VarArgs|OptArgs + PolyArgs|Overloading + KWArgs +(PosArgs -> OptArgs) +
(KWArgs -> ReqArgs) + (KWArgs -> VarArgs)

Maybe we also don't really need (KWArgs -> ReqArgs) + (KWArgs -> VarArgs) -
they seem marginally useful at best.  I think it's also reasonable to
restrict matching so that KWArgs are always matched before PosArgs.  I.e.
f(1, x=1) doesn't match f(int x=0, int y=0) .  I'll call this
KWArgsBeforeOptArgs.  This corresponds to the algorithm "Match n
positionals with first n args, then resolve KWArgs to remaining OptArgs"

That would leave:

 VarArgs|OptArgs + PolyArgs|Overloading + KWArgs +(PosArgs -> OptArgs) -
KWArgsBeforeOptArgs

I think resolving overloads here is still a little complex because we need
to consider multiple ways to match keyword arguments to positional
arguments. It's also difficult to work out (in the compiler or in the
programmer's head) if two overloaded definitions may potentially conflict
because the matching of callsite args to definition arguments is complex. I
think the possibility exists if the ReqArgs of one overload is a prefix of
the ReqArgs of the another overload and there's some overlap in keyword arg
names.  I'd imagine in many situations where people might want to use
OptArgs+Overloading, then this is a possibility.

One option (I think Swift/K does this) is to strictly match PosArgs to
ReqArgs and KWArgs to OptArgs.

  VarArgs|OptArgs + PolyArgs|Overloading  + KWArgs

I think it is probably not too difficult to resolve overloads with KWArgs
in this situation. The restriction {positionals1} = {positionals2} or
{keywords1} ? {keywords2} != 0 that Mihael proposed on overloading does
help things here. I still find this choice a little unsatisfying because
programmers often would prefer to provide optional arguments positionally.

Another option is to discards KWArgs, leaving us:

  VarArgs|Optargs + PolyArgs|Overloading + (PosArgs -> OptArgs) -
KWArgsBeforeOptArgs

I think we agree that KWArgs are a nice feature that we'd like to have, so
that's not great either.  Maybe we can disallow OptArgs for overloads
though - it seems like in most situations you would use one or the other,
not both.  We could potentially
This would give us:

 VarArgs|OptArgs + PolyArgs + KWArgs +(PosArgs -> OptArgs) -
KWArgsBeforeOptArgs
 VarArgs + PolyArgs|Overloading + KWArgs +(PosArgs -> OptArgs) -
KWArgsBeforeOptArgs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150207/9db22a90/attachment.html>

From tim.g.armstrong at gmail.com  Sat Feb  7 16:17:04 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Sat, 7 Feb 2015 16:17:04 -0600
Subject: [Swift-devel] Keyword Args and Overloading
In-Reply-To: <CAC0jiV6eUSnrvEHyr=0MvQ7ygEAMZQfS_EsP3ThWK-m0GYzj8w@mail.gmail.com>
References: <CAC0jiV6eUSnrvEHyr=0MvQ7ygEAMZQfS_EsP3ThWK-m0GYzj8w@mail.gmail.com>
Message-ID: <CAC0jiV5rBXKcbxwWu__R-UBP0BS7JHSgGMkT3MdMCi8-gYZi1g@mail.gmail.com>

Oops, hit send before I finished typing.  The last bit should be:

 VarArgs|OptArgs + PolyArgs + KWArgs +(PosArgs -> OptArgs) -
KWArgsBeforeOptArgs
 VarArgs + Overloading

I think we could revisit the combination of Overloading + OptArgs later and
support it only for cases where it was simple to resolve, but this seems
like a good starting point.

Also, we would only be supporting some of these features for library
functions initially, meaning the use cases are more constrained, but I have
to write the typechecking algorithms for library functions anyway.

Anyway, so I was hoping that we'd be able to agree on one of the options
and have it concretely stated so that we're implementing the same thing in
T and K.  I prefer the last alternative, but there are other reasonable
ones and it'd be good to get everyone's inputs and thoughts.

- Tim

On Sat, Feb 7, 2015 at 4:10 PM, Tim Armstrong <tim.g.armstrong at gmail.com>
wrote:

> Hi All,
>
>   So we had a bunch of useful discussion about what we wanted to support
> in functions.  There was a pretty clear decision to only support
> overloading for library functions at this stage, but I think a few things
> were left unspecified, since there are a lot of potential variations.
>
>
> To pin it down, I'm going to attempt to define some terms and precisely
> talk about what design decision we're making.
>
> Definitions
> ========
>
> Function definition: a single function definition that specifies the types
> and names of arguments, plus info for any additional features about
> arguments
> Composite functions: functions with a Swift body
> Function callsite: a place in the program where the function is called
> with a list of arguments.  In general, we can have f(1, 2, 3, argname1=4,
> argname2=5)
> Overloaded function definitions (Overloads): where multiple function
> definitions with the same name exist, and they are disambiguated at the
> function callsite based on the callsite arguments
>
> Callsite argument categories:
> Positional Arguments (PosArgs) - when the the caller only specifies
> position.  e.g. f(1,2,3)
> Keyword Arguments (KWArgs) - when the callsite specifies the name of the
> argument, e.g. f(x=1, y=2).  This allows them to be specified out of order
> or with some omitted
>
> Function definition argument categories:
> Required Arguments(ReqArgs) - arguments that are required
> Variadic Arguments (VarArgs) - the last argument in the function
> definition can match 0 or more PosArgs
> Optional Arguments (OptArgs) - when a default value is provided for an
> argument, e.g. f(arg=2)
> Polymorphic Arguments (PolyArgs) - when a argument in the function
> definition can be one of set of types (e.g. wildcard type, type variables,
> union types)
>
> Matching rules (I've marked the ones up for discussion with a ??? and
> uncontroversial ones with :)):
> PosArgs -> ReqArgs - :)
> PosArgs -> VarArgs - :)
> PosArgs -> OptArgs - ???
> KWArgs -> ReqArgs - ???
> KWArgs -> VarArgs - ???
> KWArgs -> OptArgs - :)
>
> Restrictions
> =========
> Overall restrictions that I think we agree on, for now:
> * VarArgs and OptArgs cannot be used in same function definition.
> * Any OptArgs must be followed only by other OptArgs
> * VarArgs cannot be used in composite function definitions
> * PolyArgs cannot be used in composite function definitions
>
> So now I think there are a few somewhat different ways we can allow the
> other features to be combined.  The baseline features, that I will assume
> for the rest are:
>
>   ReqArgs + PosArgs. + VarArgs + (PosArgs -> ReqArgs) + (PosArgs ->
> VarArgs)
>
> My understanding of the current states of Swift/T and Swift/K are:
>
>   T -VarArgs|OptArgs + PolyArgs
>   K -VarArgs|OptArgs + PolyArgs (sorta) + KWArgs + (KWArgs -> OptArgs)
>
> If we want to extend things, first, this would be the attempt to support
> everything in combination.
>
>   PolyArgs + VarArgs|OptArgs + KWArgs +(PosArgs -> OptArgs) + (KWArgs ->
> ReqArgs) + (KWArgs -> VarArgs) + Overloading
>
> I think we agree that this is not reasonable to implement.  I'm not
> totally clear on which subset we are planning to support though.  One
> restriction that seems reasonable is to disallow the combination of
> PolyArgs and Overloading:
>
>  VarArgs|OptArgs + PolyArgs|Overloading + KWArgs +(PosArgs -> OptArgs) +
> (KWArgs -> ReqArgs) + (KWArgs -> VarArgs)
>
> Maybe we also don't really need (KWArgs -> ReqArgs) + (KWArgs -> VarArgs)
> - they seem marginally useful at best.  I think it's also reasonable to
> restrict matching so that KWArgs are always matched before PosArgs.  I.e.
> f(1, x=1) doesn't match f(int x=0, int y=0) .  I'll call this
> KWArgsBeforeOptArgs.  This corresponds to the algorithm "Match n
> positionals with first n args, then resolve KWArgs to remaining OptArgs"
>
> That would leave:
>
>  VarArgs|OptArgs + PolyArgs|Overloading + KWArgs +(PosArgs -> OptArgs) -
> KWArgsBeforeOptArgs
>
> I think resolving overloads here is still a little complex because we need
> to consider multiple ways to match keyword arguments to positional
> arguments. It's also difficult to work out (in the compiler or in the
> programmer's head) if two overloaded definitions may potentially conflict
> because the matching of callsite args to definition arguments is complex. I
> think the possibility exists if the ReqArgs of one overload is a prefix of
> the ReqArgs of the another overload and there's some overlap in keyword arg
> names.  I'd imagine in many situations where people might want to use
> OptArgs+Overloading, then this is a possibility.
>
> One option (I think Swift/K does this) is to strictly match PosArgs to
> ReqArgs and KWArgs to OptArgs.
>
>   VarArgs|OptArgs + PolyArgs|Overloading  + KWArgs
>
> I think it is probably not too difficult to resolve overloads with KWArgs
> in this situation. The restriction {positionals1} = {positionals2} or
> {keywords1} ? {keywords2} != 0 that Mihael proposed on overloading does
> help things here. I still find this choice a little unsatisfying because
> programmers often would prefer to provide optional arguments positionally.
>
> Another option is to discards KWArgs, leaving us:
>
>   VarArgs|Optargs + PolyArgs|Overloading + (PosArgs -> OptArgs) -
> KWArgsBeforeOptArgs
>
> I think we agree that KWArgs are a nice feature that we'd like to have, so
> that's not great either.  Maybe we can disallow OptArgs for overloads
> though - it seems like in most situations you would use one or the other,
> not both.  We could potentially
> This would give us:
>
>  VarArgs|OptArgs + PolyArgs + KWArgs +(PosArgs -> OptArgs) -
> KWArgsBeforeOptArgs
>  VarArgs + PolyArgs|Overloading + KWArgs +(PosArgs -> OptArgs) -
> KWArgsBeforeOptArgs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150207/416cdb09/attachment.html>

From tim.g.armstrong at gmail.com  Sat Feb  7 16:19:51 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Sat, 7 Feb 2015 16:19:51 -0600
Subject: [Swift-devel] Keyword Args and Overloading
In-Reply-To: <CAC0jiV5rBXKcbxwWu__R-UBP0BS7JHSgGMkT3MdMCi8-gYZi1g@mail.gmail.com>
References: <CAC0jiV6eUSnrvEHyr=0MvQ7ygEAMZQfS_EsP3ThWK-m0GYzj8w@mail.gmail.com>
	<CAC0jiV5rBXKcbxwWu__R-UBP0BS7JHSgGMkT3MdMCi8-gYZi1g@mail.gmail.com>
Message-ID: <CAC0jiV7iVxe99wSY5sWJEsiXOmzMD3Y82+pVS10crunFSEqL4w@mail.gmail.com>

Also, KWArgsBeforeOptArgs should be PosArgsBeforeKWArgs - wasn't thinking
clearly

- Tim

On Sat, Feb 7, 2015 at 4:17 PM, Tim Armstrong <tim.g.armstrong at gmail.com>
wrote:

> Oops, hit send before I finished typing.  The last bit should be:
>
>  VarArgs|OptArgs + PolyArgs + KWArgs +(PosArgs -> OptArgs) -
> KWArgsBeforeOptArgs
>  VarArgs + Overloading
>
> I think we could revisit the combination of Overloading + OptArgs later
> and support it only for cases where it was simple to resolve, but this
> seems like a good starting point.
>
> Also, we would only be supporting some of these features for library
> functions initially, meaning the use cases are more constrained, but I have
> to write the typechecking algorithms for library functions anyway.
>
> Anyway, so I was hoping that we'd be able to agree on one of the options
> and have it concretely stated so that we're implementing the same thing in
> T and K.  I prefer the last alternative, but there are other reasonable
> ones and it'd be good to get everyone's inputs and thoughts.
>
> - Tim
>
> On Sat, Feb 7, 2015 at 4:10 PM, Tim Armstrong <tim.g.armstrong at gmail.com>
> wrote:
>
>> Hi All,
>>
>>   So we had a bunch of useful discussion about what we wanted to support
>> in functions.  There was a pretty clear decision to only support
>> overloading for library functions at this stage, but I think a few things
>> were left unspecified, since there are a lot of potential variations.
>>
>>
>> To pin it down, I'm going to attempt to define some terms and precisely
>> talk about what design decision we're making.
>>
>> Definitions
>> ========
>>
>> Function definition: a single function definition that specifies the
>> types and names of arguments, plus info for any additional features about
>> arguments
>> Composite functions: functions with a Swift body
>> Function callsite: a place in the program where the function is called
>> with a list of arguments.  In general, we can have f(1, 2, 3, argname1=4,
>> argname2=5)
>> Overloaded function definitions (Overloads): where multiple function
>> definitions with the same name exist, and they are disambiguated at the
>> function callsite based on the callsite arguments
>>
>> Callsite argument categories:
>> Positional Arguments (PosArgs) - when the the caller only specifies
>> position.  e.g. f(1,2,3)
>> Keyword Arguments (KWArgs) - when the callsite specifies the name of the
>> argument, e.g. f(x=1, y=2).  This allows them to be specified out of order
>> or with some omitted
>>
>> Function definition argument categories:
>> Required Arguments(ReqArgs) - arguments that are required
>> Variadic Arguments (VarArgs) - the last argument in the function
>> definition can match 0 or more PosArgs
>> Optional Arguments (OptArgs) - when a default value is provided for an
>> argument, e.g. f(arg=2)
>> Polymorphic Arguments (PolyArgs) - when a argument in the function
>> definition can be one of set of types (e.g. wildcard type, type variables,
>> union types)
>>
>> Matching rules (I've marked the ones up for discussion with a ??? and
>> uncontroversial ones with :)):
>> PosArgs -> ReqArgs - :)
>> PosArgs -> VarArgs - :)
>> PosArgs -> OptArgs - ???
>> KWArgs -> ReqArgs - ???
>> KWArgs -> VarArgs - ???
>> KWArgs -> OptArgs - :)
>>
>> Restrictions
>> =========
>> Overall restrictions that I think we agree on, for now:
>> * VarArgs and OptArgs cannot be used in same function definition.
>> * Any OptArgs must be followed only by other OptArgs
>> * VarArgs cannot be used in composite function definitions
>> * PolyArgs cannot be used in composite function definitions
>>
>> So now I think there are a few somewhat different ways we can allow the
>> other features to be combined.  The baseline features, that I will assume
>> for the rest are:
>>
>>   ReqArgs + PosArgs. + VarArgs + (PosArgs -> ReqArgs) + (PosArgs ->
>> VarArgs)
>>
>> My understanding of the current states of Swift/T and Swift/K are:
>>
>>   T -VarArgs|OptArgs + PolyArgs
>>   K -VarArgs|OptArgs + PolyArgs (sorta) + KWArgs + (KWArgs -> OptArgs)
>>
>> If we want to extend things, first, this would be the attempt to support
>> everything in combination.
>>
>>   PolyArgs + VarArgs|OptArgs + KWArgs +(PosArgs -> OptArgs) + (KWArgs ->
>> ReqArgs) + (KWArgs -> VarArgs) + Overloading
>>
>> I think we agree that this is not reasonable to implement.  I'm not
>> totally clear on which subset we are planning to support though.  One
>> restriction that seems reasonable is to disallow the combination of
>> PolyArgs and Overloading:
>>
>>  VarArgs|OptArgs + PolyArgs|Overloading + KWArgs +(PosArgs -> OptArgs) +
>> (KWArgs -> ReqArgs) + (KWArgs -> VarArgs)
>>
>> Maybe we also don't really need (KWArgs -> ReqArgs) + (KWArgs -> VarArgs)
>> - they seem marginally useful at best.  I think it's also reasonable to
>> restrict matching so that KWArgs are always matched before PosArgs.  I.e.
>> f(1, x=1) doesn't match f(int x=0, int y=0) .  I'll call this
>> KWArgsBeforeOptArgs.  This corresponds to the algorithm "Match n
>> positionals with first n args, then resolve KWArgs to remaining OptArgs"
>>
>> That would leave:
>>
>>  VarArgs|OptArgs + PolyArgs|Overloading + KWArgs +(PosArgs -> OptArgs) -
>> KWArgsBeforeOptArgs
>>
>> I think resolving overloads here is still a little complex because we
>> need to consider multiple ways to match keyword arguments to positional
>> arguments. It's also difficult to work out (in the compiler or in the
>> programmer's head) if two overloaded definitions may potentially conflict
>> because the matching of callsite args to definition arguments is complex. I
>> think the possibility exists if the ReqArgs of one overload is a prefix of
>> the ReqArgs of the another overload and there's some overlap in keyword arg
>> names.  I'd imagine in many situations where people might want to use
>> OptArgs+Overloading, then this is a possibility.
>>
>> One option (I think Swift/K does this) is to strictly match PosArgs to
>> ReqArgs and KWArgs to OptArgs.
>>
>>   VarArgs|OptArgs + PolyArgs|Overloading  + KWArgs
>>
>> I think it is probably not too difficult to resolve overloads with KWArgs
>> in this situation. The restriction {positionals1} = {positionals2} or
>> {keywords1} ? {keywords2} != 0 that Mihael proposed on overloading does
>> help things here. I still find this choice a little unsatisfying because
>> programmers often would prefer to provide optional arguments positionally.
>>
>> Another option is to discards KWArgs, leaving us:
>>
>>   VarArgs|Optargs + PolyArgs|Overloading + (PosArgs -> OptArgs) -
>> KWArgsBeforeOptArgs
>>
>> I think we agree that KWArgs are a nice feature that we'd like to have,
>> so that's not great either.  Maybe we can disallow OptArgs for overloads
>> though - it seems like in most situations you would use one or the other,
>> not both.  We could potentially
>> This would give us:
>>
>>  VarArgs|OptArgs + PolyArgs + KWArgs +(PosArgs -> OptArgs) -
>> KWArgsBeforeOptArgs
>>  VarArgs + PolyArgs|Overloading + KWArgs +(PosArgs -> OptArgs) -
>> KWArgsBeforeOptArgs
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150207/a3945287/attachment.html>

From yadudoc1729 at gmail.com  Tue Feb 10 13:21:34 2015
From: yadudoc1729 at gmail.com (Yadu Nand)
Date: Tue, 10 Feb 2015 13:21:34 -0600
Subject: [Swift-devel] Fwd: [Swift-user] Swift-Java error: Block task
 failed: Connection to worker lost
In-Reply-To: <8CEB97C36B499F4CB2FA1E00DD06E343449DA7B0@xm-mbx-07-prod.ad.uchicago.edu>
References: <8CEB97C36B499F4CB2FA1E00DD06E343449D0950@xm-mbx-07-prod.ad.uchicago.edu>
	<CANa904kGyMohJ3H-Pw9v0EgNfjjaktkBJEu0DyN-PNgwSC4adQ@mail.gmail.com>
	<8CEB97C36B499F4CB2FA1E00DD06E343449DA7B0@xm-mbx-07-prod.ad.uchicago.edu>
Message-ID: <CANa904=p26mecm4hMeKrqsJYF-TM2bLCgvuA-QsxzHh_TM_byg@mail.gmail.com>

Hi Mihael,

Could you take a look at the attached logs from Karthikeyan. I've gone
through them
and tried a couple experiments on midway to check for failures with long
running
tasks and haven't run into the same problem so far.

Thanks,
Yadu

---------- Forwarded message ----------
From: Karthikeyan Balasubramanian <karthikeyanb at uchicago.edu>
Date: Mon, Feb 2, 2015 at 1:00 PM
Subject: RE: [Swift-user] Swift-Java error: Block task failed: Connection
to worker lost
To: Yadu Nand <yadudoc1729 at gmail.com>


 Hi Yadu,

 Attached, please find the runNNN files from two runs. run001 failed on a
file, which I excluded in the second run, but still it failed with the
broken pipe issue.

 Thanks.
B.K.
 ------------------------------
*From:* Yadu Nand [yadudoc1729 at gmail.com]
*Sent:* Thursday, January 29, 2015 3:35 PM
*To:* Karthikeyan Balasubramanian
*Cc:* swift-user at ci.uchicago.edu
*Subject:* Re: [Swift-user] Swift-Java error: Block task failed: Connection
to worker lost

  Hi Karthikeyan,

 Could you send us the runNNN folder from the execution. If you are running
swift-0.94, sending
a tarball of all the logs from the run would help.

 Thanks.
Yadu


On Fri, Jan 23, 2015 at 7:47 PM, Karthikeyan Balasubramanian <
karthikeyanb at uchicago.edu> wrote:

>  Hi,
>
>  I am encountering the following error and subsequently Swift fails. The
> code runs and generates results for a while and then throws up this error.
> Browsing the swift-user forum, it appears that the issue is not completely
> new. But, I am unable to identify a suitable solution.
>
>  Caused by:
>         Block task failed: Connection to worker lost
> java.io.IOException: Broken pipe
>         at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
>         at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
>         at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
>         at sun.nio.ch.IOUtil.write(IOUtil.java:65)
>         at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
>         at
> org.globus.cog.karajan.workflow.service.channels.NIOSender.write(NIOSender.java:168)
>         at
> org.globus.cog.karajan.workflow.service.channels.NIOSender.run(NIOSender.java:133)
>
>  Thanks,
> B.K.
>
> _______________________________________________
> Swift-user mailing list
> Swift-user at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-user
>



 --
 Yadu Nand B




-- 
Yadu Nand B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150210/aa97eeba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run001.zip
Type: application/x-zip-compressed
Size: 119310 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150210/aa97eeba/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run002.zip
Type: application/x-zip-compressed
Size: 114011 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150210/aa97eeba/attachment-0001.bin>

From iraicu at cs.iit.edu  Fri Feb 13 04:39:14 2015
From: iraicu at cs.iit.edu (Ioan Raicu)
Date: Fri, 13 Feb 2015 04:39:14 -0600
Subject: [Swift-devel] CFP: IEEE Transaction on Cloud Computing,
 Special Issue on Many-Task Computing in the Cloud -- Due 03/13/2015
Message-ID: <54DDD452.8030203@cs.iit.edu>

Call for Papers

---------------------------------------------------------------------------------------
IEEE Transaction on Cloud Computing
Special Issue on Many-Task Computing in the Cloud
http://datasys.cs.iit.edu/events/TCC-MTC15/
=======================================================================================
The Special Issue on Many-Task Computing (MTC) in the Cloud will provide the scientific community a dedicated forum, within the prestigious IEEE Transactions on Cloud Computing journal, for presenting new research, development, and deployment efforts of loosely coupled large scale applications on Cloud Computing infrastructure. MTC, the theme of this special issue, encompasses loosely coupled applications, which are generally composed of many tasks to achieve some larger application goal. This special issue will cover challenges that can hamper efficiency and utilization in running applications on large-scale systems, such as local resource manager scalability and granularity, efficient utilization of raw hardware, parallel file-system contention and scalability, data management, I/O management, reliability at scale, and application scalability. We welcome paper submissions in theoretical, simulations, and systems topics with special consideration to papers addressing the intersection of petascale/exascale challenges with large-scale cloud computing. We seek submission of papers that present new, original and innovative ideas for the "first" time in TCC (Transactions on Cloud Computing). That means, submission of "extended versions" of already published works (e.g., conference/workshop papers) is not encouraged unless they contain significant number of "new and original" ideas/contributions along with more than 49% brand "new" material.

For more information on past workshops and special issues on Many-Task Computing, see http://datasys.cs.iit.edu/events/MTAGS/index.html. We ran a Special Issue on Many-Task Computing in the IEEE Transactions on Parallel and Distributed Systems (TPDS) which appeared in June 2011; the proceedings can be found online at http://www.computer.org/portal/web/csdl/abs/trans/td/2011/06/ttd201106toc.htm. The special issue editors also published a highly relevant paper that defines Many-Task Computing which was published in the inaugural MTAGS08 workshop, titled "Many-Task Computing for Grids and Supercomputers"; we encourage potential authors to read this paper, and to clearly articulate in your paper submissions how your papers are related to Many-Task Computing.

For more information on this special issue, please see http://datasys.cs.iit.edu/events/TCC-MTC15/.


Topics
---------------------------------------------------------------------------------------
We seek submission of papers that present new, original and innovative ideas for the "first" time in TCC (Transactions on Cloud Computing). That means, submission of "extended versions" of already published works (e.g., conference/workshop papers) will only be encouraged if they contain significant number of "new and original" ideas/contributions along with more than 49% brand "new" material. TCC expects submissions to be complete in all respects including author names, affiliation, bios etc. Manuscript should be 14 double column pages (all regular paper page limits include references and author biographies). We aim to cover topics related to Many-Task Computing and Cloud Computing. Topics of interest include:
* Compute Resource Management
   * Scheduling
   * Job execution frameworks
   * Local resource manager extensions
   * Performance evaluation of resource managers in use on large scale systems
   * Dynamic resource provisioning
   * Techniques to manage many-core resources and/or GPUs
   * Challenges and opportunities in running many-task workloads on Cloud Computing infrastructure
* Storage architectures and implementations
   * Distributed file systems
   * Parallel file systems
   * Distributed meta-data management
   * Content distribution systems for large data
   * Data caching frameworks and techniques
   * Data management within and across data centers
   * Data-aware scheduling
   * Data-intensive computing applications
   * Eventual-consistency storage usage and management
* Programming models and tools
   * Map-reduce and its generalizations
   * Many-task computing middleware and applications
   * Parallel programming frameworks
   * Ensemble MPI techniques and frameworks
   * Service-oriented science applications
* Large-Scale Workflow Systems
   * Workflow system performance and scalability analysis
   * Scalability of workflow systems
   * Workflow infrastructure and e-Science middleware
   * Programming Paradigms and Models
* Large-Scale Many-Task Applications
   * High-throughput computing (HTC) applications
   * Data-intensive applications
   * Quasi-supercomputing applications, deployments, and experiences
   * Performance Evaluation
* Performance evaluation
   * Real systems
   * Simulations
   * Reliability of large systems


Paper Submission and Publication
---------------------------------------------------------------------------------------

Authors are invited to submit unpublished and original work to the IEEE Transactions on Cloud Computing (TCC), Special Issue on Many-Task Computing in the Cloud. If the paper is extended from an initial work, the submission must contain at least 50% new material that can be qualified as ?brand? new ideas and results. The paper must be in the IEEE TCC format, namely 14 double-column pages or 30 single-column pages (Note: All regular paper page limits include references and author biographies). Please note that the double-column format will translate more readily into the final publication format. A double-column page is defined as a 7.875??10.75? page with 10-point type, 12-point vertical spacing, and 0.5 inch margins. A single-column page is defined as an 8.5??11? page with 12-point type and 24-point vertical spacing, containing approximately 250 words. All of the margins should be one inch (top, bottom, right and left). These length limits are taking into account reasonably-sized figures and references. Papers must be submitted using the submission system: https://mc.manuscriptcentral.com/tcc-cs, by selecting the special issue option ?SI-MTC?. For more information, please see http://datasys.cs.iit.edu/events/TCC-MTC15/. Email can be sent to the editors with further questions at mtc15-tcc-editors at datasys.cs.iit.edu.

Important Dates
---------------------------------------------------------------------------------------
*	Papers Due:					March 13th, 2015
* 	First round decisions:		June 1st, 2015
* 	Major Revisions if needed:	August 1st, 2015
* 	Final decisions:			September 1st, 2015
* 	Publication Date:			Fall 2015 (may vary depending on production queue)


Guest Editors (mtc15-tcc-editors at datasys.cs.iit.edu)
---------------------------------------------------------------------------------------
*	Ioan Raicu, Illinois Institute of Technology & Argonne National Laboratory
*	Justin Wozniak, University of Chicago & Argonne National Laboratory
*	Ian Foster, University of Chicago & Argonne National Laboratory
*	Yong Zhao, University of Electronic Science and Technology of China





From tim.g.armstrong at gmail.com  Fri Feb 13 15:42:15 2015
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Fri, 13 Feb 2015 15:42:15 -0600
Subject: [Swift-devel] Any type
Message-ID: <CAC0jiV7YB=1DuJ-P_pgdmAiquAoamXKZ79Rif6=+AJ18O-8Jug@mail.gmail.com>

Just following up on this.  My understanding was that this would be a
special type that is limited to builtin Java/Tcl function arguments.  I.e.
typing within Swift remains static and you can't instantiate a variable
with type any.

tl;dr version is: I think it's fine when used sparingly (serialization is a
good example).

My more detailed thoughts were:

   - It's straightforward to implement the typechecking in STC so that
   isn't a concern.
   - You can already do that with type variables in Swift/T, e.g. the
   repr() function that returns a string representation has type signature: <T>
   (string o) repr(T x).  We also have repr_array: <T> (string o[])
   repr_array(T A[]).   I'm not sure whether it would be better to stick
   with this approach in Swift/T (for the purposes of the standard library,
   there's no functional difference).
   - It may cause some confusion if programmers see the type and assume
   they will be able to instantiate *any x*; and have a dynamically typed
   variable.  This may just be a documentation issue.
   - We should try to only use it for functions where it can actually
   accept any type.  .  E.g. printf() in Swift/T isn't a good candidate,
   since, say, structs aren't a sensible argument to printf.  I.e. I think
   it's not ideal if the function implementation is something like: switch
   (type) {... default: printf("I don't like this type"); exit(1); }.
   Sometimes it's not possible to express something more nuanced in the
   type system, so it's difficult to always avoid.
   - If the function body is just going to be a switch (type) {...}, maybe
   it's best to do that in the compiler with overloading.  I think there are
   some cases where overloading isn't powerful enough: if you're recursively
   doing something like serialisation on a more complex data structure, or if
   you have multiple polymorphic arguments, then you can't enumerate all the
   cases with overloading.
   - We don't have runtime type information in Swift/T so it's a pain to
   implement functions that require it (there's a workaround with the compiler
   emitting type information for the function to parse, but it's ugly).

- Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150213/07d0383b/attachment.html>

From iraicu at cs.iit.edu  Sun Feb 15 08:14:57 2015
From: iraicu at cs.iit.edu (Ioan Raicu)
Date: Sun, 15 Feb 2015 08:14:57 -0600
Subject: [Swift-devel] CFP: IEEE Cluster 2015 -- Papers due 02/27/15
Message-ID: <54E0A9E1.80501@cs.iit.edu>

IEEE International Conference on Cluster Computing
September 8-11, 2015
Chicago, IL, USA
http://www.mcs.anl.gov/ieeecluster2015/

----------------------------------------------
...Follow us on Facebook athttps://www.facebook.com/ieee.cluster
...Follow us on Twitter athttps://twitter.com/IEEECluster
...Follow us on Linkedin at
https://www.linkedin.com/groups/IEEE-International-Conference-on-Cluster-7428925 

...Follow us on RenRen athttp://page.renren.com/601871401

----------------------------------------------
CALL FOR PAPERS

Following the successes of the series of Cluster conferences, for 2015
we solicit high-quality original papers presenting work that advances
the state-of-the-art in clusters and closely related fields. All
papers will be rigorously peer-reviewed for their originality,
technical depth and correctness, potential impact, relevance to the
conference, and quality of presentation. Research papers must clearly
demonstrate research contributions and novelty, while papers reporting
experience must clearly describe lessons learned and impact, along
with the utility of the approach compared to the ones in the past.

PAPER TRACKS
    *  Applications, Algorithms, and Libraries
    *  Architecture, Networks/Communication, and Management
    *  Programming and Systems Software
    *  Data, Storage, and Visualization

SUBMISSION GUIDELINES
Authors are invited to submit papers electronically in PDF format.
Submitted manuscripts should be structured as technical papers and may
not exceed 10 letter-size (8.5 x 11) pages including figures, tables
and references using the IEEE format for conference proceedings.
Submissions not conforming to these guidelines may be returned without
review. Authors should make sure that their file will print on a
printer that uses letter-size (8.5 x 11) paper. The official language
of the conference is English. All manuscripts will be reviewed and
will be judged on correctness, originality, technical strength,
significance, quality of presentation, and interest and relevance to
the conference attendees.
Paper submissions are limited to 10 pages in 2-column IEEE format
including all figures and references. Submitted manuscripts exceeding
this limit will be returned without review. For the final camera-ready
version, authors with accepted papers may purchase additional pages at
the following rates: 200 USD for each of two additional pages. See
formatting templates for details:

    *  LaTex Package
http://datasys.cs.iit.edu/events/CCGrid2014/IEEECS_confs_LaTeX.zip
    *  Word Template
http://datasys.cs.iit.edu/events/CCGrid2014/instruct8.5x11x2.doc and
http://datasys.cs.iit.edu/events/CCGrid2014/instruct8.5x11x2.pdf

Submitted papers must represent original unpublished research that is
not currently under review for any other conference or journal. Papers
not following these guidelines will be rejected without review and
further action may be taken, including (but not limited to)
notifications sent to the heads of the institutions of the authors and
sponsors of the conference. Submissions received after the due date,
exceeding the page limit, or not appropriately structured may not be
considered. Authors may contact the conference chairs for more
information. The proceedings will be published through the IEEE
Computer Society Conference Publishing Services.

Please submit your paper via the EasyChair submission system:
https://easychair.org/conferences/?conf=ieeecluster2015


JOURNAL SPECIAL ISSUE
The best papers of Cluster 2015 will be included in a Special Issue on
advances in topics related to cluster computing of the Elsevier
International Journal of Parallel Computing (PARCO), edited by Pavan
Balaji, Satoshi Matsuoka, and Michela Taufer. This special issue is
dedicated for the papers accepted in the Cluster 2015 conference. The
submission to this special issue is by invitation only.

IMPORTANT DATES
January 1, 2015 ........... Submissions open for Papers
February 27, 2015 ....... Papers Submission Deadline
April 23, 2015 ............... Papers Acceptance Notification
August 1, 2015 ............ Camera-ready Copy Deadline for Papers

See other important dates here
http://www.mcs.anl.gov/ieeecluster2015/author-information/important-dates/.

CLUSTER 2015 PROGRAM CHAIR
Satoshi Matsuoka, Tokyo Institute of Technology (matsu AT is.titech.ac.jp).

-- 
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Editor: IEEE TCC, Springer Cluster, Springer JoCCASA
Chair:  IEEE/ACM MTAGS, ACM ScienceCloud
=================================================================
Cel:      1-847-722-0876
Office:   1-312-567-5704
Email:    iraicu at cs.iit.edu
Web:      http://www.cs.iit.edu/~iraicu/
Web:      http://datasys.cs.iit.edu/
LinkedIn: http://www.linkedin.com/in/ioanraicu
Google:   http://scholar.google.com/citations?user=jE73HYAAAAAJ
=================================================================
=================================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150215/2c155e0e/attachment.html>

From wilde at anl.gov  Thu Feb 19 14:03:01 2015
From: wilde at anl.gov (Michael Wilde)
Date: Thu, 19 Feb 2015 14:03:01 -0600
Subject: [Swift-devel] General JSON doc editor for editing swift.conf
Message-ID: <54E64175.6020307@anl.gov>

Mihael, can you extend/adapt this tool to do the web-based editing of 
.conf files?

   http://jsoneditoronline.org/

Source code link is at bottom of page; Apache license.

- Mike

-- 
Michael Wilde
Mathematics and Computer Science          Computation Institute
Argonne National Laboratory               The University of Chicago



From iraicu at cs.iit.edu  Mon Feb 23 10:31:38 2015
From: iraicu at cs.iit.edu (Ioan Raicu)
Date: Mon, 23 Feb 2015 11:31:38 -0500
Subject: [Swift-devel] CFP: IEEE CLUSTER 2015 -- deadline extension March 7,
	2015
Message-ID: <54EB55EA.2000909@cs.iit.edu>

February 23, 2015 Release

IEEE International Conference on Cluster Computing
September 8-11, 2015
Chicago, IL, USA
http://www.mcs.anl.gov/ieeecluster2015/


CLUSTER 2015 CALL FOR PAPERS

Following the successes of the series of Cluster conferences, for 2015
we solicit high-quality original papers presenting work that advances
the state-of-the-art in clusters and closely related fields. All
papers will be rigorously peer-reviewed for their originality,
technical depth and correctness, potential impact, relevance to the
conference, and quality of presentation. Research papers must clearly
demonstrate research contributions and novelty, while papers reporting
experience must clearly describe lessons learned and impact, along
with the utility of the approach compared to the ones in the past.

*** Paper Tracks ***

Applications, Algorithms, and Libraries
Architecture, Networks/Communication, and Management
Programming and Systems Software
Data, Storage, and Visualization

*** Submission Guidelines ***

Authors are invited to submit papers electronically in PDF format.
Submitted manuscripts should be structured as technical papers and may
not exceed 10 letter-size (8.5 x 11) pages including figures, tables
and references using the IEEE format for conference proceedings.
Submissions not conforming to these guidelines may be returned without
review. Authors should make sure that their file will print on a
printer that uses letter-size (8.5 x 11) paper. The official language
of the conference is English. All manuscripts will be reviewed and
will be judged on correctness, originality, technical strength,
significance, quality of presentation, and interest and relevance to
the conference attendees.

Paper submissions are limited to 10 pages in 2-column IEEE format
including all figures and references. Submitted manuscripts exceeding
this limit will be returned without review. For the final camera-ready
version, authors with accepted papers may purchase additional pages at
the following rates: 200 USD for each of two additional pages. See
formatting templates for details:

LaTex Package ZIP
(http://datasys.cs.iit.edu/events/CCGrid2014/IEEECS_confs_LaTeX.zip)
Word Template DOC
(http://datasys.cs.iit.edu/events/CCGrid2014/instruct8.5x11x2.doc) and
PDF (http://datasys.cs.iit.edu/events/CCGrid2014/instruct8.5x11x2.pdf)

Submitted papers must represent original unpublished research that is
not currently under review for any other conference or journal. Papers
not following these guidelines will be rejected without review and
further action may be taken, including (but not limited to)
notifications sent to the heads of the institutions of the authors and
sponsors of the conference. Submissions received after the due date,
exceeding the page limit, or not appropriately structured may not be
considered. Authors may contact the conference chairs for more
information. The proceedings will be published through the IEEE
Computer Society Conference Publishing Services.

Please submit your paper via the EasyChair submission system:

https://easychair.org/conferences/?conf=ieeecluster2015

*** Journal Special Issue ***

The best papers of Cluster 2015 will be included in a Special Issue on
advances in topics related to cluster computing of the Elsevier
International Journal of Parallel Computing (PARCO), edited by Pavan
Balaji, Satoshi Matsuoka, and Michela Taufer. This special issue is
dedicated for the papers accepted in the Cluster 2015 conference. The
submission to this special issue is by invitation only.

*** Important Dates ***
***March 7, 2015***   Papers Submission Deadline
April 23, 2015          Papers Acceptance Notification

See other deadlines in the Important Dates page
(http://www.mcs.anl.gov/ieeecluster2015/author-information/important-dates)

*** Cluster 2015 Program Chair ***

Satoshi Matsuoka, Tokyo Institute of Technology (matsu AT is.titech.ac.jp).


----------------------------------------------
...Follow us on Facebook athttps://www.facebook.com/ieee.cluster
...Follow us on Twitter athttps://twitter.com/IEEECluster
...Follow us on Linkedin at
https://www.linkedin.com/groups/IEEE-International-Conference-on-Cluster-7428925
...Follow us on RenRen athttp://page.renren.com/601871401
----------------------------------------------

-- 
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Editor: IEEE TCC, Springer Cluster, Springer JoCCASA
Chair:  IEEE/ACM MTAGS, ACM ScienceCloud
=================================================================
Cel:      1-847-722-0876
Office:   1-312-567-5704
Email:    iraicu at cs.iit.edu
Web:      http://www.cs.iit.edu/~iraicu/
Web:      http://datasys.cs.iit.edu/
LinkedIn: http://www.linkedin.com/in/ioanraicu
Google:   http://scholar.google.com/citations?user=jE73HYAAAAAJ
=================================================================
=================================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150223/05c520ce/attachment.html>