[Swift-devel] Standard library

[Tim Armstrong]

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 <K,
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.

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 <hategan at mcs.anl.gov> 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: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150110/e2108fd1/attachment.html>