Function definition

[Ivan Čukić]

On Saturday 26 July 2014 00:54:33 Aaron J. Seigo wrote:
> each thing does one thing.

Except for the equality sign. Is using the same tokens in different places 
that much of a problem? (irrelevant of return type and ->)

> 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 :)

It adds clarity, and saner compiler messages. Just think of duck-typing 
produced template error messages in C++ (essentially a back-trace of executing 
a template meta-program), as opposed to a regular early bailout for an 
unmatched argument type.

> 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" ;)

I prefer compiler errors to the runtime ones.

Sometimes, I want the compiler to check whether I have made a mistake or not.
Usually, I want to rely on the (implicit) auto, but sometimes I want to ensure 
I got the right type, or am returning the right type. Otherwise, like with 
TMP, I'm going to detect a bug in the library a couple of layers higher.

For example, we have a comparator factory called stringComparator(locale) 
which returns comparison operators, and we have the following code
    names.sort(stringComparator("en_GB.UTF-8"))
We got an error that compare(item1, item2) can not be called. Where is the 
bug? Is it that stringComparator has returned a value 42 instead of a functor, 
is it that it returned a functor that can not handle strings (a bug in a 
function that the comparator uses?), did the factory have an if/else branch 
and one of them is not returning what it should, does the comparator have an 
issue with a specific string and returns a float instead of a bool, etc. Is 
the problem in the sort function?

If the compiler checked whether a return type in all branches was the one that 
the developer wants, we would get a precise error.

If we don't add a way for the user to enforce a type, and we add argument 
types, we will be seeing a lot of these:

    stringChecker (String s) { 0 }
    :::

    let s = intToStr(x);
    let l = log(x);
    let check_types = stringChecker(s) + floatChecker(l);

Library writers will want checks, if the ordinary users will not.

> 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

What if we don't want to handle the error, and do an early bailout if the 
returned thing is not of a required type. That is, we want to enforce that 
something returned a valid value (for symmetry to the when clause and typing 
for function arguments)


> 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.

Not ambiguities (at least, I don't see them) - more of a compiler speed issue. 
When you have things on the right side, you don't need to remember them - in 
the sense of "ok, don't know what this is yet, neither this, this and that, 
and that, hmh got the '(', ..., oh here's a curly brace, this looks like a 
function definition, and I thought it was an expression. Heh, silly me".

It will be even more fun if the tags get arguments. Like
   dbus("org.kde.Test.method1)
   receiver
   someFancyCheck(...)
   method1(arguments) {
       :::
   }

Cheerio,
Ivan

p.s. I just realized I'm writing fun instead of func all the time. Not 
intentionally, I guess ML lives in my subconsciousness.

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