<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 10, 2015 at 9:33 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Inline...<br>
<span class=""><br>
On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote:<br>
> Nice work.<br>
><br>
> I agree, I don't care about the naming convention for functions, so let's<br>
> just pick one and be consistent going forward (we can keep old names<br>
> around, at least forsome amount of time).  I'm also of the opinion that we<br>
> should avoid strcat and other c-inspired names since they don't fit the<br>
> naming convention and probably are only familiar for a minority of users.<br>
<br>
</span>I agree on strcat, etc.<br>
<span class=""><br>
><br>
> We do support user-defined polymorphic Tcl functions to some extent -<br>
> option types, type variables (e.g. the type signature for contains is <K,<br>
> V> (boolean o) contains(V A[K], K key), and variable length argument<br>
> lists.  We don't pass type information into the function, so if you want<br>
> the function to do something different for each type you can't do that.  My<br>
> understanding is that that's fairly straightforward in Swift/K since the<br>
> function can just look at the Swift type of the Java object it's passed.<br>
<br>
</span>You say user-defined and Tcl. Does this mean a user writing Tcl inside a<br>
swift script or that the mechanism to extend swift using Tcl is<br>
documented and generally accessible to users?<br></blockquote><div>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.<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And yes, the type is passed to Java. I'd like to change that to proper<br>
compile-time binding. It's not difficult, just not a priority right now.<br>
However, how do avg(int[]) and avg(float[]) work in T?<br></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> The polymorphism is compile-time (the compiler always knows the type of<br>
> each variable and expression).  I'm a little sceptical of using too much<br>
> polymorphism in library functions because it prevents type-checking from<br>
> catching errors.  I think it's fine if the function actually does<br>
> conceptually the same thing for each input type (e.g. converting them to a<br>
> string representation), but it's less of a good idea if it does different<br>
> things (e.g. converting a float to an int and a string to an int are<br>
> different operations).  There's a bit of personal taste to whether you do<br>
> these things, but I think once you allow looser typing rules,it's hard to<br>
> undo that decision.<br>
<br>
</span>I agree with what you are saying. I believe that abs/min/max/etc. can be<br>
polymorphic without much danger. I think that length(string) and<br>
length(array) are also reasonable.<br>
<br>
But I can see the wisdom in having parseFloat(string) instead of<br>
overloading toFloat(int).<br>
<br>
On the other hand, if you wanted to name them more declaratively, they<br>
would probably both sound more like asFloat().<br></blockquote><div>Yeah, I may be being overly pedantic about that, I think it's nicer in some ways having short and consistent names. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> RE: function overloading. I think we have to choose between<br>
> optional/default arguments and function overloading - I think implementing<br>
> one would preclude the other.<br>
<br>
</span>I'm not sure about that. There may be some (non-transitive) ambiguity<br>
between:<br>
<br>
f(int a) vs. f(int a, int b = 0) vs. f(int a, int b).<br>
<br>
A compiler could complain about the conflict between the middle one and<br>
the rest. But I don't see a problem with:<br>
<br>
f(int a), f(float a).<br>
<br>
Am I missing something?<br></blockquote><div>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.<br><br></div><div>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.<br><br></div><div>There are some weird corner cases.  For example, which implementation of avg would this call?<br></div><div>avg([]);<br></div><div><br></div><div>- Tim<br></div><div> <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Mihael<br>
<br>
</font></span></blockquote></div><br></div></div>