Function definition

[Aaron J. Seigo]

On Friday, July 25, 2014 18:11:02 Ivan Čukić wrote:
> fun functionName(arg1, arg2, ...) -> Type
>     when arg1 > 0 && arg2 < 0,
>     tailrec, receiver, test, other_tags_or_annotations
> {
> 
> }

Hopefully we don't have to mark functions as recursive (tail or otherwise)... 
that said ...

I actually had tags post-fixed at one point as in your example. didn't test 
very well. Kevin pointed out that nearly all analogs in C++ are prefix.

I dropped 'func' (or 'fun', whichever :) from top-level functions since there 
is no possible ambiguity there. It is only necessary when creating a function 
for assignment. but there's no particular harm to having them there if it 
helps make things clearer for people.

If return types get added to functions, i'd like them prefixed for C-ishness. 
i'm convinced that familiarity is absolutely key to getting adoption.

(Also, '->' is also intended for message passing, and so far i've been trying 
to redundancies out: one way to do things, each thing does one thing.)

So.. Return types .. I need to do some "pro's and con's" about them and come 
back to this. If you have a list already, please share :)

>  - Argument types: because of fun/let and similar, I think that right-side
> types should be preferred. (if Java devs are able to switch to Scala's
> number: Int, I guess c++ people could as well). So:

It is more important that things look familiar. There will already be enough 
new things to learn, everything that doesn't absolutely have to be different 
should remain the same. It needs to feel comfortable, even though they are in 
a slightly different world.

>     let i: Int = 0  // type would be deduced, if not specified (it would not
> be specified most of the time)
>     fun f(i: Int, s: String) -> String
> A possible alternative would be (I'm just not used to it)
>    let Int i = 0
>    fun String f(Int i, String s)

One of the nice opportunities in stepping away from C++ is getting away from 
the explicit typing of variables. Let the runtime infer them. "i = 0" is 
already clear that it is an integer (e.g.). One of the real downsides of 
explicit typing is one then needs to track the history of every assignment:

	let int a = foo();

does foo() return an int? should we care? what if it returns an error and we 
want to actually handle that rather than generate another error because the 
error doesn't match the declared type of a? This path will lead us to "auto" 
;)

	let int a = foo(); // apparently foo returns int :)
	... 20 lines of code ...
	let <?> b = a;

To know the type for b we have to go back and see what we did for a. Unless 
there are significant benefits to explicit typing, I'd like to avoid it for 
simplicity of usage. I don't like having it optional, either, (an "implicity 
auto") because then we have some code written one way and some another.

I do like optional typing of parameters; it adds to the pattern matching 
capabilities and removes the need to use ugly precondition clauses for it 
instead. It doesn't really add anything but clarity. So ... added :)

>  - If we had a special syntax for tags and annotations - something like
> C++11's [[something, something]] or Java's @something, @something, we could
> allow the them in the front as well as after the function head without much
> parsing problems. Something like:

Do prefix tags cause ambiguities that will get in the way of parsing? Every use 
I've tried thus far seems unambiguous, but maybe I've missed some cases.

>  - If using jokers, the arguments can be omitted as well:
>     fun _1 + _2 + _3 // from C++ - std::placeholders
>     fun _ + _ + _ // equivalent to the above
>     fun _1 + _2 + _1 // if one needs to repeat an argument

Too many rules for people to learn. Simplicity, even when it hurts, will be 
key to making something people (inc. average and/or enthusiast developers) are 
willing to pick up and use. Simplicity, consistency ... because getting people 
to use a kind-of functional language that asks you to split your app into a 
dozen processes is already radical enough

-- 
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/6652676e/attachment.sig>