Function definition

[Jay Woods]

The kind of analysis you go through here reminds me of some design
considerations for the running of the compiler.

It would be handy to have a switch that can be turned on and off around
some dicey piece of code. The switch would be for the
"stream-of-consciousness" mode. Have the compiler tell you what is going on
rather than having a bunch of code to do the same. After all, with a
switch, it all goes away when you understand and act on what is happening.


On Sat, Jul 26, 2014 at 5:43 AM, Ivan Čukić <ivan.cukic at kde.org> wrote:

> 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
> _______________________________________________
> Funq-devel mailing list
> Funq-devel at kde.org
> https://kde.org/mailman/listinfo/funq-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kde.org/pipermail/funq-devel/attachments/20140726/4384854c/attachment.html>