Quick survey: func(..) {..} versus (..) {..}

[Aaron J. Seigo]

On Saturday, July 26, 2014 07:58:42 Jay Woods wrote:
> Something went wrong - this is probably the second post.
> 
> Here is a nonworking example based on a C function:
> 
>     fun short get_cp_amtMaxfee(double d){ i=d; return i; };
> 
> All that I had in mind was the observation to put the typing of the return
> near
> the return. We all, of course, have the return as the last statement in the
> function. :-) The compiler could, of course, type the return from the type
> of the variable or even the reverse, type the variable 'i' from the type of
> the return. It would look like:

As long as it is optional, this is ok. It does make the compiler more complex, 
however, as it would have different internal rules for functions with return 
typing and those without.

Taken to the extreme, one could allow defining multiple return types and/or 
always implicitly assume that a return type of error is possible.

(We haven't yet gotten to the "let it crash" philosophy .. but this is 
related. http://c2.com/cgi/wiki?LetItCrash )

My concern here is that it makes it very easy to write code that is less 
generic than necessary, which generates unnecessary errors due to developer 
over-strictness (e.g. defining a method to return "int" because that's is what 
htey have used it for so far, when everything in the function can equally work 
on strings).

There's a certain lazy beauty about being able to just make functions and not 
think about them in terms of return values.

If variables can be typed, this moves the need to type functions to the 
receiver, which is really the end point that matters. It is less important for 
the function to return a $TYPE than it is for the receiver to be $TYPE.

.. and yes, this is a trade-off between development flexibility and the number 
of compiler-time errors that can be caught.

I actually expect there to be real-world limits on such things anyways as 
there is no guarantee that Module A used by  Module B will retain the same 
return signatures when the code is reloaded at runtime (hot reloading).

Given the importance I'd like to see on multi-process architectures and 
therefore the message passing that will happen, the semantics of function 
calls are only going to be a certain (hopefully somewhat small) % of the means 
by which code is coupled together. I half-expect message passing typing to be 
more important than function return typing.

> As for what people are familiar with, let's not get too wrapped up in that.
> Most programming is done with the language biases of the Indo-Europeans.
> Most language usage is Chinese. Their language biases are considerably
> different. We will be seeing the time and soon that those biases will drive
> acceptance.

Except that Chinese programmers are learning C. That is what they know when it 
comes to programming. Most importantly, the audience today for funq is ~100% 
C++ developers.

Based on a number of conversations I've had on this topic with 
C/C++/Java/PHP/Python developers who don't touch fucnctional languaes, 
syntatic familiarity seems to be significant part of the reason many developers 
avoid functional languages. It's not a good reason, but when did that stop 
anyone ;)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://kde.org/pipermail/funq-devel/attachments/20140726/8f382521/attachment.sig>