<div dir="ltr"><div><div><div>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.<br><br></div>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.<br><br></div><div>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.<br><br></div><div>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.<br></div><div><br></div>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.<br><br></div>- Tim<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 9:14 AM, Michael Wilde <span dir="ltr"><<a href="mailto:wilde@anl.gov" target="_blank">wilde@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Based on your point here and earlier, Tim, I agree with going with
option #1. So count this as a +1 for that.<br>
<br>
Function references give us something we can not otherwise do, while
overloaded functions is just a convenience (which not everyone will
like).<br>
<br>
How does this apply to intrinsic functions in the library, though,
eg, strcat( ) which you could view as an overloaded function?<br>
<br>
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?<br>
<br>
- Mike<br>
<br>
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.<div><div class="h5"><br>
<br>
<br>
<div>On 1/28/15 9:01 AM, Tim Armstrong
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>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. <br>
<br>
</div>
<div>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. <br>
<br>
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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>- Tim<br>
</div>
</div>
</blockquote>
<br>
</div></div><span class=""><pre cols="72">--
Michael Wilde
Mathematics and Computer Science Computation Institute
Argonne National Laboratory The University of Chicago
</pre>
</span></div>
</blockquote></div><br></div>