From hategan at mcs.anl.gov Fri Jan 9 22:05:43 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Fri, 9 Jan 2015 20:05:43 -0800 Subject: [Swift-devel] Standard library Message-ID: <1420862743.10156.25.camel@echo> Hi, I compiled a list of functions in both K and T with comments here: https://trac.ci.uchicago.edu/swift/wiki/StandardLibrary Feel free to edit. I think that both T and K are at about the same level of quality in terms of naming consistency (within their own group of functions), completeness, and functional consistency, with T getting slightly more points. In other words I think that both need work. Here's a list of things that are quickly obvious: - CamelCase vs. nothinginparticular vs. under_score: the real problem here is that, aside from the one in the middle, none is better than the other, and I favor CamelCase while Tim and Justin will probably not want to let go of the underscores. Maybe. I doubt either of us care that much. But let's not fall into the trap of debating it. - Overloading. While I don't think either T or K support user-defined polymorphic functions, they both seem to support it for library functions to some extent. I am of the opinion that a strongly typed language *should* make use of polymorphism. And that we should eventually allow users to overload functions. - exp(), pow(), etc., but no sin(), cos(), tan(), arcx() (K has none of these) - no regexps in T, no non-regexp split in K. - no toLower toUpper in either. - very few (if any) array functions, such as slices, join, split, search, etc. The situation is understandable. Swift's (both of them) war has been on other fronts. But I do not think, at this point, that the solution lies in either adopting what the other does and calling it a day. I think that both can get a better set of standard functions and that we can work together to come up (where necessary) with basically the same set of things. In doing so, I think what MIke said made sense: pick a decent language and mirror what it does, though I suspect that it will not necessarily be easy to agree on such a language. Mihael From tim.g.armstrong at gmail.com Sat Jan 10 16:57:16 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Sat, 10 Jan 2015 16:57:16 -0600 Subject: [Swift-devel] Standard library In-Reply-To: <1420862743.10156.25.camel@echo> References: <1420862743.10156.25.camel@echo> Message-ID: Nice work. I agree, I don't care about the naming convention for functions, so let's just pick one and be consistent going forward (we can keep old names around, at least forsome amount of time). I'm also of the opinion that we should avoid strcat and other c-inspired names since they don't fit the naming convention and probably are only familiar for a minority of users. We do support user-defined polymorphic Tcl functions to some extent - option types, type variables (e.g. the type signature for contains is (boolean o) contains(V A[K], K key), and variable length argument lists. We don't pass type information into the function, so if you want the function to do something different for each type you can't do that. My understanding is that that's fairly straightforward in Swift/K since the function can just look at the Swift type of the Java object it's passed. The polymorphism is compile-time (the compiler always knows the type of each variable and expression). I'm a little sceptical of using too much polymorphism in library functions because it prevents type-checking from catching errors. I think it's fine if the function actually does conceptually the same thing for each input type (e.g. converting them to a string representation), but it's less of a good idea if it does different things (e.g. converting a float to an int and a string to an int are different operations). There's a bit of personal taste to whether you do these things, but I think once you allow looser typing rules,it's hard to undo that decision. RE: function overloading. I think we have to choose between optional/default arguments and function overloading - I think implementing one would preclude the other. - Tim On Fri, Jan 9, 2015 at 10:05 PM, Mihael Hategan wrote: > Hi, > > I compiled a list of functions in both K and T with comments here: > https://trac.ci.uchicago.edu/swift/wiki/StandardLibrary > > Feel free to edit. > > I think that both T and K are at about the same level of quality in > terms of naming consistency (within their own group of functions), > completeness, and functional consistency, with T getting slightly more > points. > > In other words I think that both need work. Here's a list of things that > are quickly obvious: > > - CamelCase vs. nothinginparticular vs. under_score: the real problem > here is that, aside from the one in the middle, none is better than the > other, and I favor CamelCase while Tim and Justin will probably not want > to let go of the underscores. Maybe. I doubt either of us care that > much. But let's not fall into the trap of debating it. > > - Overloading. While I don't think either T or K support user-defined > polymorphic functions, they both seem to support it for library > functions to some extent. I am of the opinion that a strongly typed > language *should* make use of polymorphism. And that we should > eventually allow users to overload functions. > > - exp(), pow(), etc., but no sin(), cos(), tan(), arcx() (K has none of > these) > > - no regexps in T, no non-regexp split in K. > > - no toLower toUpper in either. > > - very few (if any) array functions, such as slices, join, split, > search, etc. > > The situation is understandable. Swift's (both of them) war has been on > other fronts. But I do not think, at this point, that the solution lies > in either adopting what the other does and calling it a day. I think > that both can get a better set of standard functions and that we can > work together to come up (where necessary) with basically the same set > of things. > > In doing so, I think what MIke said made sense: pick a decent language > and mirror what it does, though I suspect that it will not necessarily > be easy to agree on such a language. > > 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: From hategan at mcs.anl.gov Sat Jan 10 21:33:47 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Sat, 10 Jan 2015 19:33:47 -0800 Subject: [Swift-devel] Standard library In-Reply-To: References: <1420862743.10156.25.camel@echo> Message-ID: <1420947227.19970.18.camel@echo> Inline... On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote: > Nice work. > > I agree, I don't care about the naming convention for functions, so let's > just pick one and be consistent going forward (we can keep old names > around, at least forsome amount of time). I'm also of the opinion that we > should avoid strcat and other c-inspired names since they don't fit the > naming convention and probably are only familiar for a minority of users. I agree on strcat, etc. > > We do support user-defined polymorphic Tcl functions to some extent - > option types, type variables (e.g. the type signature for contains is V> (boolean o) contains(V A[K], K key), and variable length argument > lists. We don't pass type information into the function, so if you want > the function to do something different for each type you can't do that. My > understanding is that that's fairly straightforward in Swift/K since the > function can just look at the Swift type of the Java object it's passed. You say user-defined and Tcl. Does this mean a user writing Tcl inside a swift script or that the mechanism to extend swift using Tcl is documented and generally accessible to users? And yes, the type is passed to Java. I'd like to change that to proper compile-time binding. It's not difficult, just not a priority right now. However, how do avg(int[]) and avg(float[]) work in T? > > The polymorphism is compile-time (the compiler always knows the type of > each variable and expression). I'm a little sceptical of using too much > polymorphism in library functions because it prevents type-checking from > catching errors. I think it's fine if the function actually does > conceptually the same thing for each input type (e.g. converting them to a > string representation), but it's less of a good idea if it does different > things (e.g. converting a float to an int and a string to an int are > different operations). There's a bit of personal taste to whether you do > these things, but I think once you allow looser typing rules,it's hard to > undo that decision. I agree with what you are saying. I believe that abs/min/max/etc. can be polymorphic without much danger. I think that length(string) and length(array) are also reasonable. But I can see the wisdom in having parseFloat(string) instead of overloading toFloat(int). On the other hand, if you wanted to name them more declaratively, they would probably both sound more like asFloat(). > > RE: function overloading. I think we have to choose between > optional/default arguments and function overloading - I think implementing > one would preclude the other. I'm not sure about that. There may be some (non-transitive) ambiguity between: f(int a) vs. f(int a, int b = 0) vs. f(int a, int b). A compiler could complain about the conflict between the middle one and the rest. But I don't see a problem with: f(int a), f(float a). Am I missing something? Mihael From hategan at mcs.anl.gov Sat Jan 10 22:02:16 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Sat, 10 Jan 2015 20:02:16 -0800 Subject: [Swift-devel] Standard library In-Reply-To: References: <1420862743.10156.25.camel@echo> Message-ID: <1420948936.20377.11.camel@echo> On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote: > I agree, I don't care about the naming convention for functions, so let's > just pick one and be consistent going forward (we can keep old names > around, at least forsome amount of time). Let's briefly discuss this and put it to a vote. I prefer camel case because it helps with tokenization in my head. In other words when I read a program, I would like a variable or function name to be a single entity visually. Underscores are very close to a blank, so it's easy to confuse the two on a quick visual scan and interpret, say function_name, as two separate tokens instead of one. Other than that, complex tokens themselves are probably easier to read with underscores: long_name_of_variable_that_holds_value vs longNameOfVariableThatHoldsValue. See http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9499 and http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf for some relevant research. Unfortunately they focus not on program readability, but on identifier readability. Mihael From tim.g.armstrong at gmail.com Sat Jan 10 22:57:17 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Sat, 10 Jan 2015 22:57:17 -0600 Subject: [Swift-devel] Standard library In-Reply-To: <1420947227.19970.18.camel@echo> References: <1420862743.10156.25.camel@echo> <1420947227.19970.18.camel@echo> Message-ID: On Sat, Jan 10, 2015 at 9:33 PM, Mihael Hategan wrote: > Inline... > > On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote: > > Nice work. > > > > I agree, I don't care about the naming convention for functions, so let's > > just pick one and be consistent going forward (we can keep old names > > around, at least forsome amount of time). I'm also of the opinion that > we > > should avoid strcat and other c-inspired names since they don't fit the > > naming convention and probably are only familiar for a minority of users. > > I agree on strcat, etc. > > > > > We do support user-defined polymorphic Tcl functions to some extent - > > option types, type variables (e.g. the type signature for contains is > V> (boolean o) contains(V A[K], K key), and variable length argument > > lists. We don't pass type information into the function, so if you want > > the function to do something different for each type you can't do that. > My > > understanding is that that's fairly straightforward in Swift/K since the > > function can just look at the Swift type of the Java object it's passed. > > You say user-defined and Tcl. Does this mean a user writing Tcl inside a > swift script or that the mechanism to extend swift using Tcl is > documented and generally accessible to users? > Both, really. Justin and Ketan did a lot of work on documenting it. The standard library is a bunch of swift files + Tcl code implementing the functions. > And yes, the type is passed to Java. I'd like to change that to proper > compile-time binding. It's not difficult, just not a priority right now. > However, how do avg(int[]) and avg(float[]) work in T? > The same Tcl code runs in both cases, and the mathematical operations dispatch on the runtime type. The way Tcl handles this is somewhat different though - it's weakly typed and freely converts things between strings and other types. This works ok for average, but if the code actually needs to determine the intended input type it can't. > > > > > The polymorphism is compile-time (the compiler always knows the type of > > each variable and expression). I'm a little sceptical of using too much > > polymorphism in library functions because it prevents type-checking from > > catching errors. I think it's fine if the function actually does > > conceptually the same thing for each input type (e.g. converting them to > a > > string representation), but it's less of a good idea if it does different > > things (e.g. converting a float to an int and a string to an int are > > different operations). There's a bit of personal taste to whether you do > > these things, but I think once you allow looser typing rules,it's hard to > > undo that decision. > > I agree with what you are saying. I believe that abs/min/max/etc. can be > polymorphic without much danger. I think that length(string) and > length(array) are also reasonable. > > But I can see the wisdom in having parseFloat(string) instead of > overloading toFloat(int). > > On the other hand, if you wanted to name them more declaratively, they > would probably both sound more like asFloat(). > Yeah, I may be being overly pedantic about that, I think it's nicer in some ways having short and consistent names. > > > > > RE: function overloading. I think we have to choose between > > optional/default arguments and function overloading - I think > implementing > > one would preclude the other. > > I'm not sure about that. There may be some (non-transitive) ambiguity > between: > > f(int a) vs. f(int a, int b = 0) vs. f(int a, int b). > > A compiler could complain about the conflict between the middle one and > the rest. But I don't see a problem with: > > f(int a), f(float a). > > Am I missing something? > I think the problem I was thinking of is the combination of function overloading and keyword arguments - then you have a number of possible function signatures that grows exponentially with the number of optional arguments. It's not so bad if it's purely positional arguments since then you can just treat a function with n optional arguments as n + 1 overloads of the function. It might take a bit of implementation work to get to work with the other function type checking logic in Swift/T, but it seems tractable. It's already a bit complicated trying to work out the input types of the function arguments when there's the possibility of type variables, option types, etc. There are some weird corner cases. For example, which implementation of avg would this call? avg([]); - Tim > Mihael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.g.armstrong at gmail.com Sat Jan 10 22:57:49 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Sat, 10 Jan 2015 22:57:49 -0600 Subject: [Swift-devel] Standard library In-Reply-To: <1420948936.20377.11.camel@echo> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> Message-ID: I'm actually pretty indifferent :) I switch between the two styles so much anyway. - Tim On Sat, Jan 10, 2015 at 10:02 PM, Mihael Hategan wrote: > On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote: > > I agree, I don't care about the naming convention for functions, so let's > > just pick one and be consistent going forward (we can keep old names > > around, at least forsome amount of time). > > Let's briefly discuss this and put it to a vote. > > I prefer camel case because it helps with tokenization in my head. In > other words when I read a program, I would like a variable or function > name to be a single entity visually. Underscores are very close to a > blank, so it's easy to confuse the two on a quick visual scan and > interpret, say function_name, as two separate tokens instead of one. > > Other than that, complex tokens themselves are probably easier to read > with underscores: long_name_of_variable_that_holds_value vs > longNameOfVariableThatHoldsValue. > > See http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9499 and > > http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf > for some relevant research. Unfortunately they focus not on program > readability, but on identifier readability. > > Mihael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Sat Jan 10 23:40:30 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Sat, 10 Jan 2015 21:40:30 -0800 Subject: [Swift-devel] Standard library In-Reply-To: References: <1420862743.10156.25.camel@echo> <1420947227.19970.18.camel@echo> Message-ID: <1420954830.21115.18.camel@echo> On Sat, 2015-01-10 at 22:57 -0600, Tim Armstrong wrote: > > Am I missing something? > > > I think the problem I was thinking of is the combination of function > overloading and keyword arguments - then you have a number of possible > function signatures that grows exponentially with the number of optional > arguments. It's not so bad if it's purely positional arguments since then > you can just treat a function with n optional arguments as n + 1 overloads > of the function. I'm not sure. You should be able to statically determine which keyword arguments are passed in a given call, fill the missing ones with nulls or default values, sort, and generate a call to a single purely positional underlying implementation. > > It might take a bit of implementation work to get to work with the other > function type checking logic in Swift/T, but it seems tractable. It's > already a bit complicated trying to work out the input types of the > function arguments when there's the possibility of type variables, option > types, etc. Shouldn't polymorphism come before fancy type stuff? :) > > There are some weird corner cases. For example, which implementation of > avg would this call? > avg([]); Unless there is some mechanism that can ensure that it doesn't matter, or a mechanism allowing you to overload based on specific values (like pattern matching), then you probably have to have a way to say exactly which function should be called. Java requires you to do an explicit cast of arguments that would otherwise result in ambiguity. Mihael From hategan at mcs.anl.gov Sat Jan 10 23:41:32 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Sat, 10 Jan 2015 21:41:32 -0800 Subject: [Swift-devel] Naming convention discussion In-Reply-To: References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> Message-ID: <1420954892.21115.19.camel@echo> Just changing subject to reduce confusion. On Sat, 2015-01-10 at 22:57 -0600, Tim Armstrong wrote: > I'm actually pretty indifferent :) I switch between the two styles so much > anyway. > > - Tim > > On Sat, Jan 10, 2015 at 10:02 PM, Mihael Hategan > wrote: > > > On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote: > > > I agree, I don't care about the naming convention for functions, so let's > > > just pick one and be consistent going forward (we can keep old names > > > around, at least forsome amount of time). > > > > Let's briefly discuss this and put it to a vote. > > > > I prefer camel case because it helps with tokenization in my head. In > > other words when I read a program, I would like a variable or function > > name to be a single entity visually. Underscores are very close to a > > blank, so it's easy to confuse the two on a quick visual scan and > > interpret, say function_name, as two separate tokens instead of one. > > > > Other than that, complex tokens themselves are probably easier to read > > with underscores: long_name_of_variable_that_holds_value vs > > longNameOfVariableThatHoldsValue. > > > > See http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9499 and > > > > http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf > > for some relevant research. Unfortunately they focus not on program > > readability, but on identifier readability. > > > > Mihael > > > > From ketan at mcs.anl.gov Sun Jan 11 21:06:49 2015 From: ketan at mcs.anl.gov (Ketan Maheshwari) Date: Sun, 11 Jan 2015 21:06:49 -0600 Subject: [Swift-devel] Naming convention discussion In-Reply-To: <1420954892.21115.19.camel@echo> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> Message-ID: I think uniformity is good but not at the cost of readability/familiarity. Names with both camel case and underscores could be allowed on case by case basis. In some cases even common C-like function names such as strcat, sqrt etc. might be allowed. Users who have even a little familiarity with C will probably know what strcat, pow etc. functions do. So, I am more inclined towards letting go of uniformity in favor of familiarity. Just my opinion. On Sat, Jan 10, 2015 at 11:41 PM, Mihael Hategan wrote: > Just changing subject to reduce confusion. > > On Sat, 2015-01-10 at 22:57 -0600, Tim Armstrong wrote: > > I'm actually pretty indifferent :) I switch between the two styles so > much > > anyway. > > > > - Tim > > > > On Sat, Jan 10, 2015 at 10:02 PM, Mihael Hategan > > wrote: > > > > > On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote: > > > > I agree, I don't care about the naming convention for functions, so > let's > > > > just pick one and be consistent going forward (we can keep old names > > > > around, at least forsome amount of time). > > > > > > Let's briefly discuss this and put it to a vote. > > > > > > I prefer camel case because it helps with tokenization in my head. In > > > other words when I read a program, I would like a variable or function > > > name to be a single entity visually. Underscores are very close to a > > > blank, so it's easy to confuse the two on a quick visual scan and > > > interpret, say function_name, as two separate tokens instead of one. > > > > > > Other than that, complex tokens themselves are probably easier to read > > > with underscores: long_name_of_variable_that_holds_value vs > > > longNameOfVariableThatHoldsValue. > > > > > > See http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9499 > and > > > > > > > http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf > > > for some relevant research. Unfortunately they focus not on program > > > readability, but on identifier readability. > > > > > > 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: From tim.g.armstrong at gmail.com Sun Jan 11 21:48:46 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Sun, 11 Jan 2015 21:48:46 -0600 Subject: [Swift-devel] Standard library In-Reply-To: <1420954830.21115.18.camel@echo> References: <1420862743.10156.25.camel@echo> <1420947227.19970.18.camel@echo> <1420954830.21115.18.camel@echo> Message-ID: You can use a positional implementation for sure as long as the caller knows the argument names of the function it's calling at compile time. You can't reduce it to the problem of resolving overloads for functions with purely positional arguments though, since that would require there being a single consistent mapping of -> across all of the overloaded ones. You could have it try all of the overloads individually and see which ones matched, but by that point I think it's too complicated to be worth it. It would also have the downside that it's harder to work out if two overloads are potentially ambiguous at the function declaration site (it's not too bad at the call site - if you have more than one match, it's ambiguous). E.g. if I defined f(float x=0.0, int y=0) and someone writes code with a call to f(y=0); Now, if I added another overload f(int y=0), presumably the compiler wouldn't detect the overloads as ambiguous, since most ways of calling either are not, but then the call f(y=0) would break, since it's now ambiguous. Not great for modularity. I guess this got into a pretty academic discussion, but I do feel like keyword arguments and overloading don't play nicely together, and I do remember someone requesting keyword arguments at one point. With polymorphism, what do you mean by polymorphism though? I'd think of option types and type variables as one form of polymorphism among many, and probably the most natural one for a statically typed functional language. It comes up naturally - if you have a function like contains(array, array_element), then the type really should require that the arguments have types T[] and T. The alternatives were to either special-case it in the compile (not supporting it for user-defined functions and forcing compiler changes for every addition operator), or by just giving on typechecking and letting the caller pass in anything as long as the first argument is an array. The first would have been workable, but a bit limiting, and the second would have opened up a can of worms, since then it's possible to compare variables of completely different types and you have to work out what the equality rules are. E.g., what does contains([1.0, 2.0], 1) do? Anyway, with the avg([]) thing, my point was that the more features, the more corner cases come up. Rejecting anything ambiguous is mostly the right thing to do I think. In Swift/T it actually gets resolved to an int[], for the same reason that int A[]; A = []; passes type-checking - the expression [] has a wildcard in the type: *[]. On Sat, Jan 10, 2015 at 11:40 PM, Mihael Hategan wrote: > On Sat, 2015-01-10 at 22:57 -0600, Tim Armstrong wrote: > > > Am I missing something? > > > > > I think the problem I was thinking of is the combination of function > > overloading and keyword arguments - then you have a number of possible > > function signatures that grows exponentially with the number of optional > > arguments. It's not so bad if it's purely positional arguments since > then > > you can just treat a function with n optional arguments as n + 1 > overloads > > of the function. > > I'm not sure. You should be able to statically determine which keyword > arguments are passed in a given call, fill the missing ones with nulls > or default values, sort, and generate a call to a single purely > positional underlying implementation. > > > > > It might take a bit of implementation work to get to work with the other > > function type checking logic in Swift/T, but it seems tractable. It's > > already a bit complicated trying to work out the input types of the > > function arguments when there's the possibility of type variables, option > > types, etc. > > Shouldn't polymorphism come before fancy type stuff? :) > > > > > There are some weird corner cases. For example, which implementation of > > avg would this call? > > avg([]); > > Unless there is some mechanism that can ensure that it doesn't matter, > or a mechanism allowing you to overload based on specific values (like > pattern matching), then you probably have to have a way to say exactly > which function should be called. Java requires you to do an explicit > cast of arguments that would otherwise result in ambiguity. > > Mihael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Sun Jan 11 23:19:19 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Sun, 11 Jan 2015 21:19:19 -0800 Subject: [Swift-devel] Standard library In-Reply-To: References: <1420862743.10156.25.camel@echo> <1420947227.19970.18.camel@echo> <1420954830.21115.18.camel@echo> Message-ID: <1421039959.1165.44.camel@echo> On Sun, 2015-01-11 at 21:48 -0600, Tim Armstrong wrote: > You can use a positional implementation for sure as long as the caller > knows the argument names of the function it's calling at compile time. > You can't reduce it to the problem of resolving overloads for functions > with purely positional arguments though, since that would require there > being a single consistent mapping of -> > across all of the overloaded ones. I see what you are saying. I didn't think that far. > > You could have it try all of the overloads individually and see which ones > matched, but by that point I think it's too complicated to be worth it. Matching seems reasonable though. You have to do the matching anyway as part of type checking. > > It would also have the downside that it's harder to work out if two > overloads are potentially ambiguous at the function declaration site (it's > not too bad at the call site - if you have more than one match, it's > ambiguous). E.g. if I defined f(float x=0.0, int y=0) and someone writes > code with a call to f(y=0); Now, if I added another overload f(int y=0), > presumably the compiler wouldn't detect the overloads as ambiguous, since > most ways of calling either are not, but then the call f(y=0) would break, > since it's now ambiguous. Not great for modularity. There is the potential of ambiguous calls if the positional types are identical and there is an overlap between keyword args. In your case both lack positionals and both have an int y. That assuming no subtyping. The overlap part is slightly more difficult than the direct match. But it can reasonably be detected with defined functions. > > I guess this got into a pretty academic discussion, but I do feel like > keyword arguments and overloading don't play nicely together, and I do > remember someone requesting keyword arguments at one point. > I think there's an enhancement request in bugzilla for overloading. I don't know..., I mean yeah, this is pretty academic, but the question about whether we will support overloading needs to be answered if we are to come up with a decent common standard library that won't be a moving target. Well, it's a matter of consistency in K, since run-time overloading in library functions is supported. > > With polymorphism, what do you mean by polymorphism though? Right there I meant just function overloading. Sorry. > I'd think of > option types and type variables as one form of polymorphism among many, and > probably the most natural one for a statically typed functional language. > > It comes up naturally - if you have a function like contains(array, > array_element), then the type really should require that the arguments have > types T[] and T. The alternatives were to either special-case it in the > compile (not supporting it for user-defined functions and forcing compiler > changes for every addition operator), or by just giving on typechecking and > letting the caller pass in anything as long as the first argument is an > array. > > The first would have been workable, but a bit limiting, and the second > would have opened up a can of worms, since then it's possible to compare > variables of completely different types and you have to work out what the > equality rules are. E.g., what does contains([1.0, 2.0], 1) do? That still compiles in Java actually, even with generics. But then Java nailed the equality rules part fairly well. [...] Mihael From tim.g.armstrong at gmail.com Mon Jan 12 10:21:40 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Mon, 12 Jan 2015 10:21:40 -0600 Subject: [Swift-devel] Naming convention discussion In-Reply-To: References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> Message-ID: If you're in favour of camel case, Mihael, I'd support that. I guess it saves a few characters :). sqrt and pow are pretty much universal, so I agree with that. I think it's a little tricky to work out whether to abbreviate or not in general (e.g. length versus len). Though, strcat, strlen, etc are really a C-ism that a few languages have copied (Perl, PHP as far as I know for mainstream languages). Most languages don't follow that naming scheme so almost all users would have used a language where the str* naming convention wasn't used, and many users would have never used a language where the str* naming convention was used. So I don't think familiarity is enough of a factor to justify being inconsistent in our naming. On Sun, Jan 11, 2015 at 9:06 PM, Ketan Maheshwari wrote: > I think uniformity is good but not at the cost of readability/familiarity. > Names with both camel case and underscores could be allowed on case by case > basis. In some cases even common C-like function names such as strcat, sqrt > etc. might be allowed. Users who have even a little familiarity with C will > probably know what strcat, pow etc. functions do. So, I am more inclined > towards letting go of uniformity in favor of familiarity. Just my opinion. > > On Sat, Jan 10, 2015 at 11:41 PM, Mihael Hategan > wrote: > >> Just changing subject to reduce confusion. >> >> On Sat, 2015-01-10 at 22:57 -0600, Tim Armstrong wrote: >> > I'm actually pretty indifferent :) I switch between the two styles so >> much >> > anyway. >> > >> > - Tim >> > >> > On Sat, Jan 10, 2015 at 10:02 PM, Mihael Hategan >> > wrote: >> > >> > > On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote: >> > > > I agree, I don't care about the naming convention for functions, so >> let's >> > > > just pick one and be consistent going forward (we can keep old names >> > > > around, at least forsome amount of time). >> > > >> > > Let's briefly discuss this and put it to a vote. >> > > >> > > I prefer camel case because it helps with tokenization in my head. In >> > > other words when I read a program, I would like a variable or function >> > > name to be a single entity visually. Underscores are very close to a >> > > blank, so it's easy to confuse the two on a quick visual scan and >> > > interpret, say function_name, as two separate tokens instead of one. >> > > >> > > Other than that, complex tokens themselves are probably easier to read >> > > with underscores: long_name_of_variable_that_holds_value vs >> > > longNameOfVariableThatHoldsValue. >> > > >> > > See http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9499 >> and >> > > >> > > >> http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf >> > > for some relevant research. Unfortunately they focus not on program >> > > readability, but on identifier readability. >> > > >> > > 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: From tim.g.armstrong at gmail.com Mon Jan 12 11:45:28 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Mon, 12 Jan 2015 11:45:28 -0600 Subject: [Swift-devel] Standard library In-Reply-To: <1421039959.1165.44.camel@echo> References: <1420862743.10156.25.camel@echo> <1420947227.19970.18.camel@echo> <1420954830.21115.18.camel@echo> <1421039959.1165.44.camel@echo> Message-ID: I'm still not sure what you'd do with situationally ambiguous functions though. E.g. with the following f(float x=0.0, int y=0) f(int y=0) Neither dominates the other, since f(0.0, 0) and f(0) would get dispatched to the first and second. So it's not like it's obviously wrong code that should be an automatic compile error. I'm not sure if there is an algorithm in general to detect partially ambiguous functions (depending on details of the type system). If there was you could try to warn or error on partially ambiguous functions, although providing comprehensible explanations of the problem might be an issue. I think supporting overloading only for specific built-ins isn't such a bad thing (we do that for arithmetic operators, for example). I think some users might find it preferable to define overloads f(int) and f(float), but they can achieve the same effect with fInt(int) and fFloat(float), even if it's less aesthetically pleasing. You could say the same for my type variable thing I guess too - just special case it in the compiler for size() and contains(). Then there would be a limited number of special additional functions like map(), reduce(), etc, that could be special-cased. But there's no way then that you can achieve the same effect with a finite number of function definitions - you'd have to have an overload for every possible type, or just special-case it in the compiler. Java sort of gives up on typechecking in that case and just calls .equals(Object). They didn't really have much of a choice since that was baked in before they had generics. It's at least simple enough but it's definitely made it easier for bugs to go uncaught in STC, for example - I think there have been at least 15-20 things that I've had to track down that have boiled down to equals being called on two types that aren't comparable. On Sun, Jan 11, 2015 at 11:19 PM, Mihael Hategan wrote: > On Sun, 2015-01-11 at 21:48 -0600, Tim Armstrong wrote: > > You can use a positional implementation for sure as long as the caller > > knows the argument names of the function it's calling at compile time. > > You can't reduce it to the problem of resolving overloads for functions > > with purely positional arguments though, since that would require there > > being a single consistent mapping of -> position> > > across all of the overloaded ones. > > I see what you are saying. I didn't think that far. > > > > > You could have it try all of the overloads individually and see which > ones > > matched, but by that point I think it's too complicated to be worth it. > > Matching seems reasonable though. You have to do the matching anyway as > part of type checking. > > > > > It would also have the downside that it's harder to work out if two > > overloads are potentially ambiguous at the function declaration site > (it's > > not too bad at the call site - if you have more than one match, it's > > ambiguous). E.g. if I defined f(float x=0.0, int y=0) and someone > writes > > code with a call to f(y=0); Now, if I added another overload f(int y=0), > > presumably the compiler wouldn't detect the overloads as ambiguous, since > > most ways of calling either are not, but then the call f(y=0) would > break, > > since it's now ambiguous. Not great for modularity. > > There is the potential of ambiguous calls if the positional types are > identical and there is an overlap between keyword args. In your case > both lack positionals and both have an int y. That assuming no > subtyping. The overlap part is slightly more difficult than the direct > match. But it can reasonably be detected with defined functions. > > > > > I guess this got into a pretty academic discussion, but I do feel like > > keyword arguments and overloading don't play nicely together, and I do > > remember someone requesting keyword arguments at one point. > > > > I think there's an enhancement request in bugzilla for overloading. I > don't know..., I mean yeah, this is pretty academic, but the question > about whether we will support overloading needs to be answered if we are > to come up with a decent common standard library that won't be a moving > target. Well, it's a matter of consistency in K, since run-time > overloading in library functions is supported. > > > > > With polymorphism, what do you mean by polymorphism though? > > Right there I meant just function overloading. Sorry. > > > I'd think of > > option types and type variables as one form of polymorphism among many, > and > > probably the most natural one for a statically typed functional language. > > > > It comes up naturally - if you have a function like contains(array, > > array_element), then the type really should require that the arguments > have > > types T[] and T. The alternatives were to either special-case it in the > > compile (not supporting it for user-defined functions and forcing > compiler > > changes for every addition operator), or by just giving on typechecking > and > > letting the caller pass in anything as long as the first argument is an > > array. > > > > The first would have been workable, but a bit limiting, and the second > > would have opened up a can of worms, since then it's possible to compare > > variables of completely different types and you have to work out what the > > equality rules are. E.g., what does contains([1.0, 2.0], 1) do? > > That still compiles in Java actually, even with generics. But then Java > nailed the equality rules part fairly well. > > [...] > > Mihael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Mon Jan 12 12:24:46 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 12 Jan 2015 10:24:46 -0800 Subject: [Swift-devel] Standard library In-Reply-To: References: <1420862743.10156.25.camel@echo> <1420947227.19970.18.camel@echo> <1420954830.21115.18.camel@echo> <1421039959.1165.44.camel@echo> Message-ID: <1421087086.17260.20.camel@echo> On Mon, 2015-01-12 at 11:45 -0600, Tim Armstrong wrote: > I'm still not sure what you'd do with situationally ambiguous functions > though. > > E.g. with the following > f(float x=0.0, int y=0) > f(int y=0) > > Neither dominates the other, since f(0.0, 0) and f(0) would get dispatched > to the first and second. So it's not like it's obviously wrong code that > should be an automatic compile error. I think rejecting such cases is fine. With or without overloading +keyword args, such pairs of functions wouldn't be allowed. But with overloading+keyword args, there is more flexibility and certain things can be written more elegantly than without. So overloading adds things and doesn't prevent any of the things that are possible without. > I'm not sure if there is an > algorithm in general to detect partially ambiguous functions (depending on > details of the type system). If there was you could try to warn or error > on partially ambiguous functions, although providing comprehensible > explanations of the problem might be an issue. Right. This makes sense under the assumption that you can nicely deal with ambiguity. I believe it's possible and not terribly difficult, but it's just a hunch. > > I think supporting overloading only for specific built-ins isn't such a bad > thing (we do that for arithmetic operators, for example). I think some > users might find it preferable to define overloads f(int) and f(float), but > they can achieve the same effect with fInt(int) and fFloat(float), even if > it's less aesthetically pleasing. Ok. Let's start there. For the purpose of a common standard library, that's all we need. We can later look into the feasibility of also doing this for user-defined functions. > > You could say the same for my type variable thing I guess too - just > special case it in the compiler for size() and contains(). Then there > would be a limited number of special additional functions like map(), > reduce(), etc, that could be special-cased. But there's no way then that > you can achieve the same effect with a finite number of function > definitions - you'd have to have an overload for every possible type, or > just special-case it in the compiler. I like type variables. I'm not arguing against them. Just that in my head, they were a step or two up the ladder of fanciness from function overloading. > > Java sort of gives up on typechecking in that case and just calls > .equals(Object). They didn't really have much of a choice since that was > baked in before they had generics. It's a mixed blessing. It gives flexibility of defining equality classes across different types, but that is rarely used IMO. As you say though, that is probably an accidental feature. > It's at least simple enough but it's > definitely made it easier for bugs to go uncaught in STC, for example - I > think there have been at least 15-20 things that I've had to track down > that have boiled down to equals being called on two types that aren't > comparable. Right. It's not an easy problem. Comparable solves some of that, but not much. Mihael From hategan at mcs.anl.gov Mon Jan 12 22:25:59 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 12 Jan 2015 20:25:59 -0800 Subject: [Swift-devel] Naming convention discussion [VOTE] In-Reply-To: References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> Message-ID: <1421123159.2226.11.camel@echo> Allright, unless anybody else has anything to say, let's do an informal vote and see what happens. We're voting on whether the naming convention for functions should be camel case or underscores. This applies to future names when otherwise a choice would exist and does not preclude exceptions when there is a good reason to have them. This should also apply to the convention we use for future documentation. Mihael From tim.g.armstrong at gmail.com Tue Jan 13 12:20:49 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Tue, 13 Jan 2015 12:20:49 -0600 Subject: [Swift-devel] Naming convention discussion [VOTE] In-Reply-To: <1421123159.2226.11.camel@echo> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> Message-ID: I vote for camel case, based on the Swift/K precedent. Side issue: in cases where the function follows the old naming scheme, do we change nothing, or switch to the new naming scheme while keeping the old one around for compatibility? - Tim On Mon, Jan 12, 2015 at 10:25 PM, Mihael Hategan wrote: > > Allright, unless anybody else has anything to say, let's do an informal > vote and see what happens. > > We're voting on whether the naming convention for functions should be > camel case or underscores. This applies to future names when otherwise a > choice would exist and does not preclude exceptions when there is a good > reason to have them. > > This should also apply to the convention we use for future > documentation. > > 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: From wozniak at mcs.anl.gov Tue Jan 13 12:34:44 2015 From: wozniak at mcs.anl.gov (Justin M Wozniak) Date: Tue, 13 Jan 2015 12:34:44 -0600 Subject: [Swift-devel] Naming convention discussion [VOTE] In-Reply-To: References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> Message-ID: <54B56544.5070105@mcs.anl.gov> I tried to use underscores in Swift/T because I thought it promotes memorable function groups, (file_*, string_*, blob_*), and also appeals to the C and Fortran users we want to work with. I like using category_verb_modifier(), which is in a lot of the Swift/T internal code. But I am fine with camelCase too and look forward to contributing to the design document. I think we can keep the old names for compatibility. On 01/13/2015 12:20 PM, Tim Armstrong wrote: > I vote for camel case, based on the Swift/K precedent. > > Side issue: in cases where the function follows the old naming scheme, > do we change nothing, or switch to the new naming scheme while keeping > the old one around for compatibility? > > - Tim > > On Mon, Jan 12, 2015 at 10:25 PM, Mihael Hategan > wrote: > > > Allright, unless anybody else has anything to say, let's do an > informal > vote and see what happens. > > We're voting on whether the naming convention for functions should be > camel case or underscores. This applies to future names when > otherwise a > choice would exist and does not preclude exceptions when there is > a good > reason to have them. > > This should also apply to the convention we use for future > documentation. > > Mihael > > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > _______________________________________________ > 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: From wozniak at mcs.anl.gov Tue Jan 13 12:42:41 2015 From: wozniak at mcs.anl.gov (Justin M Wozniak) Date: Tue, 13 Jan 2015 12:42:41 -0600 Subject: [Swift-devel] Naming convention discussion [VOTE] In-Reply-To: <54B56544.5070105@mcs.anl.gov> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> Message-ID: <54B56721.3020308@mcs.anl.gov> On 01/13/2015 12:34 PM, Justin M Wozniak wrote: > I like using category_verb_modifier(), I also think it's good for a language standard library to claim power words like input, read, write, glob, substring, etc., and I hope we can find ways to keep names concise and memorable. I am also against overshortening like creat(), wcerr(), and str(). -- Justin M Wozniak From yadudoc1729 at gmail.com Tue Jan 13 13:07:50 2015 From: yadudoc1729 at gmail.com (Yadu Nand) Date: Tue, 13 Jan 2015 13:07:50 -0600 Subject: [Swift-devel] Naming convention discussion [VOTE] In-Reply-To: <54B56721.3020308@mcs.anl.gov> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> <54B56721.3020308@mcs.anl.gov> Message-ID: I vote for camelCase. -Yadu On Tue, Jan 13, 2015 at 12:42 PM, Justin M Wozniak wrote: > On 01/13/2015 12:34 PM, Justin M Wozniak wrote: > > I like using category_verb_modifier(), > > I also think it's good for a language standard library to claim power > words like input, read, write, glob, substring, etc., and I hope we can > find ways to keep names concise and memorable. > > I am also against overshortening like creat(), wcerr(), and str(). > > -- > Justin M Wozniak > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > -- Yadu Nand B -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Tue Jan 13 13:26:19 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 13 Jan 2015 11:26:19 -0800 Subject: [Swift-devel] We need a wiki? In-Reply-To: <54B56544.5070105@mcs.anl.gov> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> Message-ID: <1421177179.24819.3.camel@echo> On Tue, 2015-01-13 at 12:34 -0600, Justin M Wozniak wrote: > [...] and look forward to contributing > to the design document. ... speaking of which, we ran into a problem with Justin not being able to modify the Trac wiki. We could probably use a wiki-like thing. Do we have any that is decent and we can all use? Mihael From yadunand at uchicago.edu Tue Jan 13 13:43:55 2015 From: yadunand at uchicago.edu (Yadu Nand Babuji) Date: Tue, 13 Jan 2015 13:43:55 -0600 Subject: [Swift-devel] We need a wiki? In-Reply-To: <1421177179.24819.3.camel@echo> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> <1421177179.24819.3.camel@echo> Message-ID: <54B5757B.50204@uchicago.edu> How about the wiki that comes with the github repo ? https://github.com/swift-lang/swift-k/wiki or: https://github.com/swift-lang/swift-t/wiki -Yadu On 01/13/2015 01:26 PM, Mihael Hategan wrote: > On Tue, 2015-01-13 at 12:34 -0600, Justin M Wozniak wrote: >> [...] and look forward to contributing >> to the design document. > ... speaking of which, we ran into a problem with Justin not being able > to modify the Trac wiki. > > We could probably use a wiki-like thing. Do we have any that is decent > and we can all use? > > Mihael > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel From wilde at anl.gov Tue Jan 13 14:13:11 2015 From: wilde at anl.gov (Michael Wilde) Date: Tue, 13 Jan 2015 14:13:11 -0600 Subject: [Swift-devel] Naming convention discussion [VOTE] In-Reply-To: References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> <54B56721.3020308@mcs.anl.gov> Message-ID: <54B57C57.5090203@anl.gov> I vote for camelCase. - Mike On 1/13/15 1:07 PM, Yadu Nand wrote: > I vote for camelCase. > > -Yadu > > On Tue, Jan 13, 2015 at 12:42 PM, Justin M Wozniak > > wrote: > > On 01/13/2015 12:34 PM, Justin M Wozniak wrote: > > I like using category_verb_modifier(), > > I also think it's good for a language standard library to claim power > words like input, read, write, glob, substring, etc., and I hope > we can > find ways to keep names concise and memorable. > > I am also against overshortening like creat(), wcerr(), and str(). > > -- > Justin M Wozniak > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > -- > Yadu Nand B > > > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilde at anl.gov Tue Jan 13 14:14:20 2015 From: wilde at anl.gov (Michael Wilde) Date: Tue, 13 Jan 2015 14:14:20 -0600 Subject: [Swift-devel] We need a wiki? In-Reply-To: <54B5757B.50204@uchicago.edu> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> <1421177179.24819.3.camel@echo> <54B5757B.50204@uchicago.edu> Message-ID: <54B57C9C.9020901@anl.gov> We also have the swift-devel Google site. If we move from there to GitHub wiki, would be good to move all relevant content from the Google site. - Mike On 1/13/15 1:43 PM, Yadu Nand Babuji wrote: > How about the wiki that comes with the github repo ? > > https://github.com/swift-lang/swift-k/wiki > or: > https://github.com/swift-lang/swift-t/wiki > > -Yadu > > On 01/13/2015 01:26 PM, Mihael Hategan wrote: >> On Tue, 2015-01-13 at 12:34 -0600, Justin M Wozniak wrote: >>> [...] and look forward to contributing >>> to the design document. >> ... speaking of which, we ran into a problem with Justin not being able >> to modify the Trac wiki. >> >> We could probably use a wiki-like thing. Do we have any that is decent >> and we can all use? >> >> Mihael >> >> _______________________________________________ >> Swift-devel mailing list >> Swift-devel at ci.uchicago.edu >> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago From hategan at mcs.anl.gov Tue Jan 13 14:23:04 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 13 Jan 2015 12:23:04 -0800 Subject: [Swift-devel] We need a wiki? In-Reply-To: <54B57C9C.9020901@anl.gov> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> <1421177179.24819.3.camel@echo> <54B5757B.50204@uchicago.edu> <54B57C9C.9020901@anl.gov> Message-ID: <1421180584.30066.3.camel@echo> This I presume: https://code.google.com/p/exm-issues/ Mihael On Tue, 2015-01-13 at 14:14 -0600, Michael Wilde wrote: > We also have the swift-devel Google site. > > If we move from there to GitHub wiki, would be good to move all relevant > content from the Google site. > > - Mike > > On 1/13/15 1:43 PM, Yadu Nand Babuji wrote: > > How about the wiki that comes with the github repo ? > > > > https://github.com/swift-lang/swift-k/wiki > > or: > > https://github.com/swift-lang/swift-t/wiki > > > > -Yadu > > > > On 01/13/2015 01:26 PM, Mihael Hategan wrote: > >> On Tue, 2015-01-13 at 12:34 -0600, Justin M Wozniak wrote: > >>> [...] and look forward to contributing > >>> to the design document. > >> ... speaking of which, we ran into a problem with Justin not being able > >> to modify the Trac wiki. > >> > >> We could probably use a wiki-like thing. Do we have any that is decent > >> and we can all use? > >> > >> Mihael > >> > >> _______________________________________________ > >> Swift-devel mailing list > >> Swift-devel at ci.uchicago.edu > >> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > _______________________________________________ > > Swift-devel mailing list > > Swift-devel at ci.uchicago.edu > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > From wilde at anl.gov Tue Jan 13 14:26:15 2015 From: wilde at anl.gov (Michael Wilde) Date: Tue, 13 Jan 2015 14:26:15 -0600 Subject: [Swift-devel] We need a wiki? In-Reply-To: <1421180584.30066.3.camel@echo> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> <1421177179.24819.3.camel@echo> <54B5757B.50204@uchicago.edu> <54B57C9C.9020901@anl.gov> <1421180584.30066.3.camel@echo> Message-ID: <54B57F67.9090505@anl.gov> No, this one: https://sites.google.com/site/swiftdevel/ - Mike On 1/13/15 2:23 PM, Mihael Hategan wrote: > This I presume: https://code.google.com/p/exm-issues/ > > Mihael > > On Tue, 2015-01-13 at 14:14 -0600, Michael Wilde wrote: >> We also have the swift-devel Google site. >> >> If we move from there to GitHub wiki, would be good to move all relevant >> content from the Google site. >> >> - Mike >> >> On 1/13/15 1:43 PM, Yadu Nand Babuji wrote: >>> How about the wiki that comes with the github repo ? >>> >>> https://github.com/swift-lang/swift-k/wiki >>> or: >>> https://github.com/swift-lang/swift-t/wiki >>> >>> -Yadu >>> >>> On 01/13/2015 01:26 PM, Mihael Hategan wrote: >>>> On Tue, 2015-01-13 at 12:34 -0600, Justin M Wozniak wrote: >>>>> [...] and look forward to contributing >>>>> to the design document. >>>> ... speaking of which, we ran into a problem with Justin not being able >>>> to modify the Trac wiki. >>>> >>>> We could probably use a wiki-like thing. Do we have any that is decent >>>> and we can all use? >>>> >>>> Mihael >>>> >>>> _______________________________________________ >>>> Swift-devel mailing list >>>> Swift-devel at ci.uchicago.edu >>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel >>> _______________________________________________ >>> Swift-devel mailing list >>> Swift-devel at ci.uchicago.edu >>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago From hategan at mcs.anl.gov Tue Jan 13 14:29:53 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 13 Jan 2015 12:29:53 -0800 Subject: [Swift-devel] We need a wiki? In-Reply-To: <54B57F67.9090505@anl.gov> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> <1421177179.24819.3.camel@echo> <54B5757B.50204@uchicago.edu> <54B57C9C.9020901@anl.gov> <1421180584.30066.3.camel@echo> <54B57F67.9090505@anl.gov> Message-ID: <1421180993.30403.2.camel@echo> Ah, thanks. Doesn't seem to allow me to edit, so I think github is a better choice since everybody that can commit code can edit, and we need it mainly for development purposes. Mihael On Tue, 2015-01-13 at 14:26 -0600, Michael Wilde wrote: > No, this one: > > https://sites.google.com/site/swiftdevel/ > > - Mike > > On 1/13/15 2:23 PM, Mihael Hategan wrote: > > This I presume: https://code.google.com/p/exm-issues/ > > > > Mihael > > > > On Tue, 2015-01-13 at 14:14 -0600, Michael Wilde wrote: > >> We also have the swift-devel Google site. > >> > >> If we move from there to GitHub wiki, would be good to move all relevant > >> content from the Google site. > >> > >> - Mike > >> > >> On 1/13/15 1:43 PM, Yadu Nand Babuji wrote: > >>> How about the wiki that comes with the github repo ? > >>> > >>> https://github.com/swift-lang/swift-k/wiki > >>> or: > >>> https://github.com/swift-lang/swift-t/wiki > >>> > >>> -Yadu > >>> > >>> On 01/13/2015 01:26 PM, Mihael Hategan wrote: > >>>> On Tue, 2015-01-13 at 12:34 -0600, Justin M Wozniak wrote: > >>>>> [...] and look forward to contributing > >>>>> to the design document. > >>>> ... speaking of which, we ran into a problem with Justin not being able > >>>> to modify the Trac wiki. > >>>> > >>>> We could probably use a wiki-like thing. Do we have any that is decent > >>>> and we can all use? > >>>> > >>>> Mihael > >>>> > >>>> _______________________________________________ > >>>> Swift-devel mailing list > >>>> Swift-devel at ci.uchicago.edu > >>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > >>> _______________________________________________ > >>> Swift-devel mailing list > >>> Swift-devel at ci.uchicago.edu > >>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > From wilde at anl.gov Tue Jan 13 14:33:30 2015 From: wilde at anl.gov (Michael Wilde) Date: Tue, 13 Jan 2015 14:33:30 -0600 Subject: [Swift-devel] We need a wiki? In-Reply-To: <1421180993.30403.2.camel@echo> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> <1421177179.24819.3.camel@echo> <54B5757B.50204@uchicago.edu> <54B57C9C.9020901@anl.gov> <1421180584.30066.3.camel@echo> <54B57F67.9090505@anl.gov> <1421180993.30403.2.camel@echo> Message-ID: <54B5811A.4020101@anl.gov> I agree. I favor consolidating our information bases around GitHub. - Mike On 1/13/15 2:29 PM, Mihael Hategan wrote: > Ah, thanks. > > Doesn't seem to allow me to edit, so I think github is a better choice > since everybody that can commit code can edit, and we need it mainly for > development purposes. > > Mihael > > On Tue, 2015-01-13 at 14:26 -0600, Michael Wilde wrote: >> No, this one: >> >> https://sites.google.com/site/swiftdevel/ >> >> - Mike >> >> On 1/13/15 2:23 PM, Mihael Hategan wrote: >>> This I presume: https://code.google.com/p/exm-issues/ >>> >>> Mihael >>> >>> On Tue, 2015-01-13 at 14:14 -0600, Michael Wilde wrote: >>>> We also have the swift-devel Google site. >>>> >>>> If we move from there to GitHub wiki, would be good to move all relevant >>>> content from the Google site. >>>> >>>> - Mike >>>> >>>> On 1/13/15 1:43 PM, Yadu Nand Babuji wrote: >>>>> How about the wiki that comes with the github repo ? >>>>> >>>>> https://github.com/swift-lang/swift-k/wiki >>>>> or: >>>>> https://github.com/swift-lang/swift-t/wiki >>>>> >>>>> -Yadu >>>>> >>>>> On 01/13/2015 01:26 PM, Mihael Hategan wrote: >>>>>> On Tue, 2015-01-13 at 12:34 -0600, Justin M Wozniak wrote: >>>>>>> [...] and look forward to contributing >>>>>>> to the design document. >>>>>> ... speaking of which, we ran into a problem with Justin not being able >>>>>> to modify the Trac wiki. >>>>>> >>>>>> We could probably use a wiki-like thing. Do we have any that is decent >>>>>> and we can all use? >>>>>> >>>>>> Mihael >>>>>> >>>>>> _______________________________________________ >>>>>> Swift-devel mailing list >>>>>> Swift-devel at ci.uchicago.edu >>>>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel >>>>> _______________________________________________ >>>>> Swift-devel mailing list >>>>> Swift-devel at ci.uchicago.edu >>>>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago From wilde at anl.gov Thu Jan 15 11:34:27 2015 From: wilde at anl.gov (Michael Wilde) Date: Thu, 15 Jan 2015 11:34:27 -0600 Subject: [Swift-devel] Notes on Swift sites attributes for Cray systems Message-ID: <54B7FA23.9040902@anl.gov> are here: https://sites.google.com/site/swiftdevel/sites/pbs https://sites.google.com/site/swiftdevel/sites/pbs/cray -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago From hategan at mcs.anl.gov Fri Jan 16 13:59:12 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Fri, 16 Jan 2015 11:59:12 -0800 Subject: [Swift-devel] Naming convention discussion [VOTE] In-Reply-To: <54B57C57.5090203@anl.gov> References: <1420862743.10156.25.camel@echo> <1420948936.20377.11.camel@echo> <1420954892.21115.19.camel@echo> <1421123159.2226.11.camel@echo> <54B56544.5070105@mcs.anl.gov> <54B56721.3020308@mcs.anl.gov> <54B57C57.5090203@anl.gov> Message-ID: <1421438352.16614.1.camel@echo> Ok, so right now we have 3 for camel case and what I think is one vote for underscores. Mihael On Tue, 2015-01-13 at 14:13 -0600, Michael Wilde wrote: > I vote for camelCase. > > - Mike > > On 1/13/15 1:07 PM, Yadu Nand wrote: > > I vote for camelCase. > > > > -Yadu > > > > On Tue, Jan 13, 2015 at 12:42 PM, Justin M Wozniak > > > wrote: > > > > On 01/13/2015 12:34 PM, Justin M Wozniak wrote: > > > I like using category_verb_modifier(), > > > > I also think it's good for a language standard library to claim power > > words like input, read, write, glob, substring, etc., and I hope > > we can > > find ways to keep names concise and memorable. > > > > I am also against overshortening like creat(), wcerr(), and str(). > > > > -- > > Justin M Wozniak > > > > _______________________________________________ > > Swift-devel mailing list > > Swift-devel at ci.uchicago.edu > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > > > > > > -- > > Yadu Nand B > > > > > > > > _______________________________________________ > > Swift-devel mailing list > > Swift-devel at ci.uchicago.edu > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel From wilde at anl.gov Tue Jan 20 09:00:54 2015 From: wilde at anl.gov (Michael Wilde) Date: Tue, 20 Jan 2015 09:00:54 -0600 Subject: [Swift-devel] Sporadic connection handler messages in 0.95RC7 Message-ID: <54BE6DA6.4090403@anl.gov> Mihael, All, Im getting a sporadic "Could not start connection handler" message followed by a tracback starting at gssap code (see below) at the start of some test runs from bridled to beagle using 0.95RC7, coasters, ssh-cl and provider staging. The message seems to occur on less than half of my tests and whatever is causing them doesnt seem to be impacting the run. I intend to upgrade this script to trunk/0.96 as soon as time permits, but in the meantime, if you know the cause of this, it would great of I could fix it. If not, its very low priority and not at the moment worth much of your time (unless it recurs on 0.96 and/or causes failures). The runs are on bridled at /scratch/local/wilde/epsweep. Thanks, - Mike Swift 0.95 RC7 RunID: run011 Warning: The @ syntax for function invocation is deprecated Progress: Tue, 20 Jan 2015 00:11:30-0600 5 Runs in Simulation ep+12+31+90+72+72+3.85+113+70 ep+12+31+180+72+72+3.85+113+70 ep+12+31+135+72+72+3.85+113+70 ep+12+31+45+72+72+3.85+113+70 ep+12+31+0+72+72+3.85+113+70 Progress: Tue, 20 Jan 2015 00:11:31-0600 Submitting:5 Could not start connection handler java.io.EOFException at org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readHandshakeToken(GSIGssInputStream.java:61) at org.globus.gsi.gssapi.net.impl.GSIGssSocket.readToken(GSIGssSocket.java:65) at org.globus.gsi.gssapi.net.GssSocket.authenticateServer(GssSocket.java:127) at org.globus.gsi.gssapi.net.GssSocket.startHandshake(GssSocket.java:147) at org.globus.gsi.gssapi.net.GssSocket.getInputStream(GssSocket.java:177) at org.globus.cog.coaster.channels.AbstractTCPChannel.setSocket(AbstractTCPChannel.java:47) at org.globus.cog.coaster.channels.GSSChannel.(GSSChannel.java:46) at org.globus.cog.coaster.ConnectionHandler.(ConnectionHandler.java:42) at org.globus.cog.abstraction.coaster.service.local.LocalService.handleConnection(LocalService.java:71) at org.globus.net.BaseServer.run(BaseServer.java:247) at java.lang.Thread.run(Thread.java:722) -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago From yadudoc1729 at gmail.com Tue Jan 20 17:39:23 2015 From: yadudoc1729 at gmail.com (Yadu Nand) Date: Tue, 20 Jan 2015 17:39:23 -0600 Subject: [Swift-devel] 0.96 Branch Message-ID: Hi Mihael, There's an 0.96 branch on github with the last commit on Dec 4. It is missing the bug fixes that went into master much later. Do we merge trunk to it, and decide to branch now ? Or are we waiting on the library feature to merge ? Master : https://github.com/swift-lang/swift-k 0.96 : https://github.com/swift-lang/swift-k/tree/release-0.96-swift ?Thanks!? ?? Yadu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilde at anl.gov Tue Jan 20 17:48:52 2015 From: wilde at anl.gov (Michael Wilde) Date: Tue, 20 Jan 2015 17:48:52 -0600 Subject: [Swift-devel] 0.96 Branch In-Reply-To: References: Message-ID: <54BEE964.90406@anl.gov> I think we said that we would not wait on the library feature for 0.96. That would go into 0.97. - Mike On 1/20/15 5:39 PM, Yadu Nand wrote: > Hi Mihael, > > There's an 0.96 branch on github with the last commit on Dec 4. It > is missing the bug fixes that went into master much later. > > Do we merge trunk to it, and decide to branch now ? Or are we waiting > on the library feature to merge ? > > Master : https://github.com/swift-lang/swift-k > 0.96 : https://github.com/swift-lang/swift-k/tree/release-0.96-swift > > ?Thanks!? > ? ? > Yadu > > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Tue Jan 20 18:11:04 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 20 Jan 2015 16:11:04 -0800 Subject: [Swift-devel] 0.96 Branch In-Reply-To: <54BEE964.90406@anl.gov> References: <54BEE964.90406@anl.gov> Message-ID: <1421799064.20062.0.camel@echo> I agree. On Tue, 2015-01-20 at 17:48 -0600, Michael Wilde wrote: > I think we said that we would not wait on the library feature for 0.96. > That would go into 0.97. > > - Mike > > On 1/20/15 5:39 PM, Yadu Nand wrote: > > Hi Mihael, > > > > There's an 0.96 branch on github with the last commit on Dec 4. It > > is missing the bug fixes that went into master much later. > > > > Do we merge trunk to it, and decide to branch now ? Or are we waiting > > on the library feature to merge ? > > > > Master : https://github.com/swift-lang/swift-k > > 0.96 : https://github.com/swift-lang/swift-k/tree/release-0.96-swift > > > > ?Thanks!? > > ? ? > > Yadu > > > > > > _______________________________________________ > > Swift-devel mailing list > > Swift-devel at ci.uchicago.edu > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel From hategan at mcs.anl.gov Tue Jan 20 18:56:20 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 20 Jan 2015 16:56:20 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page Message-ID: <1421801780.20062.9.camel@echo> Hi, I made a wiki page on github where we could discuss the standard library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary It's a draft and there are some rough edges. In particular: - regular expression support: substitutions can be done either directly or with a combination between a function that returns capture groups and a formatting function that replaces certain tokens with elements of an array. One could overload the format() function to, in addition to standard formatting specs, also support something like %s[index]. Or have a separate formatting function that only deals with this specific problem. I'm not sure. - some of the array functions may be difficult to implement as specified, or there may be different functions that solve the problems better. In particular when joining arrays of arrays, there is some freedom in how to order the elements of the resulting array. - read and write: it may not be easy to implement a read that can return any type in T. There is some precedent in other languages that support serialization for this. Anyway, I added red exclamation marks and red question marks where things aren't quite clear. I'm assuming that most of us will agree on most of the things. However, if you have a wildly different proposal, it might be wise to create another page instead of editing this one. Mihael From tim.g.armstrong at gmail.com Tue Jan 20 20:36:46 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Tue, 20 Jan 2015 20:36:46 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421801780.20062.9.camel@echo> References: <1421801780.20062.9.camel@echo> Message-ID: How should we discuss things? Is it best to flag potential issues on the wiki, or should I mention it in here? - Tim On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan wrote: > Hi, > > I made a wiki page on github where we could discuss the standard > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary > > It's a draft and there are some rough edges. In particular: > > - regular expression support: substitutions can be done either directly > or with a combination between a function that returns capture groups and > a formatting function that replaces certain tokens with elements of an > array. One could overload the format() function to, in addition to > standard formatting specs, also support something like %s[index]. Or > have a separate formatting function that only deals with this specific > problem. I'm not sure. > > - some of the array functions may be difficult to implement as > specified, or there may be different functions that solve the problems > better. In particular when joining arrays of arrays, there is some > freedom in how to order the elements of the resulting array. > > - read and write: it may not be easy to implement a read that can return > any type in T. There is some precedent in other languages that support > serialization for this. > > Anyway, I added red exclamation marks and red question marks where > things aren't quite clear. > > I'm assuming that most of us will agree on most of the things. However, > if you have a wildly different proposal, it might be wise to create > another page instead of editing this one. > > 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: From hategan at mcs.anl.gov Tue Jan 20 20:56:00 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 20 Jan 2015 18:56:00 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> Message-ID: <1421808960.21749.8.camel@echo> I'm not sure. I think both. Let's try this: we use the wiki to mark points of contention. It gives us a quick overall view on the status. We discuss them through email and remove marks on the wiki as we develop fixes/agreements. I forgot to mention that there are going to have to be portions of the library that are specific to either T or K because that's just how some things have to be (e.g. file() in T). I don't think we should include them in this document/discussion. In other words, let's focus on the things for which there is no good reason to have different specifications in T and K. Mihael On Tue, 2015-01-20 at 20:36 -0600, Tim Armstrong wrote: > How should we discuss things? Is it best to flag potential issues on the > wiki, or should I mention it in here? > > - Tim > > On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan wrote: > > > Hi, > > > > I made a wiki page on github where we could discuss the standard > > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary > > > > It's a draft and there are some rough edges. In particular: > > > > - regular expression support: substitutions can be done either directly > > or with a combination between a function that returns capture groups and > > a formatting function that replaces certain tokens with elements of an > > array. One could overload the format() function to, in addition to > > standard formatting specs, also support something like %s[index]. Or > > have a separate formatting function that only deals with this specific > > problem. I'm not sure. > > > > - some of the array functions may be difficult to implement as > > specified, or there may be different functions that solve the problems > > better. In particular when joining arrays of arrays, there is some > > freedom in how to order the elements of the resulting array. > > > > - read and write: it may not be easy to implement a read that can return > > any type in T. There is some precedent in other languages that support > > serialization for this. > > > > Anyway, I added red exclamation marks and red question marks where > > things aren't quite clear. > > > > I'm assuming that most of us will agree on most of the things. However, > > if you have a wildly different proposal, it might be wise to create > > another page instead of editing this one. > > > > Mihael > > > > _______________________________________________ > > Swift-devel mailing list > > Swift-devel at ci.uchicago.edu > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > From tim.g.armstrong at gmail.com Tue Jan 20 21:12:44 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Tue, 20 Jan 2015 21:12:44 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421808960.21749.8.camel@echo> References: <1421801780.20062.9.camel@echo> <1421808960.21749.8.camel@echo> Message-ID: I made a bunch of comments. I think my biggest concerns mainly revolved around the functions operating on arrays in non-trivial ways - I'm not sure if the current definitions are obvious/intuitive, or if it's possible to have obvious/intuitive definitions given the weird behaviour of Swift arrays. I sometimes feel like Swift arrays are having an identity crisis, so this may be an opportunity to think through some of the issues. Fundamentally they're sparse arrays but they keep being pressed into service as dense arrays. Would simply adding a fixed-size dense array data type resolve some of the complications? - Tim On Tue, Jan 20, 2015 at 8:56 PM, Mihael Hategan wrote: > I'm not sure. I think both. > > Let's try this: we use the wiki to mark points of contention. It gives > us a quick overall view on the status. We discuss them through email and > remove marks on the wiki as we develop fixes/agreements. > > I forgot to mention that there are going to have to be portions of the > library that are specific to either T or K because that's just how some > things have to be (e.g. file() in T). I don't think we should include > them in this document/discussion. In other words, let's focus on the > things for which there is no good reason to have different > specifications in T and K. > > Mihael > > On Tue, 2015-01-20 at 20:36 -0600, Tim Armstrong wrote: > > How should we discuss things? Is it best to flag potential issues on the > > wiki, or should I mention it in here? > > > > - Tim > > > > On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan > wrote: > > > > > Hi, > > > > > > I made a wiki page on github where we could discuss the standard > > > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary > > > > > > It's a draft and there are some rough edges. In particular: > > > > > > - regular expression support: substitutions can be done either directly > > > or with a combination between a function that returns capture groups > and > > > a formatting function that replaces certain tokens with elements of an > > > array. One could overload the format() function to, in addition to > > > standard formatting specs, also support something like %s[index]. Or > > > have a separate formatting function that only deals with this specific > > > problem. I'm not sure. > > > > > > - some of the array functions may be difficult to implement as > > > specified, or there may be different functions that solve the problems > > > better. In particular when joining arrays of arrays, there is some > > > freedom in how to order the elements of the resulting array. > > > > > > - read and write: it may not be easy to implement a read that can > return > > > any type in T. There is some precedent in other languages that support > > > serialization for this. > > > > > > Anyway, I added red exclamation marks and red question marks where > > > things aren't quite clear. > > > > > > I'm assuming that most of us will agree on most of the things. However, > > > if you have a wildly different proposal, it might be wise to create > > > another page instead of editing this one. > > > > > > 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: From ketan at mcs.anl.gov Tue Jan 20 21:59:16 2015 From: ketan at mcs.anl.gov (Ketan Maheshwari) Date: Tue, 20 Jan 2015 21:59:16 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421801780.20062.9.camel@echo> References: <1421801780.20062.9.camel@echo> Message-ID: Neat! Comments: -- Statistical functions in a standard library seem out of place to me. One may ask, why just stop with statistical functions and not also include vector and matrix related functions such as cross and dot products or fancier stuff like finding eigen values, etc. -- sqrt and cbrt seem redundant as we already provide pow with float exponent. Regards, Ketan On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan wrote: > Hi, > > I made a wiki page on github where we could discuss the standard > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary > > It's a draft and there are some rough edges. In particular: > > - regular expression support: substitutions can be done either directly > or with a combination between a function that returns capture groups and > a formatting function that replaces certain tokens with elements of an > array. One could overload the format() function to, in addition to > standard formatting specs, also support something like %s[index]. Or > have a separate formatting function that only deals with this specific > problem. I'm not sure. > > - some of the array functions may be difficult to implement as > specified, or there may be different functions that solve the problems > better. In particular when joining arrays of arrays, there is some > freedom in how to order the elements of the resulting array. > > - read and write: it may not be easy to implement a read that can return > any type in T. There is some precedent in other languages that support > serialization for this. > > Anyway, I added red exclamation marks and red question marks where > things aren't quite clear. > > I'm assuming that most of us will agree on most of the things. However, > if you have a wildly different proposal, it might be wise to create > another page instead of editing this one. > > 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: From ketan at mcs.anl.gov Tue Jan 20 22:19:45 2015 From: ketan at mcs.anl.gov (Ketan Maheshwari) Date: Tue, 20 Jan 2015 22:19:45 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> Message-ID: One more comment: May be ln (natural log) should be there alongside log. On Tue, Jan 20, 2015 at 9:59 PM, Ketan Maheshwari wrote: > Neat! > > Comments: > > -- Statistical functions in a standard library seem out of place to me. > One may ask, why just stop with statistical functions and not also include > vector and matrix related functions such as cross and dot products or > fancier stuff like finding eigen values, etc. > > -- sqrt and cbrt seem redundant as we already provide pow with float > exponent. > > Regards, > Ketan > > On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan > wrote: > >> Hi, >> >> I made a wiki page on github where we could discuss the standard >> library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary >> >> It's a draft and there are some rough edges. In particular: >> >> - regular expression support: substitutions can be done either directly >> or with a combination between a function that returns capture groups and >> a formatting function that replaces certain tokens with elements of an >> array. One could overload the format() function to, in addition to >> standard formatting specs, also support something like %s[index]. Or >> have a separate formatting function that only deals with this specific >> problem. I'm not sure. >> >> - some of the array functions may be difficult to implement as >> specified, or there may be different functions that solve the problems >> better. In particular when joining arrays of arrays, there is some >> freedom in how to order the elements of the resulting array. >> >> - read and write: it may not be easy to implement a read that can return >> any type in T. There is some precedent in other languages that support >> serialization for this. >> >> Anyway, I added red exclamation marks and red question marks where >> things aren't quite clear. >> >> I'm assuming that most of us will agree on most of the things. However, >> if you have a wildly different proposal, it might be wise to create >> another page instead of editing this one. >> >> 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: From wilde at anl.gov Tue Jan 20 22:55:38 2015 From: wilde at anl.gov (Michael Wilde) Date: Tue, 20 Jan 2015 22:55:38 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> Message-ID: <54BF314A.3020806@anl.gov> On 1/20/15 9:59 PM, Ketan Maheshwari wrote: > Neat! > > Comments: > > -- Statistical functions in a standard library seem out of place to > me. One may ask, why just stop with statistical functions and not also > include vector and matrix related functions such as cross and dot > products or fancier stuff like finding eigen values, etc. Important things like sum( ) were placed in this category. I think this is a common need that's hard to do without an intrinsic library function. I suspect there are other frequently encountered needs to iterate through an array and select, count, or otherwise process elements that match some criteria. I'd argue for moving such functions to the Array category instead of the stats category. Do we need other types of array reduction functions? min() / max()? General reduction seems to demand function arguments, but I'm getting beyond my understanding of functional programming here. I wonder what the minimal lowest common denominator intrinsic functions of this nature are, which would enable any higher-level set of stats functions to be implemented. I'm still trying to understand if a necessary and sufficient set of such functions were already included in the proposed set, or if these remain to be defined. - Mike > > -- sqrt and cbrt seem redundant as we already provide pow with float > exponent. > > Regards, > Ketan > > On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan > wrote: > > Hi, > > I made a wiki page on github where we could discuss the standard > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary > > It's a draft and there are some rough edges. In particular: > > - regular expression support: substitutions can be done either > directly > or with a combination between a function that returns capture > groups and > a formatting function that replaces certain tokens with elements of an > array. One could overload the format() function to, in addition to > standard formatting specs, also support something like %s[index]. Or > have a separate formatting function that only deals with this specific > problem. I'm not sure. > > - some of the array functions may be difficult to implement as > specified, or there may be different functions that solve the problems > better. In particular when joining arrays of arrays, there is some > freedom in how to order the elements of the resulting array. > > - read and write: it may not be easy to implement a read that can > return > any type in T. There is some precedent in other languages that support > serialization for this. > > Anyway, I added red exclamation marks and red question marks where > things aren't quite clear. > > I'm assuming that most of us will agree on most of the things. > However, > if you have a wildly different proposal, it might be wise to create > another page instead of editing this one. > > Mihael > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Wed Jan 21 02:13:03 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 21 Jan 2015 00:13:03 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> Message-ID: <1421827983.21889.12.camel@echo> On Tue, 2015-01-20 at 21:59 -0600, Ketan Maheshwari wrote: > Neat! > > Comments: > > -- Statistical functions in a standard library seem out of place to me. One > may ask, why just stop with statistical functions and not also include > vector and matrix related functions such as cross and dot products or > fancier stuff like finding eigen values, etc. They were in Swift/T and I thought they were useful. Dot products can be done with the zip() function. Cross products can be done with two nested foreach loops (although I did consider an outer join function). There are way too many ways to calculate eigenvalues efficiently, and there are also all kinds of weird algorithms to do so when you need only some eigenvalues, either the smallest or the largest. So I don't think we should get into that business. So I think the bottom line is that if there is something that is likely helpful for a lot of users and doesn't require a lot of work, then we should probably have it there. > > -- sqrt and cbrt seem redundant as we already provide pow with float > exponent. True. But it looks like most languages provide all of them anyway (I can't really think of a language that doesn't have sqrt). I guess it's just nicer to write sqrt(2) than of pow(2, 0.5). Mihael > > Regards, > Ketan > > On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan wrote: > > > Hi, > > > > I made a wiki page on github where we could discuss the standard > > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary > > > > It's a draft and there are some rough edges. In particular: > > > > - regular expression support: substitutions can be done either directly > > or with a combination between a function that returns capture groups and > > a formatting function that replaces certain tokens with elements of an > > array. One could overload the format() function to, in addition to > > standard formatting specs, also support something like %s[index]. Or > > have a separate formatting function that only deals with this specific > > problem. I'm not sure. > > > > - some of the array functions may be difficult to implement as > > specified, or there may be different functions that solve the problems > > better. In particular when joining arrays of arrays, there is some > > freedom in how to order the elements of the resulting array. > > > > - read and write: it may not be easy to implement a read that can return > > any type in T. There is some precedent in other languages that support > > serialization for this. > > > > Anyway, I added red exclamation marks and red question marks where > > things aren't quite clear. > > > > I'm assuming that most of us will agree on most of the things. However, > > if you have a wildly different proposal, it might be wise to create > > another page instead of editing this one. > > > > Mihael > > > > _______________________________________________ > > Swift-devel mailing list > > Swift-devel at ci.uchicago.edu > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > From hategan at mcs.anl.gov Wed Jan 21 02:16:13 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 21 Jan 2015 00:16:13 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> Message-ID: <1421828173.21889.15.camel@echo> On Tue, 2015-01-20 at 22:19 -0600, Ketan Maheshwari wrote: > One more comment: May be ln (natural log) should be there alongside log. I think in most american math log == ln. And that is also the case for the propose log, or the log function in java.lang.Math. I am personally used to used to ln being ln and log being log10. But that's another story. Java does have log and log10. I have nothing against adding log10. Mihael From hategan at mcs.anl.gov Wed Jan 21 02:25:11 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 21 Jan 2015 00:25:11 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <54BF314A.3020806@anl.gov> References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> Message-ID: <1421828711.21889.23.camel@echo> On Tue, 2015-01-20 at 22:55 -0600, Michael Wilde wrote: > On 1/20/15 9:59 PM, Ketan Maheshwari wrote: > > Neat! > > > > Comments: > > > > -- Statistical functions in a standard library seem out of place to > > me. One may ask, why just stop with statistical functions and not also > > include vector and matrix related functions such as cross and dot > > products or fancier stuff like finding eigen values, etc. > Important things like sum( ) were placed in this category. I think this > is a common need that's hard to do without an intrinsic library > function. I suspect there are other frequently encountered needs to > iterate through an array and select, count, or otherwise process > elements that match some criteria. > > I'd argue for moving such functions to the Array category instead of the > stats category. Do we need other types of array reduction functions? > min() / max()? General reduction seems to demand function arguments, > but I'm getting beyond my understanding of functional programming here. So am I. In principle, recursion should be sufficient to do these things in a functional language. For example, min(x[]) = function { if (len(x) == 1) { return head(x); } else { tmp = min(tail(x)); return tmp < head(x) ? tmp : head(x); } For starters, we would need a tail() function. But I don't think we are that language. So I would say that this goes beyond my understanding too. And this discussion is hopefully going to fix some of that. > > I wonder what the minimal lowest common denominator intrinsic functions > of this nature are, which would enable any higher-level set of stats > functions to be implemented. I'm still trying to understand if a > necessary and sufficient set of such functions were already included in > the proposed set, or if these remain to be defined. I think your min/max example shows that things remain to be defined, unless we expect recursive solutions as above to be done by the user. The array split function was in fact requested by a user and there is a recursive solution for it. It should be somewhere on swift-user. So why that and not min/max? I don't know. Mihael From tim.g.armstrong at gmail.com Wed Jan 21 09:14:47 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Wed, 21 Jan 2015 09:14:47 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421828711.21889.23.camel@echo> References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> Message-ID: I think the ideal scenario might be if we could have these in the standard library, but implemented in Swift. I tried tried to write Swift code for the min/max problem and it's really revealing some weird interactions/limitations around the sparse arrays and iteration constructs provided. The thing is that there's no straightforward way to iterate in order over the set of keys in an array, passing a variable from one iteration to the next. My thought process was: 1. Iterate over array with foreach -> doesn't work, since we can't pass the max from one iteration to the next 2. Sequentially iterate over 0..size(A)-1 with for loop -> doesn't work since keys may be sparse or not start at 0 3. Fetch the list of keys and iterate over them with foreach -> doesn't work, since foreach doesn't let us pass max from one iteration to the next 4. Fetch the list of keys, and since we can assume that they're dense, iterate over 0..size(A) -1 with a for loop, lookup A[keys[i]], and update the max based on that. So there is a solution, but it's really ugly - I don't think we should have to create a copy of the array's keys and do a double indirection just to calculate min/max. It also feels a little clunky that the eventual solution depends on implicit contracts about whether an array's keys are dense or not. We'd have to assume that most users would give up after #1 or #2. Also Swift/K doesn't support for loops, so you have to resort to using arrays. It's also error prone since many users will neglect to consider that there may be gaps in the array's key space. I think there's an issue that there is no direct way to get the first item in an array, and no direct way to get the successor to an item in the array. head/tail is one solution to that, but seems more natural with linked lists than arrays, since the tail operation sort of implies a copy of the array, and the tailed array has to support every operation a normal array supports. Supporting iterators over the array might be a good alternative. So I have a couple of proposals: 1. Support iterators. e.g. it = iterator(A); it2 = next(it). 2. Support sequential foreach with some accumulator variables passed between iterations. This would likely be implemented with iterators. Supporting ordered iterators in Swift/T would require work, since we store Swift arrays in hash tables and use string keys, wihch presents two problems for finding the next integer value after the current one. - Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From ketan at mcs.anl.gov Wed Jan 21 10:03:38 2015 From: ketan at mcs.anl.gov (Ketan Maheshwari) Date: Wed, 21 Jan 2015 10:03:38 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> Message-ID: On Wed, Jan 21, 2015 at 2:13 AM, Hategan-Marandiuc, Philip M. < hategan at mcs.anl.gov> wrote: > On Tue, 2015-01-20 at 21:59 -0600, Ketan Maheshwari wrote: > > Neat! > > > > Comments: > > > > -- Statistical functions in a standard library seem out of place to me. > One > > may ask, why just stop with statistical functions and not also include > > vector and matrix related functions such as cross and dot products or > > fancier stuff like finding eigen values, etc. > > They were in Swift/T and I thought they were useful. Dot products can be > done with the zip() function. Cross products can be done with two nested > foreach loops (although I did consider an outer join function). There > are way too many ways to calculate eigenvalues efficiently, and there > are also all kinds of weird algorithms to do so when you need only some > eigenvalues, either the smallest or the largest. So I don't think we > should get into that business. > > So I think the bottom line is that if there is something that is likely > helpful for a lot of users and doesn't require a lot of work, then we > should probably have it there. > I understand the utility. My point was that may be we should move these functions out of standard library and put in another library, say auxiliary or something. As Mike mentioned in his reply, it would be nice if a canonical set of core functions are placed and locked in the standard library. > > > > > -- sqrt and cbrt seem redundant as we already provide pow with float > > exponent. > > True. But it looks like most languages provide all of them anyway (I > can't really think of a language that doesn't have sqrt). I guess it's > just nicer to write sqrt(2) than of pow(2, 0.5). > True for sqrt, not so much for cbrt though. > > Mihael > > > > > Regards, > > Ketan > > > > On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan > wrote: > > > > > Hi, > > > > > > I made a wiki page on github where we could discuss the standard > > > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary > > > > > > It's a draft and there are some rough edges. In particular: > > > > > > - regular expression support: substitutions can be done either directly > > > or with a combination between a function that returns capture groups > and > > > a formatting function that replaces certain tokens with elements of an > > > array. One could overload the format() function to, in addition to > > > standard formatting specs, also support something like %s[index]. Or > > > have a separate formatting function that only deals with this specific > > > problem. I'm not sure. > > > > > > - some of the array functions may be difficult to implement as > > > specified, or there may be different functions that solve the problems > > > better. In particular when joining arrays of arrays, there is some > > > freedom in how to order the elements of the resulting array. > > > > > > - read and write: it may not be easy to implement a read that can > return > > > any type in T. There is some precedent in other languages that support > > > serialization for this. > > > > > > Anyway, I added red exclamation marks and red question marks where > > > things aren't quite clear. > > > > > > I'm assuming that most of us will agree on most of the things. However, > > > if you have a wildly different proposal, it might be wise to create > > > another page instead of editing this one. > > > > > > 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: From tim.g.armstrong at gmail.com Wed Jan 21 12:17:50 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Wed, 21 Jan 2015 12:17:50 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> Message-ID: sqrt and pow may use different algorithms and provide slightly different numerical guarantees even if they're mathematically the same. I agree cbrt is pretty marginal, I've never used that personally. What is the difference between a standard library and an auxiliary library that is shipped with Swift? If both are shipped with Swift and both are documented in the user guide, it seems like a very minor distinction and I'm not sure what it buys us. Factoring the functions into appropriate libraries and then documenting any caveats seems sufficient to me, but maybe I'm missing something. RE: Mike's query about stats functions. The functions aren't necessarily equivalent performance-wise or numerically in practice even if they are algebraically. E.g. sum(A) / size(A) isn't always a good way to compute avg(A) because of rounding and overflow concerns. I think there's a strong argument for providing solid, numerically sound implementations of common stats functions in Swift if they're likely to see usage. Better support for reduces and loops would allow more to be implemented in Swift I think too. - Tim On Wed, Jan 21, 2015 at 10:03 AM, Ketan Maheshwari wrote: > > On Wed, Jan 21, 2015 at 2:13 AM, Hategan-Marandiuc, Philip M. < > hategan at mcs.anl.gov> wrote: > >> On Tue, 2015-01-20 at 21:59 -0600, Ketan Maheshwari wrote: >> > Neat! >> > >> > Comments: >> > >> > -- Statistical functions in a standard library seem out of place to me. >> One >> > may ask, why just stop with statistical functions and not also include >> > vector and matrix related functions such as cross and dot products or >> > fancier stuff like finding eigen values, etc. >> >> They were in Swift/T and I thought they were useful. Dot products can be >> done with the zip() function. Cross products can be done with two nested >> foreach loops (although I did consider an outer join function). There >> are way too many ways to calculate eigenvalues efficiently, and there >> are also all kinds of weird algorithms to do so when you need only some >> eigenvalues, either the smallest or the largest. So I don't think we >> should get into that business. >> >> So I think the bottom line is that if there is something that is likely >> helpful for a lot of users and doesn't require a lot of work, then we >> should probably have it there. >> > > I understand the utility. My point was that may be we should move these > functions out of standard library and put in another library, say auxiliary > or something. As Mike mentioned in his reply, it would be nice if a > canonical set of core functions are placed and locked in the standard > library. > > >> >> > >> > -- sqrt and cbrt seem redundant as we already provide pow with float >> > exponent. >> >> True. But it looks like most languages provide all of them anyway (I >> can't really think of a language that doesn't have sqrt). I guess it's >> just nicer to write sqrt(2) than of pow(2, 0.5). >> > > True for sqrt, not so much for cbrt though. > > >> >> Mihael >> >> > >> > Regards, >> > Ketan >> > >> > On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan >> wrote: >> > >> > > Hi, >> > > >> > > I made a wiki page on github where we could discuss the standard >> > > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary >> > > >> > > It's a draft and there are some rough edges. In particular: >> > > >> > > - regular expression support: substitutions can be done either >> directly >> > > or with a combination between a function that returns capture groups >> and >> > > a formatting function that replaces certain tokens with elements of an >> > > array. One could overload the format() function to, in addition to >> > > standard formatting specs, also support something like %s[index]. Or >> > > have a separate formatting function that only deals with this specific >> > > problem. I'm not sure. >> > > >> > > - some of the array functions may be difficult to implement as >> > > specified, or there may be different functions that solve the problems >> > > better. In particular when joining arrays of arrays, there is some >> > > freedom in how to order the elements of the resulting array. >> > > >> > > - read and write: it may not be easy to implement a read that can >> return >> > > any type in T. There is some precedent in other languages that support >> > > serialization for this. >> > > >> > > Anyway, I added red exclamation marks and red question marks where >> > > things aren't quite clear. >> > > >> > > I'm assuming that most of us will agree on most of the things. >> However, >> > > if you have a wildly different proposal, it might be wise to create >> > > another page instead of editing this one. >> > > >> > > Mihael >> > > >> > > _______________________________________________ >> > > Swift-devel mailing list >> > > Swift-devel at ci.uchicago.edu >> > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel >> > > >> >> >> > > _______________________________________________ > 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: From tim.g.armstrong at gmail.com Wed Jan 21 12:22:19 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Wed, 21 Jan 2015 12:22:19 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> Message-ID: RE: log/ln/log10 I think this is pretty varied. I've seen contexts where log() meant either log_e, log_2, or log_10. The completely unambiguous way would be to have ln(x), log(x, base) and optionally log10(x) On Wed, Jan 21, 2015 at 12:17 PM, Tim Armstrong wrote: > sqrt and pow may use different algorithms and provide slightly different > numerical guarantees even if they're mathematically the same. > > I agree cbrt is pretty marginal, I've never used that personally. > > What is the difference between a standard library and an auxiliary library > that is shipped with Swift? If both are shipped with Swift and both are > documented in the user guide, it seems like a very minor distinction and > I'm not sure what it buys us. Factoring the functions into appropriate > libraries and then documenting any caveats seems sufficient to me, but > maybe I'm missing something. > > RE: Mike's query about stats functions. The functions aren't necessarily > equivalent performance-wise or numerically in practice even if they are > algebraically. E.g. sum(A) / size(A) isn't always a good way to compute > avg(A) because of rounding and overflow concerns. I think there's a strong > argument for providing solid, numerically sound implementations of common > stats functions in Swift if they're likely to see usage. > > Better support for reduces and loops would allow more to be implemented in > Swift I think too. > > - Tim > > > > On Wed, Jan 21, 2015 at 10:03 AM, Ketan Maheshwari > wrote: > >> >> On Wed, Jan 21, 2015 at 2:13 AM, Hategan-Marandiuc, Philip M. < >> hategan at mcs.anl.gov> wrote: >> >>> On Tue, 2015-01-20 at 21:59 -0600, Ketan Maheshwari wrote: >>> > Neat! >>> > >>> > Comments: >>> > >>> > -- Statistical functions in a standard library seem out of place to >>> me. One >>> > may ask, why just stop with statistical functions and not also include >>> > vector and matrix related functions such as cross and dot products or >>> > fancier stuff like finding eigen values, etc. >>> >>> They were in Swift/T and I thought they were useful. Dot products can be >>> done with the zip() function. Cross products can be done with two nested >>> foreach loops (although I did consider an outer join function). There >>> are way too many ways to calculate eigenvalues efficiently, and there >>> are also all kinds of weird algorithms to do so when you need only some >>> eigenvalues, either the smallest or the largest. So I don't think we >>> should get into that business. >>> >>> So I think the bottom line is that if there is something that is likely >>> helpful for a lot of users and doesn't require a lot of work, then we >>> should probably have it there. >>> >> >> I understand the utility. My point was that may be we should move these >> functions out of standard library and put in another library, say auxiliary >> or something. As Mike mentioned in his reply, it would be nice if a >> canonical set of core functions are placed and locked in the standard >> library. >> >> >>> >>> > >>> > -- sqrt and cbrt seem redundant as we already provide pow with float >>> > exponent. >>> >>> True. But it looks like most languages provide all of them anyway (I >>> can't really think of a language that doesn't have sqrt). I guess it's >>> just nicer to write sqrt(2) than of pow(2, 0.5). >>> >> >> True for sqrt, not so much for cbrt though. >> >> >>> >>> Mihael >>> >>> > >>> > Regards, >>> > Ketan >>> > >>> > On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan >>> wrote: >>> > >>> > > Hi, >>> > > >>> > > I made a wiki page on github where we could discuss the standard >>> > > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary >>> > > >>> > > It's a draft and there are some rough edges. In particular: >>> > > >>> > > - regular expression support: substitutions can be done either >>> directly >>> > > or with a combination between a function that returns capture groups >>> and >>> > > a formatting function that replaces certain tokens with elements of >>> an >>> > > array. One could overload the format() function to, in addition to >>> > > standard formatting specs, also support something like %s[index]. Or >>> > > have a separate formatting function that only deals with this >>> specific >>> > > problem. I'm not sure. >>> > > >>> > > - some of the array functions may be difficult to implement as >>> > > specified, or there may be different functions that solve the >>> problems >>> > > better. In particular when joining arrays of arrays, there is some >>> > > freedom in how to order the elements of the resulting array. >>> > > >>> > > - read and write: it may not be easy to implement a read that can >>> return >>> > > any type in T. There is some precedent in other languages that >>> support >>> > > serialization for this. >>> > > >>> > > Anyway, I added red exclamation marks and red question marks where >>> > > things aren't quite clear. >>> > > >>> > > I'm assuming that most of us will agree on most of the things. >>> However, >>> > > if you have a wildly different proposal, it might be wise to create >>> > > another page instead of editing this one. >>> > > >>> > > Mihael >>> > > >>> > > _______________________________________________ >>> > > Swift-devel mailing list >>> > > Swift-devel at ci.uchicago.edu >>> > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel >>> > > >>> >>> >>> >> >> _______________________________________________ >> 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: From hategan at mcs.anl.gov Wed Jan 21 13:09:09 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 21 Jan 2015 11:09:09 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> Message-ID: <1421867349.25580.1.camel@echo> On Wed, 2015-01-21 at 12:22 -0600, Tim Armstrong wrote: > RE: log/ln/log10 > > I think this is pretty varied. I've seen contexts where log() meant either > log_e, log_2, or log_10. > > The completely unambiguous way would be to have ln(x), log(x, base) and > optionally log10(x) I like that. +1 Mihael From hategan at mcs.anl.gov Wed Jan 21 13:20:41 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 21 Jan 2015 11:20:41 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> Message-ID: <1421868041.25580.12.camel@echo> I think this is a general problem with Swift: the inability to have accumulator variables. It leads to the necessity to use recursion, but that isn't in itself enough because of the issue with tail(array) that you mention. So iterators seem like the right choice there. You mentioned non-sparse arrays. The only problem with algorithms based on dense arrays is that they might not be very efficient in swift since elements are not necessarily generated in order. It may just be that a[0] will make it into the array last due to parallelism. So I think updateables > iterators > dense arrays > tail > nothing. The question is whether we would design the standard library differently if we had either of updateables or iterators vs. what we have right now (nothing) and whether the differences would be significant enough for us to suspend the standard library discussion until we have these features. Mihael On Wed, 2015-01-21 at 09:14 -0600, Tim Armstrong wrote: > I think the ideal scenario might be if we could have these in the standard > library, but implemented in Swift. > > I tried tried to write Swift code for the min/max problem and it's really > revealing some weird interactions/limitations around the sparse arrays and > iteration constructs provided. > > The thing is that there's no straightforward way to iterate in order over > the set of keys in an array, passing a variable from one iteration to the > next. My thought process was: > > 1. Iterate over array with foreach -> doesn't work, since we can't pass > the max from one iteration to the next > 2. Sequentially iterate over 0..size(A)-1 with for loop -> doesn't work > since keys may be sparse or not start at 0 > 3. Fetch the list of keys and iterate over them with foreach -> doesn't > work, since foreach doesn't let us pass max from one iteration to the next > 4. Fetch the list of keys, and since we can assume that they're dense, > iterate over 0..size(A) -1 with a for loop, lookup A[keys[i]], and update > the max based on that. > > So there is a solution, but it's really ugly - I don't think we should have > to create a copy of the array's keys and do a double indirection just to > calculate min/max. It also feels a little clunky that the eventual > solution depends on implicit contracts about whether an array's keys are > dense or not. > > We'd have to assume that most users would give up after #1 or #2. Also > Swift/K doesn't support for loops, so you have to resort to using arrays. > It's also error prone since many users will neglect to consider that there > may be gaps in the array's key space. > > I think there's an issue that there is no direct way to get the first item > in an array, and no direct way to get the successor to an item in the > array. head/tail is one solution to that, but seems more natural with > linked lists than arrays, since the tail operation sort of implies a copy > of the array, and the tailed array has to support every operation a normal > array supports. Supporting iterators over the array might be a good > alternative. > > So I have a couple of proposals: > > 1. Support iterators. e.g. it = iterator(A); it2 = next(it). > 2. Support sequential foreach with some accumulator variables passed > between iterations. This would likely be implemented with iterators. > > Supporting ordered iterators in Swift/T would require work, since we store > Swift arrays in hash tables and use string keys, wihch presents two > problems for finding the next integer value after the current one. > > - Tim From tim.g.armstrong at gmail.com Wed Jan 21 15:04:37 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Wed, 21 Jan 2015 15:04:37 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421868041.25580.12.camel@echo> References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> Message-ID: I'm assuming that the size of a dense array would be specified when its initialized. Then a dense array of size n behaves the same as n individual variables - there's no reason you have to assign them in order, or iterate over them in order unless that's what you actually want/need to do. I agree that trying to have dense arrays that automatically expand in a parallel language is a bad idea. I think it's really worth considering, because for a lot of standard library functions, bad or confusing things will happen if arguments are sparse arrays. Of course we can document all of these functions to warn users about doing that, but that requires them to a) actually read the docs b) understand the distinction c) remember this when they're writing code and d) be able to trace weird deadlocks or error messages back to the original cause when they make an inadvertent mistake. I don't mean this as an insult to users - I could see myself doing all of those things. It seems very suboptimal. This is really a separate discussion that doesn't affect the standard library, but I think the updateable idea, at least in the form that was proposed on the phone call, is flawed and actually is equivalent to changing Swift from a language with parallel semantics to a language with sequential semantics that we're trying to auto-parallelise. I don't think we want to try to solve the autoparallelisation problem. It's easy to autoparallelise trivial examples but as soon as a programmer uses something exotic like an if statement (or an if statement inside a loop, or many more possibilities) it becomes much harder. I can provide examples that will break any specific approach if needed. For example, the "versioned" variables idea doesn't work for this code: versioned int x = 1; if (...) { x = 2; } trace(x); Does x at the bottom refer to version 0 of the variable or version 1 of the variable? You can't determine that statically. You might say that you could define the semantics so that the version x it's referring to depends on which branch is taken at runtime. But then you've reinvented sequential control flow and all that entails. Once you get loops involved it is much worse too - it's probably not that hard to come up with an extension that works ok for this specific example, but adding loops to the equation breaks it further. - Tim On Wed, Jan 21, 2015 at 1:20 PM, Mihael Hategan wrote: > I think this is a general problem with Swift: the inability to have > accumulator variables. It leads to the necessity to use recursion, but > that isn't in itself enough because of the issue with tail(array) that > you mention. So iterators seem like the right choice there. > > You mentioned non-sparse arrays. The only problem with algorithms based > on dense arrays is that they might not be very efficient in swift since > elements are not necessarily generated in order. It may just be that > a[0] will make it into the array last due to parallelism. > > So I think updateables > iterators > dense arrays > tail > nothing. > > The question is whether we would design the standard library differently > if we had either of updateables or iterators vs. what we have right now > (nothing) and whether the differences would be significant enough for us > to suspend the standard library discussion until we have these features. > > Mihael > > On Wed, 2015-01-21 at 09:14 -0600, Tim Armstrong wrote: > > I think the ideal scenario might be if we could have these in the > standard > > library, but implemented in Swift. > > > > I tried tried to write Swift code for the min/max problem and it's really > > revealing some weird interactions/limitations around the sparse arrays > and > > iteration constructs provided. > > > > The thing is that there's no straightforward way to iterate in order over > > the set of keys in an array, passing a variable from one iteration to the > > next. My thought process was: > > > > 1. Iterate over array with foreach -> doesn't work, since we can't > pass > > the max from one iteration to the next > > 2. Sequentially iterate over 0..size(A)-1 with for loop -> doesn't > work > > since keys may be sparse or not start at 0 > > 3. Fetch the list of keys and iterate over them with foreach -> > doesn't > > work, since foreach doesn't let us pass max from one iteration to the > next > > 4. Fetch the list of keys, and since we can assume that they're dense, > > iterate over 0..size(A) -1 with a for loop, lookup A[keys[i]], and > update > > the max based on that. > > > > So there is a solution, but it's really ugly - I don't think we should > have > > to create a copy of the array's keys and do a double indirection just to > > calculate min/max. It also feels a little clunky that the eventual > > solution depends on implicit contracts about whether an array's keys are > > dense or not. > > > > We'd have to assume that most users would give up after #1 or #2. Also > > Swift/K doesn't support for loops, so you have to resort to using arrays. > > It's also error prone since many users will neglect to consider that > there > > may be gaps in the array's key space. > > > > I think there's an issue that there is no direct way to get the first > item > > in an array, and no direct way to get the successor to an item in the > > array. head/tail is one solution to that, but seems more natural with > > linked lists than arrays, since the tail operation sort of implies a copy > > of the array, and the tailed array has to support every operation a > normal > > array supports. Supporting iterators over the array might be a good > > alternative. > > > > So I have a couple of proposals: > > > > 1. Support iterators. e.g. it = iterator(A); it2 = next(it). > > 2. Support sequential foreach with some accumulator variables passed > > between iterations. This would likely be implemented with iterators. > > > > Supporting ordered iterators in Swift/T would require work, since we > store > > Swift arrays in hash tables and use string keys, wihch presents two > > problems for finding the next integer value after the current one. > > > > - Tim > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Wed Jan 21 15:55:22 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 21 Jan 2015 13:55:22 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> Message-ID: <1421877322.27780.30.camel@echo> On Wed, 2015-01-21 at 15:04 -0600, Tim Armstrong wrote: > I'm assuming that the size of a dense array would be specified when its > initialized. Then a dense array of size n behaves the same as n individual > variables - there's no reason you have to assign them in order, or iterate > over them in order unless that's what you actually want/need to do. I > agree that trying to have dense arrays that automatically expand in a > parallel language is a bad idea. I think what I said was in reply to your question whether dense arrays would solve the problem. The answer is it would probably help, but it would not lead to ideal solutions. The point would have been that you can use them to emulate tail() by passing a starting index to a recursive function. You need a deterministic way of going through all the indices. Starting at 0 and incrementing is just the most obvious example. However, the creation of the elements is nondeterministic so the order in which elements are created and the order in which an algorithm would "iterate" through such an array would never be the same except for unlikely accidents. The way things are iterated now is with foreach which is also nondeterministic in the way it picks the order, but it roughly matches the order of production. > > I think it's really worth considering, because for a lot of standard > library functions, bad or confusing things will happen if arguments are > sparse arrays. Of course we can document all of these functions to warn > users about doing that, but that requires them to a) actually read the docs > b) understand the distinction c) remember this when they're writing code > and d) be able to trace weird deadlocks or error messages back to the > original cause when they make an inadvertent mistake. I don't mean this as > an insult to users - I could see myself doing all of those things. It > seems very suboptimal. Can you be more specific about "bad or confusing things"? One obvious thing is that a piece of code will access an array element that no other piece of code will ever write. I think this can be detected at array closing time. The same applies to dense arrays: you cannot in general guarantee that all elements in a dense array will be assigned. So you are back to square one. In order to avoid deadlocks, you would still need to track all writes and determine when no more writes to the sparse array will happen (essentially the current closing semantics) and then check if any readers are blocked on the array. > > This is really a separate discussion that doesn't affect the standard > library, but I think the updateable idea, at least in the form that was > proposed on the phone call, is flawed and actually is equivalent to > changing Swift from a language with parallel semantics to a language with > sequential semantics that we're trying to auto-parallelise. I don't think > we want to try to solve the autoparallelisation problem. That is what we are doing IMO and we are letting futures do the work for us. An elegant solution that avoids complex compilers to a large extent. I do, however, agree that we should not try to solve the problem of auto-parallelizing C-like languages unless it turns out that we can do so *easily* and there is a reasonable justification for it. > It's easy to > autoparallelise trivial examples but as soon as a programmer uses something > exotic like an if statement (or an if statement inside a loop, or many more > possibilities) it becomes much harder. I can provide examples that will > break any specific approach if needed. For example, the "versioned" > variables idea doesn't work for this code: > > versioned int x = 1; > > if (...) { > x = 2; > } > > trace(x); > > Does x at the bottom refer to version 0 of the variable or version 1 of the > variable? You can't determine that statically. You might say that you > could define the semantics so that the version x it's referring to depends > on which branch is taken at runtime. Perhaps. Your example reminds me of the issue of keeping track of the number of writers. int x = 1; if (...) { x = 2; } After how many writes do you close x? This is currently solved by the insertion of a balancing else branch: if (...) { x = 2; } else { partialClose(x); } In other words, the compiler keeps track of how many writes are in both branches and inserts closing statements to bring them in sync. I don't see why that couldn't be used for other purposes: if (...) { x = 2; } else { x = x; } It is in a sense what your example code means: "if the condition is true, make x two, otherwise implicitly let x be the same as before". > But then you've reinvented sequential > control flow and all that entails. Once you get loops involved it is much > worse too - it's probably not that hard to come up with an extension that > works ok for this specific example, but adding loops to the equation breaks > it further. Maybe. Or maybe it's in the same class of problems as the writes. I'm not sure. I was floating the idea by. How about just providing function pointers and reduce()? Solves min/max, sum, avg, etc. Does not solve finding all sub-strings in a string. Mihael From tim.g.armstrong at gmail.com Wed Jan 21 17:02:14 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Wed, 21 Jan 2015 17:02:14 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421877322.27780.30.camel@echo> References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> <1421877322.27780.30.camel@echo> Message-ID: I see your point with dense/sparse array errors - there is the prospect of confusing errors in either case. I think with dense arrays, the intent is clearer - the users knows they have to assign elements [0..N-1] and the function knows it can expect elements [0..N-1]. With sparse arrays the user has might readily expect the function to "do the right thing" with the input, since the types check out - getting back to the root cause of the problem would require more steps of inference to get back to the root problem - that the function doesn't do what they expect. That transformation of adding an implicit else branch is really just a way of implementing sequential semantics by adding data dependencies to implement the sequential control dependency. The other example of closing an array is a pure data dependency on the entire value of A rather than a control flow dependency. I don't see Swift as a sequential language that we're autoparallelising though. For one, we let statements with side-effects execute out of order as a general rule. Constructs like foreach are also explicitly allowed to execute out of order. I.e. there is no total order in the program in which statements have to execute, there's just a partial order defined by data flow. To work out which version of a variable is being referred to requires defining a total order. For example, if we involve loops: versioned x = 1; foreach i in A { if (rand()) { x = i; } } I'm going to assume the intended behavior is that the loop iterations execute in some sequential order and each iteration depends on the previous. But this requires that a) the keys of A have a defined order, and b) we don't start iterating over A until we know what the "first" element is, i.e. essentially until A is closed. But that doesn't really square with the idea that iterations of a foreach loop are independent that previously existed. This seems to require that the presence of a variable of a particular type changes the semantics of an enclosing control flow structure. This is really bizarre from a language design point of view. I just think if we want sequential control flow we need to be realistic about the pros and cons that entails. - Tim On Wed, Jan 21, 2015 at 3:55 PM, Mihael Hategan wrote: > On Wed, 2015-01-21 at 15:04 -0600, Tim Armstrong wrote: > > I'm assuming that the size of a dense array would be specified when its > > initialized. Then a dense array of size n behaves the same as n > individual > > variables - there's no reason you have to assign them in order, or > iterate > > over them in order unless that's what you actually want/need to do. I > > agree that trying to have dense arrays that automatically expand in a > > parallel language is a bad idea. > > I think what I said was in reply to your question whether dense arrays > would solve the problem. The answer is it would probably help, but it > would not lead to ideal solutions. The point would have been that you > can use them to emulate tail() by passing a starting index to a > recursive function. You need a deterministic way of going through all > the indices. Starting at 0 and incrementing is just the most obvious > example. However, the creation of the elements is nondeterministic so > the order in which elements are created and the order in which an > algorithm would "iterate" through such an array would never be the same > except for unlikely accidents. > > The way things are iterated now is with foreach which is also > nondeterministic in the way it picks the order, but it roughly matches > the order of production. > > > > > I think it's really worth considering, because for a lot of standard > > library functions, bad or confusing things will happen if arguments are > > sparse arrays. Of course we can document all of these functions to warn > > users about doing that, but that requires them to a) actually read the > docs > > b) understand the distinction c) remember this when they're writing code > > and d) be able to trace weird deadlocks or error messages back to the > > original cause when they make an inadvertent mistake. I don't mean this > as > > an insult to users - I could see myself doing all of those things. It > > seems very suboptimal. > > Can you be more specific about "bad or confusing things"? One obvious > thing is that a piece of code will access an array element that no other > piece of code will ever write. I think this can be detected at array > closing time. The same applies to dense arrays: you cannot in general > guarantee that all elements in a dense array will be assigned. So you > are back to square one. In order to avoid deadlocks, you would still > need to track all writes and determine when no more writes to the sparse > array will happen (essentially the current closing semantics) and then > check if any readers are blocked on the array. > > > > > This is really a separate discussion that doesn't affect the standard > > library, but I think the updateable idea, at least in the form that was > > proposed on the phone call, is flawed and actually is equivalent to > > changing Swift from a language with parallel semantics to a language with > > sequential semantics that we're trying to auto-parallelise. I don't > think > > we want to try to solve the autoparallelisation problem. > > That is what we are doing IMO and we are letting futures do the work for > us. An elegant solution that avoids complex compilers to a large extent. > I do, however, agree that we should not try to solve the problem of > auto-parallelizing C-like languages unless it turns out that we can do > so *easily* and there is a reasonable justification for it. > > > It's easy to > > autoparallelise trivial examples but as soon as a programmer uses > something > > exotic like an if statement (or an if statement inside a loop, or many > more > > possibilities) it becomes much harder. I can provide examples that will > > break any specific approach if needed. For example, the "versioned" > > variables idea doesn't work for this code: > > > > versioned int x = 1; > > > > if (...) { > > x = 2; > > } > > > > trace(x); > > > > Does x at the bottom refer to version 0 of the variable or version 1 of > the > > variable? You can't determine that statically. You might say that you > > could define the semantics so that the version x it's referring to > depends > > on which branch is taken at runtime. > > Perhaps. Your example reminds me of the issue of keeping track of the > number of writers. > > int x = 1; > > if (...) { > x = 2; > } > > After how many writes do you close x? > > This is currently solved by the insertion of a balancing else branch: > > if (...) { > x = 2; > } > else { > partialClose(x); > } > > In other words, the compiler keeps track of how many writes are in both > branches and inserts closing statements to bring them in sync. I don't > see why that couldn't be used for other purposes: > > if (...) { > x = 2; > } > else { > x = x; > } > > It is in a sense what your example code means: "if the condition is > true, make x two, otherwise implicitly let x be the same as before". > > > > But then you've reinvented sequential > > control flow and all that entails. Once you get loops involved it is > much > > worse too - it's probably not that hard to come up with an extension that > > works ok for this specific example, but adding loops to the equation > breaks > > it further. > > Maybe. Or maybe it's in the same class of problems as the writes. I'm > not sure. I was floating the idea by. > > How about just providing function pointers and reduce()? Solves min/max, > sum, avg, etc. Does not solve finding all sub-strings in a string. > > Mihael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.g.armstrong at gmail.com Wed Jan 21 17:09:54 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Wed, 21 Jan 2015 17:09:54 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> <1421877322.27780.30.camel@echo> Message-ID: Function pointers are probably not a short-term addition - might be simpler just to add functions we think are important and have function pointers as a longer-term addition. - Tim On Wed, Jan 21, 2015 at 5:02 PM, Tim Armstrong wrote: > I see your point with dense/sparse array errors - there is the prospect of > confusing errors in either case. I think with dense arrays, the intent is > clearer - the users knows they have to assign elements [0..N-1] and the > function knows it can expect elements [0..N-1]. With sparse arrays the > user has might readily expect the function to "do the right thing" with the > input, since the types check out - getting back to the root cause of the > problem would require more steps of inference to get back to the root > problem - that the function doesn't do what they expect. > > That transformation of adding an implicit else branch is really just a way > of implementing sequential semantics by adding data dependencies to > implement the sequential control dependency. The other example of closing > an array is a pure data dependency on the entire value of A rather than a > control flow dependency. > > I don't see Swift as a sequential language that we're autoparallelising > though. For one, we let statements with side-effects execute out of order > as a general rule. Constructs like foreach are also explicitly allowed to > execute out of order. I.e. there is no total order in the program in which > statements have to execute, there's just a partial order defined by data > flow. To work out which version of a variable is being referred to > requires defining a total order. > > For example, if we involve loops: > > versioned x = 1; > > foreach i in A { > if (rand()) { > x = i; > } > } > > I'm going to assume the intended behavior is that the loop iterations > execute in some sequential order and each iteration depends on the > previous. But this requires that a) the keys of A have a defined order, > and b) we don't start iterating over A until we know what the "first" > element is, i.e. essentially until A is closed. > > But that doesn't really square with the idea that iterations of a foreach > loop are independent that previously existed. This seems to require that > the presence of a variable of a particular type changes the semantics of an > enclosing control flow structure. This is really bizarre from a language > design point of view. > > I just think if we want sequential control flow we need to be realistic > about the pros and cons that entails. > > - Tim > > > On Wed, Jan 21, 2015 at 3:55 PM, Mihael Hategan > wrote: > >> On Wed, 2015-01-21 at 15:04 -0600, Tim Armstrong wrote: >> > I'm assuming that the size of a dense array would be specified when its >> > initialized. Then a dense array of size n behaves the same as n >> individual >> > variables - there's no reason you have to assign them in order, or >> iterate >> > over them in order unless that's what you actually want/need to do. I >> > agree that trying to have dense arrays that automatically expand in a >> > parallel language is a bad idea. >> >> I think what I said was in reply to your question whether dense arrays >> would solve the problem. The answer is it would probably help, but it >> would not lead to ideal solutions. The point would have been that you >> can use them to emulate tail() by passing a starting index to a >> recursive function. You need a deterministic way of going through all >> the indices. Starting at 0 and incrementing is just the most obvious >> example. However, the creation of the elements is nondeterministic so >> the order in which elements are created and the order in which an >> algorithm would "iterate" through such an array would never be the same >> except for unlikely accidents. >> >> The way things are iterated now is with foreach which is also >> nondeterministic in the way it picks the order, but it roughly matches >> the order of production. >> >> > >> > I think it's really worth considering, because for a lot of standard >> > library functions, bad or confusing things will happen if arguments are >> > sparse arrays. Of course we can document all of these functions to warn >> > users about doing that, but that requires them to a) actually read the >> docs >> > b) understand the distinction c) remember this when they're writing code >> > and d) be able to trace weird deadlocks or error messages back to the >> > original cause when they make an inadvertent mistake. I don't mean >> this as >> > an insult to users - I could see myself doing all of those things. It >> > seems very suboptimal. >> >> Can you be more specific about "bad or confusing things"? One obvious >> thing is that a piece of code will access an array element that no other >> piece of code will ever write. I think this can be detected at array >> closing time. The same applies to dense arrays: you cannot in general >> guarantee that all elements in a dense array will be assigned. So you >> are back to square one. In order to avoid deadlocks, you would still >> need to track all writes and determine when no more writes to the sparse >> array will happen (essentially the current closing semantics) and then >> check if any readers are blocked on the array. >> >> > >> > This is really a separate discussion that doesn't affect the standard >> > library, but I think the updateable idea, at least in the form that was >> > proposed on the phone call, is flawed and actually is equivalent to >> > changing Swift from a language with parallel semantics to a language >> with >> > sequential semantics that we're trying to auto-parallelise. I don't >> think >> > we want to try to solve the autoparallelisation problem. >> >> That is what we are doing IMO and we are letting futures do the work for >> us. An elegant solution that avoids complex compilers to a large extent. >> I do, however, agree that we should not try to solve the problem of >> auto-parallelizing C-like languages unless it turns out that we can do >> so *easily* and there is a reasonable justification for it. >> >> > It's easy to >> > autoparallelise trivial examples but as soon as a programmer uses >> something >> > exotic like an if statement (or an if statement inside a loop, or many >> more >> > possibilities) it becomes much harder. I can provide examples that will >> > break any specific approach if needed. For example, the "versioned" >> > variables idea doesn't work for this code: >> > >> > versioned int x = 1; >> > >> > if (...) { >> > x = 2; >> > } >> > >> > trace(x); >> > >> > Does x at the bottom refer to version 0 of the variable or version 1 of >> the >> > variable? You can't determine that statically. You might say that you >> > could define the semantics so that the version x it's referring to >> depends >> > on which branch is taken at runtime. >> >> Perhaps. Your example reminds me of the issue of keeping track of the >> number of writers. >> >> int x = 1; >> >> if (...) { >> x = 2; >> } >> >> After how many writes do you close x? >> >> This is currently solved by the insertion of a balancing else branch: >> >> if (...) { >> x = 2; >> } >> else { >> partialClose(x); >> } >> >> In other words, the compiler keeps track of how many writes are in both >> branches and inserts closing statements to bring them in sync. I don't >> see why that couldn't be used for other purposes: >> >> if (...) { >> x = 2; >> } >> else { >> x = x; >> } >> >> It is in a sense what your example code means: "if the condition is >> true, make x two, otherwise implicitly let x be the same as before". >> >> >> > But then you've reinvented sequential >> > control flow and all that entails. Once you get loops involved it is >> much >> > worse too - it's probably not that hard to come up with an extension >> that >> > works ok for this specific example, but adding loops to the equation >> breaks >> > it further. >> >> Maybe. Or maybe it's in the same class of problems as the writes. I'm >> not sure. I was floating the idea by. >> >> How about just providing function pointers and reduce()? Solves min/max, >> sum, avg, etc. Does not solve finding all sub-strings in a string. >> >> Mihael >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Wed Jan 21 18:02:09 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 21 Jan 2015 16:02:09 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> <1421877322.27780.30.camel@echo> Message-ID: <1421884929.29442.46.camel@echo> On Wed, 2015-01-21 at 17:02 -0600, Tim Armstrong wrote: > I see your point with dense/sparse array errors - there is the prospect of > confusing errors in either case. I think with dense arrays, the intent is > clearer - the users knows they have to assign elements [0..N-1] and the > function knows it can expect elements [0..N-1]. With sparse arrays the > user has might readily expect the function to "do the right thing" with the > input, since the types check out - getting back to the root cause of the > problem would require more steps of inference to get back to the root > problem - that the function doesn't do what they expect. I agree that a fixed-size array is slightly less error-prone in certain scenarios because there is more information known. But it is also easier to check a sparse array for completeness because length(array) will guarantee that all counted elements exist. So I think they are just about the same: an imperfect solution to a complex problem. > > That transformation of adding an implicit else branch is really just a way > of implementing sequential semantics by adding data dependencies to > implement the sequential control dependency. The other example of closing > an array is a pure data dependency on the entire value of A rather than a > control flow dependency. > > I don't see Swift as a sequential language that we're autoparallelising > though. For one, we let statements with side-effects execute out of order > as a general rule. Constructs like foreach are also explicitly allowed to > execute out of order. I.e. there is no total order in the program in which > statements have to execute, there's just a partial order defined by data > flow. To work out which version of a variable is being referred to > requires defining a total order. Right. The data flow provides a total ordering in this case, for a sub-set of statements. These are basically inductive algorithms for which we require indices be spelled out. Ultimately the user only needs to spell out the induction step and the initial (and perhaps final) condition. Perhaps I agree with you in a sense: either spell out all the steps and then require specific indices, or require only initial_value, final_condition and inductive_step and let some library function unfold the whole thing. Probably cleaner, less error-prone, and easier to implement. So, new proposal: lambda arguments and a nice functional set of reduction functions? > > For example, if we involve loops: > > versioned x = 1; > > foreach i in A { > if (rand()) { > x = i; > } > } > > I'm going to assume the intended behavior is that the loop iterations > execute in some sequential order and each iteration depends on the > previous. But this requires that a) the keys of A have a defined order, > and b) we don't start iterating over A until we know what the "first" > element is, i.e. essentially until A is closed. > > But that doesn't really square with the idea that iterations of a foreach > loop are independent that previously existed. Right. It doesn't. If you introduce dependencies between iterations, then iterations are not independent. And there are algorithms that require such dependencies. > This seems to require that > the presence of a variable of a particular type changes the semantics of an > enclosing control flow structure. This is really bizarre from a language > design point of view. I disagree. Without data dependencies the order of execution has always been unspecified in Swift and is explicitly disconnected from the official semantics. We can choose to serialize everything as long as data dependencies are enforced. And we certainly do so if calling apps and only allowing one executable at a time (or if we set foreachMaxThreads to 1). Parallelism is only used for performance and the exact details are left to the implementation to decide/optimize. The only guarantee is that whether serial or parallel or somewhere in-between, swift will produce the same results if the apps are well behaved. The involvement of foreach here is not relevant. One can unfold the foreach completely and say things like a[0] = 1; a[1] = f(a[0]); a[2] = f(a[1]); etc. The results are the same (you can technically write a very large number of these guarded by termination conditions to deal with the fact that a dynamic version of these has a statically unknown number of steps). Mihael From hategan at mcs.anl.gov Wed Jan 21 18:06:38 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 21 Jan 2015 16:06:38 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> <1421877322.27780.30.camel@echo> Message-ID: <1421885198.29442.50.camel@echo> On Wed, 2015-01-21 at 17:09 -0600, Tim Armstrong wrote: > Function pointers are probably not a short-term addition - might be simpler > just to add functions we think are important and have function pointers as > a longer-term addition. I agree. However, comparable in effort to auto-update variables. So maybe we can decide to not waste effort on one of them. Mihael From tim.g.armstrong at gmail.com Thu Jan 22 00:26:02 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Thu, 22 Jan 2015 00:26:02 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421885198.29442.50.camel@echo> References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> <1421877322.27780.30.camel@echo> <1421885198.29442.50.camel@echo> Message-ID: I agree that the language can pick whatever schedule with whatever degree of parallelism as long as it satisfies the partial order defined by data flow and there are no false control dependencies inserted that will prevent progress. The issue is more that adding those variables to the language adds additional ordering requirements based on sequential control flow. A schedule that satisfies the stricter ordering requirements will satisfy the weaker ones (unless the additional dependencies prevent it from making progress), but the difference in ordering requirements is real. I don't think it's all that relevant that it's possible for an implementation to exist that satisfies both semantics in many circumstances. The involvement of foreach is very relevant. You can unfold a foreach to ; under the current semantics. You can also unfold it to ; ; and it's the same. The language needs this to run the iterations out of order based on data availability - there is no problem doing so since the two unfoldings are equivalent. What's being proposed is that the first unfolding is the canonical one, and you can't do the second one unless you prove that it's equivalent. So an implementation must guarantee that the loop iterations *don't* execute out of order unless it analyses the loop body sufficiently to prove that there is nothing in there that depends on the sequential order of loop iterations. But there's another issue. We would need to provide a strong guarantee that the iterations *do* execute out of order if there is nothing in the loop body to prevent them from doing so, since otherwise the program might fail to make progress when it should, or even deadlock if there is some sort of recursive dependency where the array being iterated over depends directly or indirectly on the computation in the loop body. So essentially foreach would have to be one of two different control flow constructs (in-order foreach or out-of-order foreach) depending on what you do inside it. That also doesn't address the issue of other array key types. If you iterate over an array with [auto] keys, what is the canonical order of iterations? Also,, now that I think about it, presumably negative numbers would go before 0, so if you were iterating over an array with integer keys that had keys [0] to [N] filled in, you couldn't process key [0] until the array was entirely closed. Seems strange... I just feel that Swift is fundamentally a language with relaxed ordering. I don't have anything against a more sequential version for some situations but I feel like it's just a different language. - Tim On Wed, Jan 21, 2015 at 6:06 PM, Mihael Hategan wrote: > On Wed, 2015-01-21 at 17:09 -0600, Tim Armstrong wrote: > > Function pointers are probably not a short-term addition - might be > simpler > > just to add functions we think are important and have function pointers > as > > a longer-term addition. > > I agree. However, comparable in effort to auto-update variables. So > maybe we can decide to not waste effort on one of them. > > Mihael > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Thu Jan 22 01:12:40 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 21 Jan 2015 23:12:40 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> <1421877322.27780.30.camel@echo> <1421885198.29442.50.camel@echo> Message-ID: <1421910760.7871.32.camel@echo> On Thu, 2015-01-22 at 00:26 -0600, Tim Armstrong wrote: > I agree that the language can pick whatever schedule with whatever degree > of parallelism as long as it satisfies the partial order defined by data > flow and there are no false control dependencies inserted that will prevent > progress. Right. There would be no false dependencies. But if the user has a data dependency a[i + 1] = f(a[i]) then we can't say that they shouldn't. So the issue is not what dependencies are there but whether we would allow that statement to be written as "a = f(a)". This would allow nothing that isn't already allowed. We should probably drop this though. I think we went past usefulness and I do think that a functional approach is more clear and easy to implement, it has no blanks to fill in, and is almost certainly less contentious. [...] > in the loop body to prevent them from doing so, since otherwise the program > might fail to make progress when it should, or even deadlock if there is > some sort of recursive dependency where the array being iterated over > depends directly or indirectly on the computation in the loop body. Hmm. Maybe I shouldn't point out that K allows this already and perhaps this is the missing piece in the conversation. You can write the following code: float a[]; a[0] = 10; foreach v, k in a { if (a[k] > 0.01) { a[k + 1] = f(a[k]); } } It's meant as a pure dataflow replacement for iterate{}. Mihael From tim.g.armstrong at gmail.com Thu Jan 22 09:22:32 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Thu, 22 Jan 2015 09:22:32 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421910760.7871.32.camel@echo> References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> <1421877322.27780.30.camel@echo> <1421885198.29442.50.camel@echo> <1421910760.7871.32.camel@echo> Message-ID: I'm aware K supports execution loops out of order - I think the out of order execution is the "right" behavior. But it doesn't coexist with versioned variables nicely. In your example the dataflow matches the serial control flow dependencies, so there's no direct ordering conflict, and anyway, there are no versioned variables to cause problems. If you reverse it though, then the data flow and implied serial control flow don't match. This code should work according to my understanding of Swift's current semantics, but the implementation would have to infer that executing the iteration for v=1000 first didn't violate any dependencies arising from sequential control flow: float a[]; a[1000] = 10; foreach v, k in a { if (a[k] > 0.01) { a[k - 1] = f(a[k]); } } If you add in a versioned variable, then the code is definitely going to deadlock because the data dependencies and control dependencies go in opposite directions: float a[]; a[1000] = 10; versioned float x = 1; foreach v, k in a { if (a[k] > x) { a[k - 1] = f(a[k]); x += a[k]; } } There's also another problem even with ascending indices if you add in a versioned variable. In order for the k = 1 iteration to execute and the program to make progress, it has to infer that there is no iteration for k < 1 that would have a version of x that precedes the version of x for the k = 1 iteration. In this example it's possible to prove by induction, but in general it's equivalent to solving the halting problem: float a[]; versioned float x = 1 a[1] = 10; foreach v, k in a { if (a[k] > x) { a[k + 1] = f(a[k]); x = x + a[k] } } So to do some kind of variable versioning you need a sequential foreach loop that has semantics that are not entirely compatible with Swift's existing foreach loop. The only way I can see to make this compatible with existing Swift semantics is to automatically switch between the two foreach loops depending on whether a versioned variable is being modified in the loop. I.e. if you use a versioned variable, you asked for a sequential foreach loop and your code might deadlock. I think having two versions of the foreach loop that are explicitly different may be a good idea with use cases, but it's not a good idea to have them be syntactically identical and switch between incompatible behaviors based on the presence or absence of a variable of a particular type. - Tim On Thu, Jan 22, 2015 at 1:12 AM, Mihael Hategan wrote: > On Thu, 2015-01-22 at 00:26 -0600, Tim Armstrong wrote: > > I agree that the language can pick whatever schedule with whatever degree > > of parallelism as long as it satisfies the partial order defined by data > > flow and there are no false control dependencies inserted that will > prevent > > progress. > > Right. There would be no false dependencies. But if the user has a data > dependency > > a[i + 1] = f(a[i]) > > then we can't say that they shouldn't. So the issue is not what > dependencies are there but whether we would allow that statement to be > written as "a = f(a)". This would allow nothing that isn't already > allowed. > > We should probably drop this though. I think we went past usefulness and > I do think that a functional approach is more clear and easy to > implement, it has no blanks to fill in, and is almost certainly less > contentious. > > [...] > > in the loop body to prevent them from doing so, since otherwise the > program > > might fail to make progress when it should, or even deadlock if there is > > some sort of recursive dependency where the array being iterated over > > depends directly or indirectly on the computation in the loop body. > > Hmm. Maybe I shouldn't point out that K allows this already and perhaps > this is the missing piece in the conversation. You can write the > following code: > > float a[]; > a[0] = 10; > > foreach v, k in a { > if (a[k] > 0.01) { > a[k + 1] = f(a[k]); > } > } > > It's meant as a pure dataflow replacement for iterate{}. > > Mihael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yadunand at uchicago.edu Thu Jan 22 12:17:23 2015 From: yadunand at uchicago.edu (Yadu Nand Babuji) Date: Thu, 22 Jan 2015 12:17:23 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421801780.20062.9.camel@echo> References: <1421801780.20062.9.camel@echo> Message-ID: <54C13EB3.8050605@uchicago.edu> Hi Mihael, I have a request for the some features similar to those provided by python's os library: getcwd remove (/rm) move ? ( python doesn't seem to have this) stat ( For loops which stat for new files ) system ( fix ? ) I've tried to get these through the system() function, but it would be nice to have this done properly. I also like the read/write functions in the I/O section. Saves writing a cat app. Thanks, Yadu On 01/20/2015 06:56 PM, Mihael Hategan wrote: > Hi, > > I made a wiki page on github where we could discuss the standard > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary > > It's a draft and there are some rough edges. In particular: > > - regular expression support: substitutions can be done either directly > or with a combination between a function that returns capture groups and > a formatting function that replaces certain tokens with elements of an > array. One could overload the format() function to, in addition to > standard formatting specs, also support something like %s[index]. Or > have a separate formatting function that only deals with this specific > problem. I'm not sure. > > - some of the array functions may be difficult to implement as > specified, or there may be different functions that solve the problems > better. In particular when joining arrays of arrays, there is some > freedom in how to order the elements of the resulting array. > > - read and write: it may not be easy to implement a read that can return > any type in T. There is some precedent in other languages that support > serialization for this. > > Anyway, I added red exclamation marks and red question marks where > things aren't quite clear. > > I'm assuming that most of us will agree on most of the things. However, > if you have a wildly different proposal, it might be wise to create > another page instead of editing this one. > > Mihael > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel From hategan at mcs.anl.gov Thu Jan 22 12:35:43 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Thu, 22 Jan 2015 10:35:43 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> <1421877322.27780.30.camel@echo> <1421885198.29442.50.camel@echo> <1421910760.7871.32.camel@echo> Message-ID: <1421951743.21745.26.camel@echo> n Thu, 2015-01-22 at 09:22 -0600, Tim Armstrong wrote: > If you reverse it though, then the data flow and implied serial control > flow don't match. This code should work according to my understanding of > Swift's current semantics, but the implementation would have to infer that > executing the iteration for v=1000 first didn't violate any dependencies > arising from sequential control flow: > > float a[]; > a[1000] = 10; > > foreach v, k in a { > if (a[k] > 0.01) { > a[k - 1] = f(a[k]); > } > } There is no sequential control flow. It's a plain swift foreach. The only addition is code to detect when the array can be closed, but absolutely zero code in addition to standard swift in terms of ordering things. > > If you add in a versioned variable, then the code is definitely going to > deadlock because the data dependencies and control dependencies go in > opposite directions: > > float a[]; > a[1000] = 10; > versioned float x = 1; > > foreach v, k in a { > if (a[k] > x) { > a[k - 1] = f(a[k]); > x += a[k]; > } > } I see. The code would potentially be translated to something like this: float a[]; a[1000] = 10; float x[]; x[0] = 1; foreach v, k in a { // implicit iteration counter z starting at 0 if (a[k] > x) { a[k - 1] = f(a[k]); x[z + 1] = x[z] + a[k]; } } There is no way to guarantee that given an iteration with (k, z) you will have an iteration with (k - 1, z + 1) unless you can guarantee that only one iteration will be running at a time (but that breaks if you generate more than one elements of a[] in one iteration). Got it! :) Mihael From hategan at mcs.anl.gov Thu Jan 22 12:41:59 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Thu, 22 Jan 2015 10:41:59 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <54C13EB3.8050605@uchicago.edu> References: <1421801780.20062.9.camel@echo> <54C13EB3.8050605@uchicago.edu> Message-ID: <1421952119.21745.32.camel@echo> On Thu, 2015-01-22 at 12:17 -0600, Yadu Nand Babuji wrote: > Hi Mihael, > > I have a request for the some features similar to those provided by > python's os library: > > getcwd Sure. Perhaps getEnv()? > remove (/rm) > move ? ( python doesn't seem to have this) Like move and remove files? Do you have an example of how these would be used? > stat ( For loops which stat for new files ) Stat on a given file, yes (and there are some question marks there, too), stat to poll for files being added to a directory? I'm not sure. How do you even loop sanely in swift? Do you have a specific need/example? > system ( fix ? ) Sure. Although I'd like Tim's and Justin's input on this. Mihael From yadunand at uchicago.edu Thu Jan 22 14:14:04 2015 From: yadunand at uchicago.edu (Yadu Nand Babuji) Date: Thu, 22 Jan 2015 14:14:04 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421952119.21745.32.camel@echo> References: <1421801780.20062.9.camel@echo> <54C13EB3.8050605@uchicago.edu> <1421952119.21745.32.camel@echo> Message-ID: <54C15A0C.7050009@uchicago.edu> Hi MIhael, Now that I write that snippet/pseudocode, I think baseName and dirName would also be useful. Perhaps stat, is redundant because I can use a mapper for the same result. How do you loop sanely in swift. Well that is a tough question. On 01/22/2015 12:41 PM, Mihael Hategan wrote: > On Thu, 2015-01-22 at 12:17 -0600, Yadu Nand Babuji wrote: >> Hi Mihael, >> e >> I have a request for the some features similar to those provided by >> python's os library: >> >> getcwd > Sure. Perhaps getEnv()? Sure getEnv works just as well. >> remove (/rm) >> move ? ( python doesn't seem to have this) > Like move and remove files? Do you have an example of how these would be > used? I remember a case where a directory is actively getting filled with data that needs to be processed. So, we map the input_queue directory, "move" the file to the active directory and start the processing. file active_files[] ; file completed[]; iterate ( ){ file new_files[] = ; foreach f in new_files{ move ( f, active_files[length(active_files)] ); # We move the file, so that it is not processed again in the next round. completed[length(completed)] = process(active_file); sleep(60); } }until ( status == 10000 ); I do not have a use-case that generates large intermediate files, which need to be removed mid-way through processing. >> stat ( For loops which stat for new files ) > Stat on a given file, yes (and there are some question marks there, > too), stat to poll for files being added to a directory? I'm not sure. > How do you even loop sanely in swift? Do you have a specific > need/example? Perhaps stat is redundant since you can do the same check with a mapper ? I do not know how to answer the "how to loop sanely" question. The example is the same is the one above. >> system ( fix ? ) > Sure. Although I'd like Tim's and Justin's input on this. > Mihael > From hategan at mcs.anl.gov Thu Jan 22 14:46:12 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Thu, 22 Jan 2015 12:46:12 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <54C15A0C.7050009@uchicago.edu> References: <1421801780.20062.9.camel@echo> <54C13EB3.8050605@uchicago.edu> <1421952119.21745.32.camel@echo> <54C15A0C.7050009@uchicago.edu> Message-ID: <1421959572.31315.11.camel@echo> On Thu, 2015-01-22 at 14:14 -0600, Yadu Nand Babuji wrote: > >> remove (/rm) > >> move ? ( python doesn't seem to have this) > > Like move and remove files? Do you have an example of how these would be > > used? > I remember a case where a directory is actively getting filled with data > that needs to be processed. > So, we map the input_queue directory, "move" the file to the active > directory and start the processing. > > file active_files[] ; > file completed[]; > > iterate ( ){ > file new_files[] = ; > foreach f in new_files{ > move ( f, active_files[length(active_files)] ); # We move the file, so that it is not processed again in the next round. > completed[length(completed)] = process(active_file); > sleep(60); > } > }until ( status == 10000 ); Does this work without move()? Say, by doing the move in a script as part of process()? Mihael From yadunand at uchicago.edu Thu Jan 22 14:55:25 2015 From: yadunand at uchicago.edu (Yadu Nand Babuji) Date: Thu, 22 Jan 2015 14:55:25 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421959572.31315.11.camel@echo> References: <1421801780.20062.9.camel@echo> <54C13EB3.8050605@uchicago.edu> <1421952119.21745.32.camel@echo> <54C15A0C.7050009@uchicago.edu> <1421959572.31315.11.camel@echo> Message-ID: <54C163BD.8060608@uchicago.edu> Replies inline -Yadu On 01/22/2015 02:46 PM, Mihael Hategan wrote: > On Thu, 2015-01-22 at 14:14 -0600, Yadu Nand Babuji wrote: >>>> remove (/rm) >>>> move ? ( python doesn't seem to have this) >>> Like move and remove files? Do you have an example of how these would be >>> used? >> I remember a case where a directory is actively getting filled with data >> that needs to be processed. >> So, we map the input_queue directory, "move" the file to the active >> directory and start the processing. >> >> file active_files[] ; >> file completed[]; >> >> iterate ( ){ >> file new_files[] = ; >> foreach f in new_files{ >> move ( f, active_files[length(active_files)] ); # We move the file, so that it is not processed again in the next round. >> completed[length(completed)] = process(active_file); >> sleep(60); >> } >> }until ( status == 10000 ); > Does this work without move()? Say, by doing the move in a script as > part of process()? Of course, that is possible. The only reason I though that an explicit move/remove would make sense is because I think swift should be handling the movement of files involved in the run. Perhaps this isn't as clean as I thought it'd be. > Mihael > From hategan at mcs.anl.gov Thu Jan 22 18:04:29 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Thu, 22 Jan 2015 16:04:29 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <54C163BD.8060608@uchicago.edu> References: <1421801780.20062.9.camel@echo> <54C13EB3.8050605@uchicago.edu> <1421952119.21745.32.camel@echo> <54C15A0C.7050009@uchicago.edu> <1421959572.31315.11.camel@echo> <54C163BD.8060608@uchicago.edu> Message-ID: <1421971469.32698.9.camel@echo> On Thu, 2015-01-22 at 14:55 -0600, Yadu Nand Babuji wrote: > Replies inline > > -Yadu > On 01/22/2015 02:46 PM, Mihael Hategan wrote: > > On Thu, 2015-01-22 at 14:14 -0600, Yadu Nand Babuji wrote: > >>>> remove (/rm) > >>>> move ? ( python doesn't seem to have this) > >>> Like move and remove files? Do you have an example of how these would be > >>> used? > >> I remember a case where a directory is actively getting filled with data > >> that needs to be processed. > >> So, we map the input_queue directory, "move" the file to the active > >> directory and start the processing. > >> > >> file active_files[] ; > >> file completed[]; > >> > >> iterate ( ){ > >> file new_files[] = ; > >> foreach f in new_files{ > >> move ( f, active_files[length(active_files)] ); # We move the file, so that it is not processed again in the next round. > >> completed[length(completed)] = process(active_file); > >> sleep(60); > >> } > >> }until ( status == 10000 ); > > Does this work without move()? Say, by doing the move in a script as > > part of process()? > Of course, that is possible. The only reason I though that an explicit > move/remove would make sense is because > I think swift should be handling the movement of files involved in the > run. Perhaps this isn't as clean as I thought it'd be. I asked because there are a number of issues with that script. For example, the statement a[length(a)] = x should deadlock. So I wanted to know if the rest of the script works. It is not clean, or at least I don't see how it can be made clean. In particular because no function in swift should behave differently depending on when it is run or if it is run multiple times. This is called referential transparency and it says that all f(x) will always have the same value when invoked with the same x. It is the only way I know to guarantee that the not-fully-specified ordering of execution in swift results in correct programs. The problem with move would be that the second invocation of move with the same parameters will have to fail or do nothing since you've already moved the file. Maybe I'm wrong. Thoughts? Mihael From hategan at mcs.anl.gov Thu Jan 22 22:34:06 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Thu, 22 Jan 2015 20:34:06 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421951743.21745.26.camel@echo> References: <1421801780.20062.9.camel@echo> <54BF314A.3020806@anl.gov> <1421828711.21889.23.camel@echo> <1421868041.25580.12.camel@echo> <1421877322.27780.30.camel@echo> <1421885198.29442.50.camel@echo> <1421910760.7871.32.camel@echo> <1421951743.21745.26.camel@echo> Message-ID: <1421987646.3624.12.camel@echo> So what do you think the direction should be? Can we agree that we would generally try to move in the direction of function pointers (and maybe lambda expressions) and provide some functional tools based on that to solve these kinds of problems? I don't personally want to address this now. I think we can have some decent set of tools that don't try to solve everything. But it would be nice to know where things are eventually going. It might inform some of the decisions. Mihael On Thu, 2015-01-22 at 10:35 -0800, Mihael Hategan wrote: > n Thu, 2015-01-22 at 09:22 -0600, Tim Armstrong wrote: > > > If you reverse it though, then the data flow and implied serial control > > flow don't match. This code should work according to my understanding of > > Swift's current semantics, but the implementation would have to infer that > > executing the iteration for v=1000 first didn't violate any dependencies > > arising from sequential control flow: > > > > float a[]; > > a[1000] = 10; > > > > foreach v, k in a { > > if (a[k] > 0.01) { > > a[k - 1] = f(a[k]); > > } > > } > > There is no sequential control flow. It's a plain swift foreach. The > only addition is code to detect when the array can be closed, but > absolutely zero code in addition to standard swift in terms of ordering > things. > > > > > If you add in a versioned variable, then the code is definitely going to > > deadlock because the data dependencies and control dependencies go in > > opposite directions: > > > > float a[]; > > a[1000] = 10; > > versioned float x = 1; > > > > foreach v, k in a { > > if (a[k] > x) { > > a[k - 1] = f(a[k]); > > x += a[k]; > > } > > } > > I see. The code would potentially be translated to something like this: > > float a[]; > a[1000] = 10; > > float x[]; > x[0] = 1; > > foreach v, k in a { // implicit iteration counter z starting at 0 > if (a[k] > x) { > a[k - 1] = f(a[k]); > x[z + 1] = x[z] + a[k]; > } > } > > There is no way to guarantee that given an iteration with (k, z) you > will have an iteration with (k - 1, z + 1) unless you can guarantee that > only one iteration will be running at a time (but that breaks if you > generate more than one elements of a[] in one iteration). > > Got it! :) > > Mihael > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel From hategan at mcs.anl.gov Thu Jan 22 22:42:32 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Thu, 22 Jan 2015 20:42:32 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421971469.32698.9.camel@echo> References: <1421801780.20062.9.camel@echo> <54C13EB3.8050605@uchicago.edu> <1421952119.21745.32.camel@echo> <54C15A0C.7050009@uchicago.edu> <1421959572.31315.11.camel@echo> <54C163BD.8060608@uchicago.edu> <1421971469.32698.9.camel@echo> Message-ID: <1421988152.3624.17.camel@echo> On Thu, 2015-01-22 at 16:04 -0800, Mihael Hategan wrote: > It is not clean, or at least I don't see how it can be made clean. In > particular because no function in swift should behave differently > depending on when it is run or if it is run multiple times. This is > called referential transparency and it says that all f(x) will always > have the same value when invoked with the same x. It is the only way I > know to guarantee that the not-fully-specified ordering of execution in > swift results in correct programs. > This does seem to fit into the idea of side effects contained into an app specification. That is, however, another issue I think. So I'm not sure. I would like to avoid contentious issues if possible. Otherwise we might spent too much time on this. Can we keep it to stuff that doesn't touch on filesystem manipulation and other known weird things? I think there are some functions on that page that are already tricky and should be removed, so, that's probably plenty for now. Mihael From yadudoc1729 at gmail.com Fri Jan 23 01:28:49 2015 From: yadudoc1729 at gmail.com (Yadu Nand) Date: Fri, 23 Jan 2015 01:28:49 -0600 Subject: [Swift-devel] Request for review Tutorial 0.96 Message-ID: Hi, Here's a draft of the new Swift-0.96 tutorial. http://web.ci.uchicago.edu/~yadunandb/www/swift-tutorial/doc/tutorial.html The major changes are that we've moved to 0.96 style configs, merged changes made by Sophia, restructured the layout and added a new mini-guide for the sites. I've also added docs and configs for the ec2-cloud provider. With the changes and the way the new config works, we should not have to create separate tutorials for different sites. This tutorial supports : * midway * beagle * osgconnect * amazon-ec2 * collection of ad-hoc nodes. ?Thanks,? Yadu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ketan at mcs.anl.gov Fri Jan 23 09:48:45 2015 From: ketan at mcs.anl.gov (Ketan Maheshwari) Date: Fri, 23 Jan 2015 09:48:45 -0600 Subject: [Swift-devel] Request for review Tutorial 0.96 In-Reply-To: References: Message-ID: Hi Yadu, The tutorial looks great! Where and how can I make edits/comments? Thanks, Ketan On Fri, Jan 23, 2015 at 1:28 AM, Yadu Nand wrote: > Hi, > > Here's a draft of the new Swift-0.96 tutorial. > http://web.ci.uchicago.edu/~yadunandb/www/swift-tutorial/doc/tutorial.html > > The major changes are that we've moved to 0.96 style configs, merged > changes > made by Sophia, restructured the layout and added a new mini-guide for the > sites. > I've also added docs and configs for the ec2-cloud provider. > > With the changes and the way the new config works, we should not have to > create separate tutorials for different sites. This tutorial supports : > * midway > * beagle > * osgconnect > * amazon-ec2 > * collection of ad-hoc nodes. > > ?Thanks,? > > Yadu > > _______________________________________________ > 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: From yadunand at uchicago.edu Fri Jan 23 11:09:38 2015 From: yadunand at uchicago.edu (Yadu Nand Babuji) Date: Fri, 23 Jan 2015 11:09:38 -0600 Subject: [Swift-devel] Request for review Tutorial 0.96 In-Reply-To: References: Message-ID: <54C28052.8030105@uchicago.edu> Hi Ketan, I've hosted the tutorial here : https://github.com/swift-lang/swift-tutorial You can add asciidoc comments or add an issue here : https://github.com/swift-lang/swift-tutorial/issues Could you check if you have push access to the repo ? If not, please send me your github id and I can add you. Thanks, Yadu On 01/23/2015 09:48 AM, Ketan Maheshwari wrote: > Hi Yadu, > > The tutorial looks great! Where and how can I make edits/comments? > > Thanks, > Ketan > > On Fri, Jan 23, 2015 at 1:28 AM, Yadu Nand > wrote: > > Hi, > > Here's a draft of the new Swift-0.96 tutorial. > http://web.ci.uchicago.edu/~yadunandb/www/swift-tutorial/doc/tutorial.html > > > The major changes are that we've moved to 0.96 style configs, > merged changes > made by Sophia, restructured the layout and added a new mini-guide > for the sites. > I've also added docs and configs for the ec2-cloud provider. > > With the changes and the way the new config works, we should not > have to > create separate tutorials for different sites. This tutorial > supports : > * midway > * beagle > * osgconnect > * amazon-ec2 > * collection of ad-hoc nodes. > > ? Thanks,? > Yadu > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > _______________________________________________ > 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: From tim.g.armstrong at gmail.com Fri Jan 23 11:25:47 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Fri, 23 Jan 2015 11:25:47 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421988152.3624.17.camel@echo> References: <1421801780.20062.9.camel@echo> <54C13EB3.8050605@uchicago.edu> <1421952119.21745.32.camel@echo> <54C15A0C.7050009@uchicago.edu> <1421959572.31315.11.camel@echo> <54C163BD.8060608@uchicago.edu> <1421971469.32698.9.camel@echo> <1421988152.3624.17.camel@echo> Message-ID: There's a Swift/T issue for this, btw, if that's of any relevance. I think the low-hanging fruit of consistent names for common functions have the highest impact here, so I agree we can move forward on the easy things. - Tim On Thu, Jan 22, 2015 at 10:42 PM, Mihael Hategan wrote: > On Thu, 2015-01-22 at 16:04 -0800, Mihael Hategan wrote: > > > It is not clean, or at least I don't see how it can be made clean. In > > particular because no function in swift should behave differently > > depending on when it is run or if it is run multiple times. This is > > called referential transparency and it says that all f(x) will always > > have the same value when invoked with the same x. It is the only way I > > know to guarantee that the not-fully-specified ordering of execution in > > swift results in correct programs. > > > > This does seem to fit into the idea of side effects contained into an > app specification. That is, however, another issue I think. > > So I'm not sure. I would like to avoid contentious issues if possible. > Otherwise we might spent too much time on this. Can we keep it to stuff > that doesn't touch on filesystem manipulation and other known weird > things? > > I think there are some functions on that page that are already tricky > and should be removed, so, that's probably plenty for now. > > 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: From yadunand at uchicago.edu Fri Jan 23 11:39:02 2015 From: yadunand at uchicago.edu (Yadu Nand Babuji) Date: Fri, 23 Jan 2015 11:39:02 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1421988152.3624.17.camel@echo> References: <1421801780.20062.9.camel@echo> <54C13EB3.8050605@uchicago.edu> <1421952119.21745.32.camel@echo> <54C15A0C.7050009@uchicago.edu> <1421959572.31315.11.camel@echo> <54C163BD.8060608@uchicago.edu> <1421971469.32698.9.camel@echo> <1421988152.3624.17.camel@echo> Message-ID: <54C28736.9080606@uchicago.edu> I was a bit confused about this because we have read() on the wiki, which can return different results when invoked multiple times. I agree with putting filesystem functions on hold instead of getting bogged down in discussion limbo. -Yadu On 01/22/2015 10:42 PM, Mihael Hategan wrote: > On Thu, 2015-01-22 at 16:04 -0800, Mihael Hategan wrote: > >> It is not clean, or at least I don't see how it can be made clean. In >> particular because no function in swift should behave differently >> depending on when it is run or if it is run multiple times. This is >> called referential transparency and it says that all f(x) will always >> have the same value when invoked with the same x. It is the only way I >> know to guarantee that the not-fully-specified ordering of execution in >> swift results in correct programs. >> > This does seem to fit into the idea of side effects contained into an > app specification. That is, however, another issue I think. > > So I'm not sure. I would like to avoid contentious issues if possible. > Otherwise we might spent too much time on this. Can we keep it to stuff > that doesn't touch on filesystem manipulation and other known weird > things? > > I think there are some functions on that page that are already tricky > and should be removed, so, that's probably plenty for now. > > Mihael > From hategan at mcs.anl.gov Fri Jan 23 12:03:45 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Fri, 23 Jan 2015 10:03:45 -0800 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <54C28736.9080606@uchicago.edu> References: <1421801780.20062.9.camel@echo> <54C13EB3.8050605@uchicago.edu> <1421952119.21745.32.camel@echo> <54C15A0C.7050009@uchicago.edu> <1421959572.31315.11.camel@echo> <54C163BD.8060608@uchicago.edu> <1421971469.32698.9.camel@echo> <1421988152.3624.17.camel@echo> <54C28736.9080606@uchicago.edu> Message-ID: <1422036225.9981.9.camel@echo> On Fri, 2015-01-23 at 11:39 -0600, Yadu Nand Babuji wrote: > I was a bit confused about this because we have read() on the wiki, > which can return > different results when invoked multiple times. read("a.txt") == read("a.txt"). It only returns different results if somebody magically changes the file. Move() would be a function that implements such type of magic. Mihael From ketan at mcs.anl.gov Fri Jan 23 13:36:29 2015 From: ketan at mcs.anl.gov (Ketan Maheshwari) Date: Fri, 23 Jan 2015 13:36:29 -0600 Subject: [Swift-devel] Swift function from command line Message-ID: Hello, This came up in a meeting today. I was wondering if it is possible to run an arbitrary swift function from Swift command line? Something along the lines of: swift -cli pow(3,2) I think this feature has been discussed in the past but am not sure if it is available currently or is a planned feature. Thanks, Ketan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Fri Jan 23 13:55:39 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Fri, 23 Jan 2015 11:55:39 -0800 Subject: [Swift-devel] Swift function from command line In-Reply-To: References: Message-ID: <1422042939.11845.3.camel@echo> swift -e Mihael On Fri, 2015-01-23 at 13:36 -0600, Ketan Maheshwari wrote: > Hello, > > This came up in a meeting today. I was wondering if it is possible to run > an arbitrary swift function from Swift command line? Something along the > lines of: > > swift -cli pow(3,2) > > I think this feature has been discussed in the past but am not sure if it > is available currently or is a planned feature. > > Thanks, > Ketan > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel From tim.g.armstrong at gmail.com Fri Jan 23 14:05:50 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Fri, 23 Jan 2015 14:05:50 -0600 Subject: [Swift-devel] Standard Library Proposal/Discussion Page In-Reply-To: <1422036225.9981.9.camel@echo> References: <1421801780.20062.9.camel@echo> <54C13EB3.8050605@uchicago.edu> <1421952119.21745.32.camel@echo> <54C15A0C.7050009@uchicago.edu> <1421959572.31315.11.camel@echo> <54C163BD.8060608@uchicago.edu> <1421971469.32698.9.camel@echo> <1421988152.3624.17.camel@echo> <54C28736.9080606@uchicago.edu> <1422036225.9981.9.camel@echo> Message-ID: I added a few more minor comments to the wiki page. I think we're probably at the point where I can start to implement some of them. - Tim On Fri, Jan 23, 2015 at 12:03 PM, Mihael Hategan wrote: > On Fri, 2015-01-23 at 11:39 -0600, Yadu Nand Babuji wrote: > > I was a bit confused about this because we have read() on the wiki, > > which can return > > different results when invoked multiple times. > > read("a.txt") == read("a.txt"). > > It only returns different results if somebody magically changes the > file. Move() would be a function that implements such type of magic. > > 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: From ketan at mcs.anl.gov Fri Jan 23 22:25:18 2015 From: ketan at mcs.anl.gov (Ketan Maheshwari) Date: Fri, 23 Jan 2015 22:25:18 -0600 Subject: [Swift-devel] Request for review Tutorial 0.96 In-Reply-To: <54C28052.8030105@uchicago.edu> References: <54C28052.8030105@uchicago.edu> Message-ID: Please add me: ketancmaheshwari On Fri, Jan 23, 2015 at 11:09 AM, Yadu Nand Babuji wrote: > Hi Ketan, > > I've hosted the tutorial here : > https://github.com/swift-lang/swift-tutorial > > You can add asciidoc comments or add an issue here : > https://github.com/swift-lang/swift-tutorial/issues > > Could you check if you have push access to the repo ? If not, please send > me your github id and I can add you. > > Thanks, > Yadu > > > On 01/23/2015 09:48 AM, Ketan Maheshwari wrote: > > Hi Yadu, > > The tutorial looks great! Where and how can I make edits/comments? > > Thanks, > Ketan > > On Fri, Jan 23, 2015 at 1:28 AM, Yadu Nand wrote: > >> Hi, >> >> Here's a draft of the new Swift-0.96 tutorial. >> http://web.ci.uchicago.edu/~yadunandb/www/swift-tutorial/doc/tutorial.html >> >> The major changes are that we've moved to 0.96 style configs, merged >> changes >> made by Sophia, restructured the layout and added a new mini-guide for >> the sites. >> I've also added docs and configs for the ec2-cloud provider. >> >> With the changes and the way the new config works, we should not have to >> create separate tutorials for different sites. This tutorial supports : >> * midway >> * beagle >> * osgconnect >> * amazon-ec2 >> * collection of ad-hoc nodes. >> >> ? Thanks,? >> >> Yadu >> >> _______________________________________________ >> Swift-devel mailing list >> Swift-devel at ci.uchicago.edu >> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel >> >> > > > _______________________________________________ > Swift-devel mailing listSwift-devel at ci.uchicago.eduhttps://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > _______________________________________________ > 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: From yadudoc1729 at gmail.com Tue Jan 27 16:28:14 2015 From: yadudoc1729 at gmail.com (Yadu Nand) Date: Tue, 27 Jan 2015 16:28:14 -0600 Subject: [Swift-devel] ssh-cl how to tell coaster bootstrap to run with limited java heap space In-Reply-To: <1379629274.31127.1.camel@echo> References: <1379623710.27686.0.camel@echo> <1379624192.30114.2.camel@echo> <1379629274.31127.1.camel@echo> Message-ID: Hi Ketan, Mihael, I'm trying to get the Xsede resources added to the tutorial list and I ran into the same issue that Ketan reported on Gordon. Does either of you remember if we got swift running on Gordon ? Thanks, Yadu On Thu, Sep 19, 2013 at 5:21 PM, Mihael Hategan wrote: > Well, if the limit is 256M and only the heap takes 256M, I don't think > the process will fit in there. There's more memory in the JVM than just > the heap. I suggest you try lower values. However, it's likely that the > coaster service will then run out of heap space. > > Mihael > > On Thu, 2013-09-19 at 17:10 -0500, Ketan Maheshwari wrote: > > Changing the line to 256M and rebuilding Swift somehow did not have any > > effect on the run. I agree, an ability to run coaster service on compute > > node will help. XSEDE Stampede also has the same and other constraints in > > place. > > > > > > On Thu, Sep 19, 2013 at 3:56 PM, Mihael Hategan > wrote: > > > > > The coaster bootstrap starts the service with 512M on 64 bit machines. > > > > > > It can be changed in the code: > > > > org.globus.cog.abstraction.impl.execution.coaster.bootstrap.Bootstrap.java, > > > line 191. The other solution is to run the service on a compute node, > but I > > > don't think we ever spent enough effort on nailing that issue down. > Maybe > > > it's time to do so. > > > > > > On Thu, 2013-09-19 at 15:53 -0500, Ketan Maheshwari wrote: > > > > Yes, 64 bit running CentOS release 6.4 > > > > > > > > > > > > On Thu, Sep 19, 2013 at 3:48 PM, Mihael Hategan > > > > wrote: > > > > > > > > > Are the login nodes 64 bit by any chance? > > > > > > > > > > On Thu, 2013-09-19 at 15:43 -0500, Ketan Maheshwari wrote: > > > > > > SDSC Gordon admins have limited java heap space to 256 on login > > > nodes. > > > > > > > > > > > > This is enabled via the following environment variable: > > > > > > > > > > > > JAVA_TOOL_OPTIONS=-Xmx256m > > > > > > > > > > > > It seems coaster bootstrap does not like this: > > > > > > > > > > > > mdw$ swift -sites.file sites.gordon.xml -tc.file apps -config cf > > > > > > workflow.swift > > > > > > Swift trunk swift-r7089 cog-r3775 > > > > > > RunID: 20130919-2038-jef0ns83 > > > > > > Progress: time: Thu, 19 Sep 2013 20:38:42 +0000 > > > > > > Progress: time: Thu, 19 Sep 2013 20:38:43 +0000 Submitting:2 > > > > > > > > > > > > Execution failed: > > > > > > Exception in matrixgen: > > > > > > Arguments: [2544, 3300, mA.dat] > > > > > > Host: gordon > > > > > > Directory: > > > workflow-20130919-2038-jef0ns83/jobs/a/matrixgen-a1rnkhfl > > > > > > exception @ swift-int-staging.k, line: 162 > > > > > > Caused by: null > > > > > > Caused by: > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > Could > > > > > > not submit job > > > > > > Caused by: > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > Could > > > > > > not start coaster service > > > > > > Caused by: > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > Task > > > > > > ended before registration was received. > > > > > > > > > > > > Picked up JAVA_TOOL_OPTIONS: -Xmx256m > > > > > > /bin/bash: line 54: 33675 Aborted > > > > > /usr/java/latest/bin/java > > > > > > -Djava=/usr/java/latest/bin/java > -DGLOBUS_TCP_PORT_RANGE=50000,51000 > > > > > > > -DX509_USER_PROXY=/home/ketan/.globus/sshproxy-316831905-1379663604 > > > > > > > > > -DX509_CERT_DIR=/home/ketan/.globus/sshCAcert-316831905-1379663604.pem > > > > > > -DGLOBUS_HOSTNAME=gordon.sdsc.xsede.org -Duser.home=/home/ketan > -jar > > > > > > /tmp/bootstrap.RWIqFu http://swift.rcc.uchicago.edu:50001 > > > > > > https://128.135.112.73:50000 11836079986 > > > > > > > > > > > > > > > > > > Do I understand right that this is indeed the java heap space > issue? > > > or > > > > > is > > > > > > it something else that I could work around with? Thanks for any > > > ideas. > > > > > > > > > > > > SDSC Gordon admins have limited java heap space to 256 on login > > > nodes. > > > > > > > > > > > > > > > > > > This is enabled via the following environment variable: > > > > > > > > > > > > JAVA_TOOL_OPTIONS=-Xmx256m > > > > > > > > > > > > > > > > > > It seems coaster bootstrap does not like this: > > > > > > > > > > > > mdw$ swift -sites.file sites.gordon.xml -tc.file apps -config cf > > > > > > workflow.swift > > > > > > Swift trunk swift-r7089 cog-r3775 > > > > > > RunID: 20130919-2038-jef0ns83 > > > > > > Progress: time: Thu, 19 Sep 2013 20:38:42 +0000 > > > > > > Progress: time: Thu, 19 Sep 2013 20:38:43 +0000 Submitting:2 > > > > > > > > > > > > Execution failed: > > > > > > Exception in matrixgen: > > > > > > Arguments: [2544, 3300, mA.dat] > > > > > > Host: gordon > > > > > > Directory: > > > > > > workflow-20130919-2038-jef0ns83/jobs/a/matrixgen-a1rnkhfl > > > > > > exception @ swift-int-staging.k, line: 162 > > > > > > Caused by: null > > > > > > Caused by: > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > > Could not submit job > > > > > > Caused by: > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > > Could not start coaster service > > > > > > Caused by: > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > > Task ended before registration was received. > > > > > > > > > > > > Picked up JAVA_TOOL_OPTIONS: -Xmx256m > > > > > > /bin/bash: line 54: 33675 > > > > > > Aborted /usr/java/latest/bin/java > > > > > > -Djava=/usr/java/latest/bin/java > -DGLOBUS_TCP_PORT_RANGE=50000,51000 > > > > > > > -DX509_USER_PROXY=/home/ketan/.globus/sshproxy-316831905-1379663604 > > > > > > > > > -DX509_CERT_DIR=/home/ketan/.globus/sshCAcert-316831905-1379663604.pem > > > > > > -DGLOBUS_HOSTNAME=gordon.sdsc.xsede.org -Duser.home=/home/ketan > > > > > > -jar /tmp/bootstrap.RWIqFu http://swift.rcc.uchicago.edu:50001 > > > > > > https://128.135.112.73:50000 11836079986 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do I understand right that this is indeed the java heap space > issue? > > > > > > or is it something else that I could work around with? Thanks > for any > > > > > > ideas. > > > > > > > > > > > > > > > > > > -- > > > > > > Ketan > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Swift-devel mailing list > > > > > > Swift-devel at ci.uchicago.edu > > > > > > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, 64 bit running CentOS release 6.4 > > > > > > > > > > > > > > > > On Thu, Sep 19, 2013 at 3:48 PM, Mihael Hategan > > > > > wrote: > > > > Are the login nodes 64 bit by any chance? > > > > > > > > On Thu, 2013-09-19 at 15:43 -0500, Ketan Maheshwari wrote: > > > > > SDSC Gordon admins have limited java heap space to 256 on > > > > login nodes. > > > > > > > > > > This is enabled via the following environment variable: > > > > > > > > > > JAVA_TOOL_OPTIONS=-Xmx256m > > > > > > > > > > It seems coaster bootstrap does not like this: > > > > > > > > > > mdw$ swift -sites.file sites.gordon.xml -tc.file apps > > > > -config cf > > > > > workflow.swift > > > > > Swift trunk swift-r7089 cog-r3775 > > > > > RunID: 20130919-2038-jef0ns83 > > > > > Progress: time: Thu, 19 Sep 2013 20:38:42 +0000 > > > > > Progress: time: Thu, 19 Sep 2013 20:38:43 +0000 > > > > Submitting:2 > > > > > > > > > > Execution failed: > > > > > Exception in matrixgen: > > > > > Arguments: [2544, 3300, mA.dat] > > > > > Host: gordon > > > > > Directory: > > > > workflow-20130919-2038-jef0ns83/jobs/a/matrixgen-a1rnkhfl > > > > > exception @ swift-int-staging.k, line: 162 > > > > > Caused by: null > > > > > Caused by: > > > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > Could > > > > > not submit job > > > > > Caused by: > > > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > Could > > > > > not start coaster service > > > > > Caused by: > > > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > Task > > > > > ended before registration was received. > > > > > > > > > > Picked up JAVA_TOOL_OPTIONS: -Xmx256m > > > > > /bin/bash: line 54: 33675 Aborted > > > > /usr/java/latest/bin/java > > > > > -Djava=/usr/java/latest/bin/java > > > > -DGLOBUS_TCP_PORT_RANGE=50000,51000 > > > > > > > > > > > > -DX509_USER_PROXY=/home/ketan/.globus/sshproxy-316831905-1379663604 > > > > > > > > > > > > -DX509_CERT_DIR=/home/ketan/.globus/sshCAcert-316831905-1379663604.pem > > > > > -DGLOBUS_HOSTNAME=gordon.sdsc.xsede.org > > > > -Duser.home=/home/ketan -jar > > > > > /tmp/bootstrap.RWIqFu http://swift.rcc.uchicago.edu:50001 > > > > > https://128.135.112.73:50000 11836079986 > > > > > > > > > > > > > > > Do I understand right that this is indeed the java heap > > > > space issue? or is > > > > > it something else that I could work around with? Thanks for > > > > any ideas. > > > > > > > > > > SDSC Gordon admins have limited java heap space to 256 on > > > > login nodes. > > > > > > > > > > > > > > > This is enabled via the following environment variable: > > > > > > > > > > JAVA_TOOL_OPTIONS=-Xmx256m > > > > > > > > > > > > > > > It seems coaster bootstrap does not like this: > > > > > > > > > > mdw$ swift -sites.file sites.gordon.xml -tc.file apps > > > > -config cf > > > > > workflow.swift > > > > > Swift trunk swift-r7089 cog-r3775 > > > > > RunID: 20130919-2038-jef0ns83 > > > > > Progress: time: Thu, 19 Sep 2013 20:38:42 +0000 > > > > > Progress: time: Thu, 19 Sep 2013 20:38:43 +0000 > > > > Submitting:2 > > > > > > > > > > Execution failed: > > > > > Exception in matrixgen: > > > > > Arguments: [2544, 3300, mA.dat] > > > > > Host: gordon > > > > > Directory: > > > > > workflow-20130919-2038-jef0ns83/jobs/a/matrixgen-a1rnkhfl > > > > > exception @ swift-int-staging.k, line: 162 > > > > > Caused by: null > > > > > Caused by: > > > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > Could not submit job > > > > > Caused by: > > > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > Could not start coaster service > > > > > Caused by: > > > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > Task ended before registration was received. > > > > > > > > > > Picked up JAVA_TOOL_OPTIONS: -Xmx256m > > > > > /bin/bash: line 54: 33675 > > > > > Aborted /usr/java/latest/bin/java > > > > > -Djava=/usr/java/latest/bin/java > > > > -DGLOBUS_TCP_PORT_RANGE=50000,51000 > > > > > > > > > > > > -DX509_USER_PROXY=/home/ketan/.globus/sshproxy-316831905-1379663604 > > > > > > > > > > > > -DX509_CERT_DIR=/home/ketan/.globus/sshCAcert-316831905-1379663604.pem > > > > > -DGLOBUS_HOSTNAME=gordon.sdsc.xsede.org > > > > -Duser.home=/home/ketan > > > > > -jar /tmp/bootstrap.RWIqFu > > > > http://swift.rcc.uchicago.edu:50001 > > > > > https://128.135.112.73:50000 11836079986 > > > > > > > > > > > > > > > > > > > > > > > > > Do I understand right that this is indeed the java heap > > > > space issue? > > > > > or is it something else that I could work around with? > > > > Thanks for any > > > > > ideas. > > > > > > > > > > > > > > > -- > > > > > Ketan > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Swift-devel mailing list > > > > > Swift-devel at ci.uchicago.edu > > > > > > > > > > > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > Changing the line to 256M and rebuilding Swift somehow did not have > > any effect on the run. I agree, an ability to run coaster service on > > compute node will help. XSEDE Stampede also has the same and other > > constraints in place. > > > > > > > > On Thu, Sep 19, 2013 at 3:56 PM, Mihael Hategan > > wrote: > > The coaster bootstrap starts the service with 512M on 64 bit > > machines. > > > > It can be changed in the code: > > > org.globus.cog.abstraction.impl.execution.coaster.bootstrap.Bootstrap.java, > line 191. The other solution is to run the service on a compute node, but I > don't think we ever spent enough effort on nailing that issue down. Maybe > it's time to do so. > > > > On Thu, 2013-09-19 at 15:53 -0500, Ketan Maheshwari wrote: > > > Yes, 64 bit running CentOS release 6.4 > > > > > > > > > On Thu, Sep 19, 2013 at 3:48 PM, Mihael Hategan > > wrote: > > > > > > > Are the login nodes 64 bit by any chance? > > > > > > > > On Thu, 2013-09-19 at 15:43 -0500, Ketan Maheshwari wrote: > > > > > SDSC Gordon admins have limited java heap space to 256 > > on login nodes. > > > > > > > > > > This is enabled via the following environment variable: > > > > > > > > > > JAVA_TOOL_OPTIONS=-Xmx256m > > > > > > > > > > It seems coaster bootstrap does not like this: > > > > > > > > > > mdw$ swift -sites.file sites.gordon.xml -tc.file apps > > -config cf > > > > > workflow.swift > > > > > Swift trunk swift-r7089 cog-r3775 > > > > > RunID: 20130919-2038-jef0ns83 > > > > > Progress: time: Thu, 19 Sep 2013 20:38:42 +0000 > > > > > Progress: time: Thu, 19 Sep 2013 20:38:43 +0000 > > Submitting:2 > > > > > > > > > > Execution failed: > > > > > Exception in matrixgen: > > > > > Arguments: [2544, 3300, mA.dat] > > > > > Host: gordon > > > > > Directory: > > workflow-20130919-2038-jef0ns83/jobs/a/matrixgen-a1rnkhfl > > > > > exception @ swift-int-staging.k, line: 162 > > > > > Caused by: null > > > > > Caused by: > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > Could > > > > > not submit job > > > > > Caused by: > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > Could > > > > > not start coaster service > > > > > Caused by: > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: Task > > > > > ended before registration was received. > > > > > > > > > > Picked up JAVA_TOOL_OPTIONS: -Xmx256m > > > > > /bin/bash: line 54: 33675 Aborted > > > > /usr/java/latest/bin/java > > > > > -Djava=/usr/java/latest/bin/java > > -DGLOBUS_TCP_PORT_RANGE=50000,51000 > > > > > > > > -DX509_USER_PROXY=/home/ketan/.globus/sshproxy-316831905-1379663604 > > > > > > > > -DX509_CERT_DIR=/home/ketan/.globus/sshCAcert-316831905-1379663604.pem > > > > > -DGLOBUS_HOSTNAME=gordon.sdsc.xsede.org > > -Duser.home=/home/ketan -jar > > > > > /tmp/bootstrap.RWIqFu > > http://swift.rcc.uchicago.edu:50001 > > > > > https://128.135.112.73:50000 11836079986 > > > > > > > > > > > > > > > Do I understand right that this is indeed the java heap > > space issue? or > > > > is > > > > > it something else that I could work around with? Thanks > > for any ideas. > > > > > > > > > > SDSC Gordon admins have limited java heap space to 256 > > on login nodes. > > > > > > > > > > > > > > > This is enabled via the following environment variable: > > > > > > > > > > JAVA_TOOL_OPTIONS=-Xmx256m > > > > > > > > > > > > > > > It seems coaster bootstrap does not like this: > > > > > > > > > > mdw$ swift -sites.file sites.gordon.xml -tc.file apps > > -config cf > > > > > workflow.swift > > > > > Swift trunk swift-r7089 cog-r3775 > > > > > RunID: 20130919-2038-jef0ns83 > > > > > Progress: time: Thu, 19 Sep 2013 20:38:42 +0000 > > > > > Progress: time: Thu, 19 Sep 2013 20:38:43 +0000 > > Submitting:2 > > > > > > > > > > Execution failed: > > > > > Exception in matrixgen: > > > > > Arguments: [2544, 3300, mA.dat] > > > > > Host: gordon > > > > > Directory: > > > > > > > workflow-20130919-2038-jef0ns83/jobs/a/matrixgen-a1rnkhfl > > > > > exception @ swift-int-staging.k, line: 162 > > > > > Caused by: null > > > > > Caused by: > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > Could not submit job > > > > > Caused by: > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > Could not start coaster service > > > > > Caused by: > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > > Task ended before registration was received. > > > > > > > > > > Picked up JAVA_TOOL_OPTIONS: -Xmx256m > > > > > /bin/bash: line 54: 33675 > > > > > Aborted /usr/java/latest/bin/java > > > > > -Djava=/usr/java/latest/bin/java > > -DGLOBUS_TCP_PORT_RANGE=50000,51000 > > > > > > > > -DX509_USER_PROXY=/home/ketan/.globus/sshproxy-316831905-1379663604 > > > > > > > > -DX509_CERT_DIR=/home/ketan/.globus/sshCAcert-316831905-1379663604.pem > > > > > -DGLOBUS_HOSTNAME=gordon.sdsc.xsede.org > > -Duser.home=/home/ketan > > > > > -jar /tmp/bootstrap.RWIqFu > > http://swift.rcc.uchicago.edu:50001 > > > > > https://128.135.112.73:50000 11836079986 > > > > > > > > > > > > > > > > > > > > > > > > > Do I understand right that this is indeed the java heap > > space issue? > > > > > or is it something else that I could work around with? > > Thanks for any > > > > > ideas. > > > > > > > > > > > > > > > -- > > > > > Ketan > > > > > > > > > > > > > > > _______________________________________________ > > > > > Swift-devel mailing list > > > > > Swift-devel at ci.uchicago.edu > > > > > > > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > > > > > > > > > > > > > > > > > Yes, 64 bit running CentOS release 6.4 > > > > > > > > > > > > On Thu, Sep 19, 2013 at 3:48 PM, Mihael Hategan > > > > > wrote: > > > Are the login nodes 64 bit by any chance? > > > > > > On Thu, 2013-09-19 at 15:43 -0500, Ketan Maheshwari > > wrote: > > > > SDSC Gordon admins have limited java heap space to > > 256 on > > > login nodes. > > > > > > > > This is enabled via the following environment > > variable: > > > > > > > > JAVA_TOOL_OPTIONS=-Xmx256m > > > > > > > > It seems coaster bootstrap does not like this: > > > > > > > > mdw$ swift -sites.file sites.gordon.xml -tc.file > > apps > > > -config cf > > > > workflow.swift > > > > Swift trunk swift-r7089 cog-r3775 > > > > RunID: 20130919-2038-jef0ns83 > > > > Progress: time: Thu, 19 Sep 2013 20:38:42 +0000 > > > > Progress: time: Thu, 19 Sep 2013 20:38:43 +0000 > > > Submitting:2 > > > > > > > > Execution failed: > > > > Exception in matrixgen: > > > > Arguments: [2544, 3300, mA.dat] > > > > Host: gordon > > > > Directory: > > > > > workflow-20130919-2038-jef0ns83/jobs/a/matrixgen-a1rnkhfl > > > > exception @ swift-int-staging.k, line: 162 > > > > Caused by: null > > > > Caused by: > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: Could > > > > not submit job > > > > Caused by: > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: Could > > > > not start coaster service > > > > Caused by: > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: Task > > > > ended before registration was received. > > > > > > > > Picked up JAVA_TOOL_OPTIONS: -Xmx256m > > > > /bin/bash: line 54: 33675 Aborted > > > /usr/java/latest/bin/java > > > > -Djava=/usr/java/latest/bin/java > > > -DGLOBUS_TCP_PORT_RANGE=50000,51000 > > > > > > > > > > -DX509_USER_PROXY=/home/ketan/.globus/sshproxy-316831905-1379663604 > > > > > > > > > > -DX509_CERT_DIR=/home/ketan/.globus/sshCAcert-316831905-1379663604.pem > > > > -DGLOBUS_HOSTNAME=gordon.sdsc.xsede.org > > > -Duser.home=/home/ketan -jar > > > > /tmp/bootstrap.RWIqFu > > http://swift.rcc.uchicago.edu:50001 > > > > https://128.135.112.73:50000 11836079986 > > > > > > > > > > > > Do I understand right that this is indeed the java > > heap > > > space issue? or is > > > > it something else that I could work around with? > > Thanks for > > > any ideas. > > > > > > > > SDSC Gordon admins have limited java heap space to > > 256 on > > > login nodes. > > > > > > > > > > > > This is enabled via the following environment > > variable: > > > > > > > > JAVA_TOOL_OPTIONS=-Xmx256m > > > > > > > > > > > > It seems coaster bootstrap does not like this: > > > > > > > > mdw$ swift -sites.file sites.gordon.xml -tc.file > > apps > > > -config cf > > > > workflow.swift > > > > Swift trunk swift-r7089 cog-r3775 > > > > RunID: 20130919-2038-jef0ns83 > > > > Progress: time: Thu, 19 Sep 2013 20:38:42 +0000 > > > > Progress: time: Thu, 19 Sep 2013 20:38:43 +0000 > > > Submitting:2 > > > > > > > > Execution failed: > > > > Exception in matrixgen: > > > > Arguments: [2544, 3300, mA.dat] > > > > Host: gordon > > > > Directory: > > > > > > workflow-20130919-2038-jef0ns83/jobs/a/matrixgen-a1rnkhfl > > > > exception @ swift-int-staging.k, line: 162 > > > > Caused by: null > > > > Caused by: > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > Could not submit job > > > > Caused by: > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > Could not start coaster service > > > > Caused by: > > > > > > > > > > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException: > > > > Task ended before registration was received. > > > > > > > > Picked up JAVA_TOOL_OPTIONS: -Xmx256m > > > > /bin/bash: line 54: 33675 > > > > Aborted /usr/java/latest/bin/java > > > > -Djava=/usr/java/latest/bin/java > > > -DGLOBUS_TCP_PORT_RANGE=50000,51000 > > > > > > > > > > -DX509_USER_PROXY=/home/ketan/.globus/sshproxy-316831905-1379663604 > > > > > > > > > > -DX509_CERT_DIR=/home/ketan/.globus/sshCAcert-316831905-1379663604.pem > > > > -DGLOBUS_HOSTNAME=gordon.sdsc.xsede.org > > > -Duser.home=/home/ketan > > > > -jar /tmp/bootstrap.RWIqFu > > > http://swift.rcc.uchicago.edu:50001 > > > > https://128.135.112.73:50000 11836079986 > > > > > > > > > > > > > > > > > > > > Do I understand right that this is indeed the java > > heap > > > space issue? > > > > or is it something else that I could work around > > with? > > > Thanks for any > > > > ideas. > > > > > > > > > > > > -- > > > > Ketan > > > > > > > > > > > > > > > _______________________________________________ > > > > Swift-devel mailing list > > > > Swift-devel at ci.uchicago.edu > > > > > > > > > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > > > > > > > > > > > > > > -- > > > Ketan > > > > > > > > > > > > > > > > > > > > -- > > Ketan > > > > > > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > -- Yadu Nand B -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.g.armstrong at gmail.com Tue Jan 27 21:42:39 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Tue, 27 Jan 2015 21:42:39 -0600 Subject: [Swift-devel] Reconsidering function overloading Message-ID: Hi All, I was just starting to look at implementing the function overloading support required by the current design of the standard library. I've just realised some of the complications and wanted to reassess the current design. .As soon as I looked at the changes needed, it was obvious that it interacts with function references in ways that are probably undesirable. The issue is that a function name maps to more than one function, and the compiler needs to be able to disambiguate wherever it is used: in a variable context as well as a function call context. For example, suppose we wanted to provide a reduce function with type reduce(T, T[], (T) f (T, T)). It seems reasonable that we'd want to be able to write: reduce(0, [1, 10, 3, 4], max) But if max is overloaded, then we have to be able to infer from the type of the first and second arguments which max was meant. As an aside, there's a further level of difficulty in resolving things correctly if you consider that overloaded functions can take overloaded functions as arguments There seems to be a number of ways to get around this problem: 1. Don't support overloading at all, save complications at the expense of longer function names 2. Don't plan on supporting function references at all 3. Ban using overloaded functions as first-class functions, force users to work around it. 4. Attempt to do some basic type inference to disambiguate, give up if we can't disambiguate from local information. (C++ approach, essentially) 5. Full program-wide type inference (Haskell approach) #2 doesn't fit with overall plans for the project, I don't think. #3 seems pretty unsatisfying and I think we're best to avoid bad programmer experiences when we have a cleanish slate to work from. #5 doesn't seem feasible without major changes to language and compiler. This leaves #1 and #4. I think I could make #4 work in Swift/T, but it would be days of work and getting all the corner cases may be a challenge - realistically I might just not get it done. I have no idea how feasible #4 is in Swift/K. #1 seems like the best effort to reward ratio to me. Anyway, that was a bunch of detail - does anyone have any thoughts or opinions? Have I missed anything? I'm already assuming that we just shouldn't support overloading functions with any other kind of polymorphic arguments - it's not really necessary and too complicated to implement - Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilde at anl.gov Wed Jan 28 07:07:49 2015 From: wilde at anl.gov (Michael Wilde) Date: Wed, 28 Jan 2015 07:07:49 -0600 Subject: [Swift-devel] Reconsidering function overloading In-Reply-To: References: Message-ID: <54C8DF25.9030301@anl.gov> I think #1 is reasonable. I don't think #3 is in practice that bad, though. Another variation on #3 is: 6. Ban using function references as arguments/returns in overloaded functions (for now). Note that Apple's Swift makes heavy use of type inference. It might be useful to see how it handles this issue. An advantage to #1 is that we could add support for overloading at a later time. A point in favor of #3 or #6 is that we've lived without either feature till now; a few restrictions on the pair of new features will not be very limiting. I don't think it will lead to many "bad programmer experiences", although I agree that its a wart from a language design perspective. - Mike On 1/27/15 9:42 PM, Tim Armstrong wrote: > Hi All, > I was just starting to look at implementing the function overloading > support required by the current design of the standard library. I've > just realised some of the complications and wanted to reassess the > current design. > > .As soon as I looked at the changes needed, it was obvious that it > interacts with function references in ways that are probably > undesirable. The issue is that a function name maps to more than one > function, and the compiler needs to be able to disambiguate wherever > it is used: in a variable context as well as a function call context. > > For example, suppose we wanted to provide a reduce function with type > reduce(T, T[], (T) f (T, T)). It seems reasonable that we'd want to > be able to write: > > reduce(0, [1, 10, 3, 4], max) > > But if max is overloaded, then we have to be able to infer from the > type of the first and second arguments which max was meant. > > As an aside, there's a further level of difficulty in resolving things > correctly if you consider that overloaded functions can take > overloaded functions as arguments > > There seems to be a number of ways to get around this problem: > 1. Don't support overloading at all, save complications at the expense > of longer function names > 2. Don't plan on supporting function references at all > 3. Ban using overloaded functions as first-class functions, force > users to work around it. > 4. Attempt to do some basic type inference to disambiguate, give up if > we can't disambiguate from local information. (C++ approach, essentially) > 5. Full program-wide type inference (Haskell approach) > > #2 doesn't fit with overall plans for the project, I don't think. #3 > seems pretty unsatisfying and I think we're best to avoid bad > programmer experiences when we have a cleanish slate to work from. > #5 doesn't seem feasible without major changes to language and compiler. > This leaves #1 and #4. I think I could make #4 work in Swift/T, but > it would be days of work and getting all the corner cases may be a > challenge - realistically I might just not get it done. I have no > idea how feasible #4 is in Swift/K. #1 seems like the best effort to > reward ratio to me. > > Anyway, that was a bunch of detail - does anyone have any thoughts or > opinions? Have I missed anything? > > I'm already assuming that we just shouldn't support overloading > functions with any other kind of polymorphic arguments - it's not > really necessary and too complicated to implement > > - Tim > > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilde at anl.gov Wed Jan 28 07:17:48 2015 From: wilde at anl.gov (Michael Wilde) Date: Wed, 28 Jan 2015 07:17:48 -0600 Subject: [Swift-devel] Reconsidering function overloading In-Reply-To: <54C8DF25.9030301@anl.gov> References: <54C8DF25.9030301@anl.gov> Message-ID: <54C8E17C.6070407@anl.gov> One more possibility occurs: could we allow overloaded functions to pass/return function reference args if we required that when a function reference arg is overloaded, it must be passed with a disambiguating type signature? I.e. if we have: max( float[ ] ) max( int[ ] ) sum( int[ ] ) reduce(T, T[ ], (T) f ( int[ ] ) ) Then we have to say: reduce(0, [1, 10, 3, 4], max( int[ ] ) ) but we could also say: reduce(0, [1, 10, 3, 4], sum ) And if we wanted uniformity over convenience we could insist that function references must always be passed with type signatures even when unambiguous. Does that approach work consistently and reasonably? - Mike On 1/28/15 7:07 AM, Michael Wilde wrote: > > I think #1 is reasonable. > > I don't think #3 is in practice that bad, though. > > Another variation on #3 is: > > 6. Ban using function references as arguments/returns in overloaded > functions (for now). > > Note that Apple's Swift makes heavy use of type inference. It might be > useful to see how it handles this issue. > > An advantage to #1 is that we could add support for overloading at a > later time. > > A point in favor of #3 or #6 is that we've lived without either > feature till now; a few restrictions on the pair of new features will > not be very limiting. I don't think it will lead to many "bad > programmer experiences", although I agree that its a wart from a > language design perspective. > > - Mike > > On 1/27/15 9:42 PM, Tim Armstrong wrote: >> Hi All, >> I was just starting to look at implementing the function >> overloading support required by the current design of the standard >> library. I've just realised some of the complications and wanted to >> reassess the current design. >> >> .As soon as I looked at the changes needed, it was obvious that it >> interacts with function references in ways that are probably >> undesirable. The issue is that a function name maps to more than one >> function, and the compiler needs to be able to disambiguate wherever >> it is used: in a variable context as well as a function call context. >> >> For example, suppose we wanted to provide a reduce function with type >> reduce(T, T[], (T) f (T, T)). It seems reasonable that we'd want to >> be able to write: >> >> reduce(0, [1, 10, 3, 4], max) >> >> But if max is overloaded, then we have to be able to infer from the >> type of the first and second arguments which max was meant. >> >> As an aside, there's a further level of difficulty in resolving >> things correctly if you consider that overloaded functions can take >> overloaded functions as arguments >> >> There seems to be a number of ways to get around this problem: >> 1. Don't support overloading at all, save complications at the >> expense of longer function names >> 2. Don't plan on supporting function references at all >> 3. Ban using overloaded functions as first-class functions, force >> users to work around it. >> 4. Attempt to do some basic type inference to disambiguate, give up >> if we can't disambiguate from local information. (C++ approach, >> essentially) >> 5. Full program-wide type inference (Haskell approach) >> >> #2 doesn't fit with overall plans for the project, I don't think. #3 >> seems pretty unsatisfying and I think we're best to avoid bad >> programmer experiences when we have a cleanish slate to work from. >> #5 doesn't seem feasible without major changes to language and compiler. >> This leaves #1 and #4. I think I could make #4 work in Swift/T, but >> it would be days of work and getting all the corner cases may be a >> challenge - realistically I might just not get it done. I have no >> idea how feasible #4 is in Swift/K. #1 seems like the best effort to >> reward ratio to me. >> >> Anyway, that was a bunch of detail - does anyone have any thoughts or >> opinions? Have I missed anything? >> >> I'm already assuming that we just shouldn't support overloading >> functions with any other kind of polymorphic arguments - it's not >> really necessary and too complicated to implement >> >> - Tim >> >> >> _______________________________________________ >> Swift-devel mailing list >> Swift-devel at ci.uchicago.edu >> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > -- > Michael Wilde > Mathematics and Computer Science Computation Institute > Argonne National Laboratory The University of Chicago > > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.g.armstrong at gmail.com Wed Jan 28 09:01:35 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Wed, 28 Jan 2015 09:01:35 -0600 Subject: [Swift-devel] Reconsidering function overloading In-Reply-To: <54C8E17C.6070407@anl.gov> References: <54C8DF25.9030301@anl.gov> <54C8E17C.6070407@anl.gov> Message-ID: Mike - that's technically possible to implement but I don't see the cost/benefit stacking up that well - I think any new syntactic constructs come with a non-neglible implementation/documentation/user attention cost that can quickly accumulate if we're not selective about what we put into the language (see C++). Tangentially, that particular syntax is difficult to parse unambiguously - you could be trying to index a variable called int and pass it into max. The problem I see with #3 is that we're allowing overloaded functions so that the standard library seems slightly neater/more friendly. If that results in a bunch of exceptions where users can't do something that "ought to" work - composing two standard library functions reduce/max, I just don't see enough of a net benefit (if any) to the programmer experience to justify the implementation burden. This of course is somewhat subjective - I tend to like languages where there is a simple and consistent but powerful set of core rules that are orthogonal and compose well together - you can learn the basic rules and don't have to worry about many exceptions. Other language designs will special-case common constructs so that use-cases that the language designer expects to be common will be shorter or "cuter", or add features that don't compose well with other features and come with caveats/exceptions. I think C, Haskell and Python are examples of the former, and Perl, R and C++ are examples of the latter. I'm not sure which camp we see ourselves in. I haven't found complete documentation on Apple Swift's type inference, but it doesn't seem like it does anything very sophisticated - Swift/T already does similar local type inference. - Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilde at anl.gov Wed Jan 28 09:14:59 2015 From: wilde at anl.gov (Michael Wilde) Date: Wed, 28 Jan 2015 09:14:59 -0600 Subject: [Swift-devel] Reconsidering function overloading In-Reply-To: References: <54C8DF25.9030301@anl.gov> <54C8E17C.6070407@anl.gov> Message-ID: <54C8FCF3.6060202@anl.gov> Based on your point here and earlier, Tim, I agree with going with option #1. So count this as a +1 for that. Function references give us something we can not otherwise do, while overloaded functions is just a convenience (which not everyone will like). How does this apply to intrinsic functions in the library, though, eg, strcat( ) which you could view as an overloaded function? Can we address this more cleanly by introducing a type "var"? (I can't recall where we left prior discussion on that issue). Also, are we dipping into the tangentially related issue of var-args (varying number of args) here? - Mike ps. I prefer the approach of "simple and consistent but powerful set of core rules that are orthogonal and compose well together" in the C, Haskell, Python vein. On 1/28/15 9:01 AM, Tim Armstrong wrote: > Mike - that's technically possible to implement but I don't see the > cost/benefit stacking up that well - I think any new syntactic > constructs come with a non-neglible implementation/documentation/user > attention cost that can quickly accumulate if we're not selective > about what we put into the language (see C++). Tangentially, that > particular syntax is difficult to parse unambiguously - you could be > trying to index a variable called int and pass it into max. > > The problem I see with #3 is that we're allowing overloaded functions > so that the standard library seems slightly neater/more friendly. If > that results in a bunch of exceptions where users can't do something > that "ought to" work - composing two standard library functions > reduce/max, I just don't see enough of a net benefit (if any) to the > programmer experience to justify the implementation burden. > > This of course is somewhat subjective - I tend to like languages where > there is a simple and consistent but powerful set of core rules that > are orthogonal and compose well together - you can learn the basic > rules and don't have to worry about many exceptions. Other language > designs will special-case common constructs so that use-cases that the > language designer expects to be common will be shorter or "cuter", or > add features that don't compose well with other features and come with > caveats/exceptions. I think C, Haskell and Python are examples of the > former, and Perl, R and C++ are examples of the latter. I'm not sure > which camp we see ourselves in. > > I haven't found complete documentation on Apple Swift's type > inference, but it doesn't seem like it does anything very > sophisticated - Swift/T already does similar local type inference. > > - Tim -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.g.armstrong at gmail.com Wed Jan 28 11:15:17 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Wed, 28 Jan 2015 11:15:17 -0600 Subject: [Swift-devel] Reconsidering function overloading In-Reply-To: <54C8FCF3.6060202@anl.gov> References: <54C8DF25.9030301@anl.gov> <54C8E17C.6070407@anl.gov> <54C8FCF3.6060202@anl.gov> Message-ID: I agree the overloaded functions provide some nice functionality - I find it frustrating in C that there's no built-in min/max, for example. I don't like minInt/minFloat/etc, but they may be the lesser evil. I'm not sure how strcat is implemented in Swift/K. In Swift/T there is a single function prototype, but the arguments are option types - string|int|float. This avoids the issue of working out which version of strcat was meant, since there is only one version that accepts multiple argument types - the compiler doesn't need to inspect the argument types to work out which strcat you meant. There are two things I think you might mean by a var type. The first is static typing where you can omit the variable type and have the compiler infer it based on the right hand side of the assignment. Swift/T actually already supports this in some cases. The other option is dynamic typing where the type of the variable may vary at runtime. The problem here is that you generally then need runtime introspection to work out the type of the variable so you know what to do with it. It also prevents some typechecking. Varargs is also in the mix - we do support it already. I think it could work ok with overloading from the point of view of user experience, but I'd probably avoid supporting overloading of varargs functions since the use cases seem limited and the implementation would be some work. I'm still thinking through overloading and if there's a better way to implement it than the way I was originally thinking of. I'm looking at the typechecking code and it might be a little easier than I thought if I approach it in the right way. - Tim On Wed, Jan 28, 2015 at 9:14 AM, Michael Wilde wrote: > Based on your point here and earlier, Tim, I agree with going with option > #1. So count this as a +1 for that. > > Function references give us something we can not otherwise do, while > overloaded functions is just a convenience (which not everyone will like). > > How does this apply to intrinsic functions in the library, though, eg, > strcat( ) which you could view as an overloaded function? > > Can we address this more cleanly by introducing a type "var"? (I can't > recall where we left prior discussion on that issue). Also, are we dipping > into the tangentially related issue of var-args (varying number of args) > here? > > - Mike > > ps. I prefer the approach of "simple and consistent but powerful set of > core rules that are orthogonal and compose well together" in the C, > Haskell, Python vein. > > > > On 1/28/15 9:01 AM, Tim Armstrong wrote: > > Mike - that's technically possible to implement but I don't see the > cost/benefit stacking up that well - I think any new syntactic constructs > come with a non-neglible implementation/documentation/user attention cost > that can quickly accumulate if we're not selective about what we put into > the language (see C++). Tangentially, that particular syntax is difficult > to parse unambiguously - you could be trying to index a variable called int > and pass it into max. > > The problem I see with #3 is that we're allowing overloaded functions so > that the standard library seems slightly neater/more friendly. If that > results in a bunch of exceptions where users can't do something that "ought > to" work - composing two standard library functions reduce/max, I just > don't see enough of a net benefit (if any) to the programmer experience to > justify the implementation burden. > > This of course is somewhat subjective - I tend to like languages where > there is a simple and consistent but powerful set of core rules that are > orthogonal and compose well together - you can learn the basic rules and > don't have to worry about many exceptions. Other language designs will > special-case common constructs so that use-cases that the language designer > expects to be common will be shorter or "cuter", or add features that don't > compose well with other features and come with caveats/exceptions. I think > C, Haskell and Python are examples of the former, and Perl, R and C++ are > examples of the latter. I'm not sure which camp we see ourselves in. > > I haven't found complete documentation on Apple Swift's type inference, > but it doesn't seem like it does anything very sophisticated - Swift/T > already does similar local type inference. > > - Tim > > > -- > Michael Wilde > Mathematics and Computer Science Computation Institute > Argonne National Laboratory The University of Chicago > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Wed Jan 28 14:23:48 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 28 Jan 2015 12:23:48 -0800 Subject: [Swift-devel] Reconsidering function overloading In-Reply-To: References: Message-ID: <1422476628.7854.5.camel@echo> Here's another idea. If we do support lambda expressions, then: - a direct reference to an overloaded function when no parameter type is available should result in an ambiguity error - a user can resolve the issue by writing an explicit lambda expression which calls the overloaded function, but this time with normal parameter type information available E.g: min = reduce(a, min); // error min = reduce(a, lambda(float x) { return min(x); }); This requires no specialized casting mechanism. Of course, if lambda expressions weren't in the plans, this might be more work. Mihael On Tue, 2015-01-27 at 21:42 -0600, Tim Armstrong wrote: > Hi All, > I was just starting to look at implementing the function overloading > support required by the current design of the standard library. I've just > realised some of the complications and wanted to reassess the current > design. > > .As soon as I looked at the changes needed, it was obvious that it > interacts with function references in ways that are probably undesirable. > The issue is that a function name maps to more than one function, and the > compiler needs to be able to disambiguate wherever it is used: in a > variable context as well as a function call context. > > For example, suppose we wanted to provide a reduce function with type > reduce(T, T[], (T) f (T, T)). It seems reasonable that we'd want to be > able to write: > > reduce(0, [1, 10, 3, 4], max) > > But if max is overloaded, then we have to be able to infer from the type of > the first and second arguments which max was meant. > > As an aside, there's a further level of difficulty in resolving things > correctly if you consider that overloaded functions can take overloaded > functions as arguments > > There seems to be a number of ways to get around this problem: > 1. Don't support overloading at all, save complications at the expense of > longer function names > 2. Don't plan on supporting function references at all > 3. Ban using overloaded functions as first-class functions, force users to > work around it. > 4. Attempt to do some basic type inference to disambiguate, give up if we > can't disambiguate from local information. (C++ approach, essentially) > 5. Full program-wide type inference (Haskell approach) > > #2 doesn't fit with overall plans for the project, I don't think. #3 seems > pretty unsatisfying and I think we're best to avoid bad programmer > experiences when we have a cleanish slate to work from. #5 doesn't seem > feasible without major changes to language and compiler. > This leaves #1 and #4. I think I could make #4 work in Swift/T, but it > would be days of work and getting all the corner cases may be a challenge - > realistically I might just not get it done. I have no idea how feasible #4 > is in Swift/K. #1 seems like the best effort to reward ratio to me. > > Anyway, that was a bunch of detail - does anyone have any thoughts or > opinions? Have I missed anything? > > I'm already assuming that we just shouldn't support overloading functions > with any other kind of polymorphic arguments - it's not really necessary > and too complicated to implement > > - Tim > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel From hategan at mcs.anl.gov Wed Jan 28 14:39:50 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 28 Jan 2015 12:39:50 -0800 Subject: [Swift-devel] Reconsidering function overloading In-Reply-To: <1422476628.7854.5.camel@echo> References: <1422476628.7854.5.camel@echo> Message-ID: <1422477590.8203.5.camel@echo> Which ultimately isn't much different from having to do: (float x) minFloat(float[] a) { x = min(a); } reduce(a, minFloat); So maybe that isn't much progress. Mihael On Wed, 2015-01-28 at 12:23 -0800, Mihael Hategan wrote: > Here's another idea. If we do support lambda expressions, then: > > - a direct reference to an overloaded function when no parameter type is > available should result in an ambiguity error > - a user can resolve the issue by writing an explicit lambda expression > which calls the overloaded function, but this time with normal parameter > type information available > > E.g: > > min = reduce(a, min); // error > min = reduce(a, lambda(float x) { return min(x); }); > > This requires no specialized casting mechanism. Of course, if lambda > expressions weren't in the plans, this might be more work. > > Mihael > > On Tue, 2015-01-27 at 21:42 -0600, Tim Armstrong wrote: > > Hi All, > > I was just starting to look at implementing the function overloading > > support required by the current design of the standard library. I've just > > realised some of the complications and wanted to reassess the current > > design. > > > > .As soon as I looked at the changes needed, it was obvious that it > > interacts with function references in ways that are probably undesirable. > > The issue is that a function name maps to more than one function, and the > > compiler needs to be able to disambiguate wherever it is used: in a > > variable context as well as a function call context. > > > > For example, suppose we wanted to provide a reduce function with type > > reduce(T, T[], (T) f (T, T)). It seems reasonable that we'd want to be > > able to write: > > > > reduce(0, [1, 10, 3, 4], max) > > > > But if max is overloaded, then we have to be able to infer from the type of > > the first and second arguments which max was meant. > > > > As an aside, there's a further level of difficulty in resolving things > > correctly if you consider that overloaded functions can take overloaded > > functions as arguments > > > > There seems to be a number of ways to get around this problem: > > 1. Don't support overloading at all, save complications at the expense of > > longer function names > > 2. Don't plan on supporting function references at all > > 3. Ban using overloaded functions as first-class functions, force users to > > work around it. > > 4. Attempt to do some basic type inference to disambiguate, give up if we > > can't disambiguate from local information. (C++ approach, essentially) > > 5. Full program-wide type inference (Haskell approach) > > > > #2 doesn't fit with overall plans for the project, I don't think. #3 seems > > pretty unsatisfying and I think we're best to avoid bad programmer > > experiences when we have a cleanish slate to work from. #5 doesn't seem > > feasible without major changes to language and compiler. > > This leaves #1 and #4. I think I could make #4 work in Swift/T, but it > > would be days of work and getting all the corner cases may be a challenge - > > realistically I might just not get it done. I have no idea how feasible #4 > > is in Swift/K. #1 seems like the best effort to reward ratio to me. > > > > Anyway, that was a bunch of detail - does anyone have any thoughts or > > opinions? Have I missed anything? > > > > I'm already assuming that we just shouldn't support overloading functions > > with any other kind of polymorphic arguments - it's not really necessary > > and too complicated to implement > > > > - Tim > > _______________________________________________ > > Swift-devel mailing list > > Swift-devel at ci.uchicago.edu > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel From tim.g.armstrong at gmail.com Wed Jan 28 16:24:12 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Wed, 28 Jan 2015 16:24:12 -0600 Subject: [Swift-devel] Reconsidering function overloading In-Reply-To: <1422477590.8203.5.camel@echo> References: <1422476628.7854.5.camel@echo> <1422477590.8203.5.camel@echo> Message-ID: I think lambdas are a nice orthogonal way to solve it here, but yeah, I don't think they're in the plans in the immediate future. - Tim On Wed, Jan 28, 2015 at 2:39 PM, Mihael Hategan wrote: > Which ultimately isn't much different from having to do: > > (float x) minFloat(float[] a) { > x = min(a); > } > > reduce(a, minFloat); > > So maybe that isn't much progress. > > Mihael > > On Wed, 2015-01-28 at 12:23 -0800, Mihael Hategan wrote: > > Here's another idea. If we do support lambda expressions, then: > > > > - a direct reference to an overloaded function when no parameter type is > > available should result in an ambiguity error > > - a user can resolve the issue by writing an explicit lambda expression > > which calls the overloaded function, but this time with normal parameter > > type information available > > > > E.g: > > > > min = reduce(a, min); // error > > min = reduce(a, lambda(float x) { return min(x); }); > > > > This requires no specialized casting mechanism. Of course, if lambda > > expressions weren't in the plans, this might be more work. > > > > Mihael > > > > On Tue, 2015-01-27 at 21:42 -0600, Tim Armstrong wrote: > > > Hi All, > > > I was just starting to look at implementing the function overloading > > > support required by the current design of the standard library. I've > just > > > realised some of the complications and wanted to reassess the current > > > design. > > > > > > .As soon as I looked at the changes needed, it was obvious that it > > > interacts with function references in ways that are probably > undesirable. > > > The issue is that a function name maps to more than one function, and > the > > > compiler needs to be able to disambiguate wherever it is used: in a > > > variable context as well as a function call context. > > > > > > For example, suppose we wanted to provide a reduce function with type > > > reduce(T, T[], (T) f (T, T)). It seems reasonable that we'd want to be > > > able to write: > > > > > > reduce(0, [1, 10, 3, 4], max) > > > > > > But if max is overloaded, then we have to be able to infer from the > type of > > > the first and second arguments which max was meant. > > > > > > As an aside, there's a further level of difficulty in resolving things > > > correctly if you consider that overloaded functions can take overloaded > > > functions as arguments > > > > > > There seems to be a number of ways to get around this problem: > > > 1. Don't support overloading at all, save complications at the expense > of > > > longer function names > > > 2. Don't plan on supporting function references at all > > > 3. Ban using overloaded functions as first-class functions, force > users to > > > work around it. > > > 4. Attempt to do some basic type inference to disambiguate, give up if > we > > > can't disambiguate from local information. (C++ approach, essentially) > > > 5. Full program-wide type inference (Haskell approach) > > > > > > #2 doesn't fit with overall plans for the project, I don't think. #3 > seems > > > pretty unsatisfying and I think we're best to avoid bad programmer > > > experiences when we have a cleanish slate to work from. #5 doesn't > seem > > > feasible without major changes to language and compiler. > > > This leaves #1 and #4. I think I could make #4 work in Swift/T, but it > > > would be days of work and getting all the corner cases may be a > challenge - > > > realistically I might just not get it done. I have no idea how > feasible #4 > > > is in Swift/K. #1 seems like the best effort to reward ratio to me. > > > > > > Anyway, that was a bunch of detail - does anyone have any thoughts or > > > opinions? Have I missed anything? > > > > > > I'm already assuming that we just shouldn't support overloading > functions > > > with any other kind of polymorphic arguments - it's not really > necessary > > > and too complicated to implement > > > > > > - Tim > > > _______________________________________________ > > > Swift-devel mailing list > > > Swift-devel at ci.uchicago.edu > > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > > _______________________________________________ > > 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: From hategan at mcs.anl.gov Wed Jan 28 18:04:26 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 28 Jan 2015 16:04:26 -0800 Subject: [Swift-devel] Reconsidering function overloading In-Reply-To: References: <1422476628.7854.5.camel@echo> <1422477590.8203.5.camel@echo> Message-ID: <1422489866.10485.15.camel@echo> I personally didn't think that we would implement them (fn pointers and lambdas) separately. That was based on them being morally connected, but they are quite different in terms of implementation. My problem with my solution is that, while min(x, y) will remain nice, any use of min as a function pointer will actually require what is equivalent to having minFloat/minInt. whether by lambdas or by actually writing a minFloat/minInt. I think this has to be the cost. As before with overloading/keyword args, the language gains both abilities in general, with none of the corner case affecting anything that could have been done before cleanly. We could maybe improve things later by adding a terse casting operator. I don't think type inference (#5) will be simple if we support universally quantified types. f(T[] a, (T[] -> T) g) { g(a); } f(a, min) You would basically end up with a constraint system similar to SML's. It's doable, but there are lots of moving parts. So I think ultimately #3 might be the reasonable choice. I would also add #6, which would be to do dynamic dispatch in cases where full static resolution fails. It probably comes with a can of worms if its own. Mihael On Wed, 2015-01-28 at 16:24 -0600, Tim Armstrong wrote: > I think lambdas are a nice orthogonal way to solve it here, but yeah, I > don't think they're in the plans in the immediate future. > > - Tim > > On Wed, Jan 28, 2015 at 2:39 PM, Mihael Hategan wrote: > > > Which ultimately isn't much different from having to do: > > > > (float x) minFloat(float[] a) { > > x = min(a); > > } > > > > reduce(a, minFloat); > > > > So maybe that isn't much progress. > > > > Mihael > > > > On Wed, 2015-01-28 at 12:23 -0800, Mihael Hategan wrote: > > > Here's another idea. If we do support lambda expressions, then: > > > > > > - a direct reference to an overloaded function when no parameter type is > > > available should result in an ambiguity error > > > - a user can resolve the issue by writing an explicit lambda expression > > > which calls the overloaded function, but this time with normal parameter > > > type information available > > > > > > E.g: > > > > > > min = reduce(a, min); // error > > > min = reduce(a, lambda(float x) { return min(x); }); > > > > > > This requires no specialized casting mechanism. Of course, if lambda > > > expressions weren't in the plans, this might be more work. > > > > > > Mihael > > > > > > On Tue, 2015-01-27 at 21:42 -0600, Tim Armstrong wrote: > > > > Hi All, > > > > I was just starting to look at implementing the function overloading > > > > support required by the current design of the standard library. I've > > just > > > > realised some of the complications and wanted to reassess the current > > > > design. > > > > > > > > .As soon as I looked at the changes needed, it was obvious that it > > > > interacts with function references in ways that are probably > > undesirable. > > > > The issue is that a function name maps to more than one function, and > > the > > > > compiler needs to be able to disambiguate wherever it is used: in a > > > > variable context as well as a function call context. > > > > > > > > For example, suppose we wanted to provide a reduce function with type > > > > reduce(T, T[], (T) f (T, T)). It seems reasonable that we'd want to be > > > > able to write: > > > > > > > > reduce(0, [1, 10, 3, 4], max) > > > > > > > > But if max is overloaded, then we have to be able to infer from the > > type of > > > > the first and second arguments which max was meant. > > > > > > > > As an aside, there's a further level of difficulty in resolving things > > > > correctly if you consider that overloaded functions can take overloaded > > > > functions as arguments > > > > > > > > There seems to be a number of ways to get around this problem: > > > > 1. Don't support overloading at all, save complications at the expense > > of > > > > longer function names > > > > 2. Don't plan on supporting function references at all > > > > 3. Ban using overloaded functions as first-class functions, force > > users to > > > > work around it. > > > > 4. Attempt to do some basic type inference to disambiguate, give up if > > we > > > > can't disambiguate from local information. (C++ approach, essentially) > > > > 5. Full program-wide type inference (Haskell approach) > > > > > > > > #2 doesn't fit with overall plans for the project, I don't think. #3 > > seems > > > > pretty unsatisfying and I think we're best to avoid bad programmer > > > > experiences when we have a cleanish slate to work from. #5 doesn't > > seem > > > > feasible without major changes to language and compiler. > > > > This leaves #1 and #4. I think I could make #4 work in Swift/T, but it > > > > would be days of work and getting all the corner cases may be a > > challenge - > > > > realistically I might just not get it done. I have no idea how > > feasible #4 > > > > is in Swift/K. #1 seems like the best effort to reward ratio to me. > > > > > > > > Anyway, that was a bunch of detail - does anyone have any thoughts or > > > > opinions? Have I missed anything? > > > > > > > > I'm already assuming that we just shouldn't support overloading > > functions > > > > with any other kind of polymorphic arguments - it's not really > > necessary > > > > and too complicated to implement > > > > > > > > - Tim > > > > _______________________________________________ > > > > Swift-devel mailing list > > > > Swift-devel at ci.uchicago.edu > > > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > > > > > _______________________________________________ > > > Swift-devel mailing list > > > Swift-devel at ci.uchicago.edu > > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > > From wozniak at mcs.anl.gov Thu Jan 29 11:17:46 2015 From: wozniak at mcs.anl.gov (Justin M Wozniak) Date: Thu, 29 Jan 2015 11:17:46 -0600 Subject: [Swift-devel] Swift function from command line In-Reply-To: <1422042939.11845.3.camel@echo> References: <1422042939.11845.3.camel@echo> Message-ID: <54CA6B3A.2000102@mcs.anl.gov> I just added -i and -E to swift-t: > swift-t -i io -i sys -E 'printf("args: %i", argc());' a b c args: 3 (-e is taken for environment variable.) On 1/23/2015 1:55 PM, Mihael Hategan wrote: > swift -e > > Mihael > > On Fri, 2015-01-23 at 13:36 -0600, Ketan Maheshwari wrote: >> Hello, >> >> This came up in a meeting today. I was wondering if it is possible to run >> an arbitrary swift function from Swift command line? Something along the >> lines of: >> >> swift -cli pow(3,2) >> >> I think this feature has been discussed in the past but am not sure if it >> is available currently or is a planned feature. >> >> Thanks, >> Ketan >> _______________________________________________ >> Swift-devel mailing list >> Swift-devel at ci.uchicago.edu >> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel -- Justin M Wozniak From tim.g.armstrong at gmail.com Thu Jan 29 12:29:48 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Thu, 29 Jan 2015 12:29:48 -0600 Subject: [Swift-devel] Reconsidering function overloading In-Reply-To: <1422489866.10485.15.camel@echo> References: <1422476628.7854.5.camel@echo> <1422477590.8203.5.camel@echo> <1422489866.10485.15.camel@echo> Message-ID: I thought about dynamic dispatch too. I don't think it's any more powerful than static dispatch unless you want to dispatch based on subtype, e.g. if you have type T2 that's derived from T1 and you have overloaded f(T1) and f(T2). You can implement static dispatch at runtime by emitting the type information from the compiler and having a series of conditionals that look at the type information I avoided implementing Swift functions with type variable arguments for that reason. I agree you end up needing something like SML's constraints or Haskells typeclasses to write useful code. Well.. unless you do it the C++ templates way and just try substituting the types and see what happens. The type inference might not be too bad... the way STC handles it is in a two phase way where full type information propagates up the tree, and then evaluation propagates down. When propagating up, we can have non-concrete types like option types and wildcard types. When evaluating, we need to narrow those to a concrete type based on context (or picking the first valid option if multiple are valid). Concretely, what happens currently when typechecking a function in STC: 1. Work out the type of the input argument expression. This is an option type T1|T2|T3|etc. Each of the options can include wildcard types. E.g. the type of [1] is (int[] | float[]) and the type of [] is (*[]). 2. Find the function type, and the type of the input argument at that position 3. Match up the argument expression type with the argument type, and record any type variables bound during matching. (NOTE: some things not supported, like combining option types and type variables because that causes problems at this step) 4. Once we've done that for all input arguments, try to unify them if there were multiple bindings for a type variable (NOTE: only do this for option types, but could do for subtypes too) 5. If there was no way to unify type variable bindings, typechecking fails 6. Enumerate all possible function types that could arise from selecting a type variable binding compatible with the input types. 7. The output argument types of these possible function types give the types for the function expression, e.g. (T0, T1) | (T2, T3) | (T4, T5) 8. When it comes time to evaluate the function call, one of these alternatives is selected based on context (e.g. it the possible types are float | int and the function is in an expression context where we need a float). 9. Any type variables constrained by output argument types are bound if needed. Any unconstrained type variables are bound to void I think having input argument expressions with type variables doesn't greatly affect the process so long as you're not trying to do function-level type inference (e.g. inferring constraints on function arguments based on how they're used in the function) - it's just another case to consider in step 3. Also it would need to carefully disambiguate type variables with the same name from the function you're in versus the function you're calling. I think overloading, if an overloaded function is an argument, can be handled at steps 1. and 8. by representing the overload as an option type, then selecting the implementation based on which option is chosen. Calling an overloaded function would probably just require trial-and-error of going through each overload, then selecting the one that fits. So I guess, start with #3, but #4 might be a reasonable extension. - Tim On Wed, Jan 28, 2015 at 6:04 PM, Mihael Hategan wrote: > I personally didn't think that we would implement them (fn pointers and > lambdas) separately. That was based on them being morally connected, but > they are quite different in terms of implementation. > > My problem with my solution is that, while min(x, y) will remain nice, > any use of min as a function pointer will actually require what is > equivalent to having minFloat/minInt. whether by lambdas or by actually > writing a minFloat/minInt. > > I think this has to be the cost. As before with overloading/keyword > args, the language gains both abilities in general, with none of the > corner case affecting anything that could have been done before cleanly. > We could maybe improve things later by adding a terse casting operator. > > I don't think type inference (#5) will be simple if we support > universally quantified types. > > f(T[] a, (T[] -> T) g) { > g(a); > } > > f(a, min) > > You would basically end up with a constraint system similar to SML's. > It's doable, but there are lots of moving parts. > > So I think ultimately #3 might be the reasonable choice. > > I would also add #6, which would be to do dynamic dispatch in cases > where full static resolution fails. It probably comes with a can of > worms if its own. > > Mihael > > > On Wed, 2015-01-28 at 16:24 -0600, Tim Armstrong wrote: > > I think lambdas are a nice orthogonal way to solve it here, but yeah, I > > don't think they're in the plans in the immediate future. > > > > - Tim > > > > On Wed, Jan 28, 2015 at 2:39 PM, Mihael Hategan > wrote: > > > > > Which ultimately isn't much different from having to do: > > > > > > (float x) minFloat(float[] a) { > > > x = min(a); > > > } > > > > > > reduce(a, minFloat); > > > > > > So maybe that isn't much progress. > > > > > > Mihael > > > > > > On Wed, 2015-01-28 at 12:23 -0800, Mihael Hategan wrote: > > > > Here's another idea. If we do support lambda expressions, then: > > > > > > > > - a direct reference to an overloaded function when no parameter > type is > > > > available should result in an ambiguity error > > > > - a user can resolve the issue by writing an explicit lambda > expression > > > > which calls the overloaded function, but this time with normal > parameter > > > > type information available > > > > > > > > E.g: > > > > > > > > min = reduce(a, min); // error > > > > min = reduce(a, lambda(float x) { return min(x); }); > > > > > > > > This requires no specialized casting mechanism. Of course, if lambda > > > > expressions weren't in the plans, this might be more work. > > > > > > > > Mihael > > > > > > > > On Tue, 2015-01-27 at 21:42 -0600, Tim Armstrong wrote: > > > > > Hi All, > > > > > I was just starting to look at implementing the function > overloading > > > > > support required by the current design of the standard library. > I've > > > just > > > > > realised some of the complications and wanted to reassess the > current > > > > > design. > > > > > > > > > > .As soon as I looked at the changes needed, it was obvious that it > > > > > interacts with function references in ways that are probably > > > undesirable. > > > > > The issue is that a function name maps to more than one function, > and > > > the > > > > > compiler needs to be able to disambiguate wherever it is used: in a > > > > > variable context as well as a function call context. > > > > > > > > > > For example, suppose we wanted to provide a reduce function with > type > > > > > reduce(T, T[], (T) f (T, T)). It seems reasonable that we'd want > to be > > > > > able to write: > > > > > > > > > > reduce(0, [1, 10, 3, 4], max) > > > > > > > > > > But if max is overloaded, then we have to be able to infer from the > > > type of > > > > > the first and second arguments which max was meant. > > > > > > > > > > As an aside, there's a further level of difficulty in resolving > things > > > > > correctly if you consider that overloaded functions can take > overloaded > > > > > functions as arguments > > > > > > > > > > There seems to be a number of ways to get around this problem: > > > > > 1. Don't support overloading at all, save complications at the > expense > > > of > > > > > longer function names > > > > > 2. Don't plan on supporting function references at all > > > > > 3. Ban using overloaded functions as first-class functions, force > > > users to > > > > > work around it. > > > > > 4. Attempt to do some basic type inference to disambiguate, give > up if > > > we > > > > > can't disambiguate from local information. (C++ approach, > essentially) > > > > > 5. Full program-wide type inference (Haskell approach) > > > > > > > > > > #2 doesn't fit with overall plans for the project, I don't think. > #3 > > > seems > > > > > pretty unsatisfying and I think we're best to avoid bad programmer > > > > > experiences when we have a cleanish slate to work from. #5 > doesn't > > > seem > > > > > feasible without major changes to language and compiler. > > > > > This leaves #1 and #4. I think I could make #4 work in Swift/T, > but it > > > > > would be days of work and getting all the corner cases may be a > > > challenge - > > > > > realistically I might just not get it done. I have no idea how > > > feasible #4 > > > > > is in Swift/K. #1 seems like the best effort to reward ratio to me. > > > > > > > > > > Anyway, that was a bunch of detail - does anyone have any thoughts > or > > > > > opinions? Have I missed anything? > > > > > > > > > > I'm already assuming that we just shouldn't support overloading > > > functions > > > > > with any other kind of polymorphic arguments - it's not really > > > necessary > > > > > and too complicated to implement > > > > > > > > > > - Tim > > > > > _______________________________________________ > > > > > Swift-devel mailing list > > > > > Swift-devel at ci.uchicago.edu > > > > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel > > > > > > > > > > > > _______________________________________________ > > > > 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: