funq: syntax that doesn't scare off C++ developers

[Ivan Čukić]

Hi Aaron,

> OK.. so the first thing that I'd really appreciate feedback on is the
> general feel of the funq syntax. While it intends to be a pragmatically

General feel - mostly ok, but I do have some issues with it.

> tags functionName(parameter list) : preconditions
> {
> 	code block
> }

1. The first thing I'm concerned about is the colon syntax for preconditions - 
it will be confused for initialization (c++), or typing (pascal, scala). I'd 
rather have an explicit keyword like 'assuming', 'requires', 'assert' or 
similar.

Like:
someFunction(a, b, c)
    requires(a > 0 && b + c < 100)
{
    something here
}

2. What would a function look like if one wants to do explicit typing for 
arguments and/or result?

> Preconditions optionally follow the the parameter list and allow various
> boolean checks to be made on the parameters. The third fibonacci function
> version checks that x is an integer and greater than 2.

3. I'm guessing that preconditions are also involved in pattern matching?

> There are no return types; functions are free to return different types.

4. Related to (2):
 - it seems strange to have a statically typed language where a function can 
return a different type depending on arguments
 - it is useful to have strict compiler-checked typing (even optional) - less 
bugs can get into the code

> part to single-assignment). Due to single-assignment, there is no need for
> a comparison operator (==). The assignment operator does both assignment

While there is no technical need for ==, it doesn't mean that the resulting 
code is readable. It is needed for usability - if you are reading a long 
function and encounter something = 2, you need to go upwards and check whether 
something was already defined or not to see whether it is a new alias or a 
comparison.


Cheerio,
Ivan


KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/ 
gpg key id: 850B6F76, keyserver.pgp.com