[Swift-devel] Standard library

[Tim Armstrong]

On Sat, Jan 10, 2015 at 9:33 PM, Mihael Hategan <hategan at mcs.anl.gov> 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 <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.
>
> 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: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150110/8b67bf3d/attachment.html>