Is QML full strongly typed?

[fant]

Hi, I have any questions about type consistence of QML. In the Qt documentation its written that:

(...) the engine will enforce type-safety for properties and instances (...)

(Source: http://doc.qt.io/qt-5/qtqml-typesystem-topic.html)

or here:

Properties are type safe. A property can only be assigned a value that matches the property type.

(Source: http://doc.qt.io/qt-5/qtqml-syntax-objectattributes.html, Type safety)

So I should assume that QML is strong typed, not weak typed like JavaScript. But why I can do this, what you see in code example below?

import QtQuick 2.3
import QtQuick.Window 2.2

Window 
{
    visible: true
 
    Rectangle 
    {
        color: "blue";
        height: 5 + "1"; // seems to be an implicit cast
        width: 50;
    }
}

When I only assign the string value "5" to the height property, I get an error because wrong type. When I use a concatenation the result will be casted implicit, no type errors happens.
By definition of Peter Wegner and Luca Cardelli this example should demonstrate that QML is not strongly typed, isn't?

(...) Static typing is a useful property, but the requirement that all variables and expressions are bound to a type at compile time is sometimes too restrictive. It may be replaced by the weaker requirement that all expressions are guaranteed to be type-consistent although the type itself may be statically unknown; this can be generally done by introducing some run-time type checking. Languages in which all expressions are type-consistent are called strongly typed languages. If a language is strongly typed its compiler can guarantee that the programs it accepts will execute without type errors. (...)

(Source: http://lucacardelli.name/papers/onunderstanding.a4.pdf, p. 4)

Even another cite by Luca Cardelli:

Hence, typeful programming advocates static typing, as much as possible, and dynamic typing when necessary; the strict observance of either or both of these techniques leads to strong typing, intended as the absence of unchecked run-time type errors.

(Source: http://www.lucacardelli.name/Papers/TypefulProg.pdf, p. 3)

Thank you for answers!

[SGaist]

Hi,

For such questions, I'd recommend posting on the interest mailing list. You'll find there Qt's developers/maintainers (this forum is more user oriented)

[fant]

Thank you, I will try it. When I get a good answer, I will post it here.

[JKSH]

@fant said:

So I should assume that QML is strong typed, not weak typed like JavaScript....

QML is a superset of JavaScript. It adds a declarative, "strongly-typed" infrastructure around the imperative, weakly-typed JavaScript. So, it has both strong- and weak-typed parts.

Your code can be viewed this way:

Window
{
    visible: <JavaScript Expression>

    Rectangle 
    {
        color: <JavaScript Expression>
        height: <JavaScript Expression>
        width: <JavaScript Expression>
    }
}

The things on the right-hand-side of the colons (:) are JavaScript expressions, so they follow the typing rules of JavaScript. Anything outside that is "strongly typed".

When I only assign the string value "5" to the height property, I get an error because wrong type. When I use a concatenation the result will be casted implicit, no type errors happens.
By definition of Peter Wegner and Luca Cardelli this example should demonstrate that QML is not strongly typed, isn't?

I'm surprised that 5 + "1" works. actually; it feels like a bug to me. (If it's intended, then it's a counterintuitive design...)

Note that 5 + "1" gives you a string "51", not the number 6. So in your code, your rectangle will have a height of 51.

Also, I did some tests:

height: 51 // OK
height: 5 + "1" // OK
height: "5" + 1 // OK
height: "5" + "1" // OK
height: "51" // ERROR

All the ones marked "OK" give a height of 51.

(...) this can be generally done by introducing some run-time type checking. Languages in which all expressions are type-consistent are called strongly typed languages. If a language is strongly typed its compiler can guarantee that the programs it accepts will execute without type errors. (...)

Note that QML is an interpreted language. There is no compiler^. Even the "strongly typed" parts of QML are checked at runtime.

^ To be precise, there is a commercial Qt Quick Compiler, but this is not a core requirement of the QML language.

[fant]

@JKSH Thank you for answer. Could you give me an example for a strong typing part or didn't you know any? (I see, even you puts the word strongly typed between quotation marks)
When I looking to my code, there aren't many possibilties where strong type checking could be done, except for static (and constant!) value assignment. Also a signal seems to matter whether an argument matches to the requested parameter type or not (I know, emit the signal is evaluated as JavaScript expression).
When I did further tests, I realized following: If its possible to make an implicit typecast, it will doing a cast. Otherwise it throws a type error.

Example:

height = false; // height = 0
height = "false" // can not assign QString to double
height = "51" // height = 51

property int c: 2;
property string d: c; // ok 

Note that 5 + "1" gives you a string "51", not the number 6.

When I concatenate 5 and "1" and assign it to an integer property I only expecting a type error during runtime that breaks the application, nothing else.
I do further research and looking to a language like Python that is dynamically and strongly typed. In fact they argue this on this way:

In a weakly typed language a compiler / interpreter will sometimes change the type of a variable. For example, in some languages (like JavaScript) you can add strings to numbers 'x' + 3 becomes 'x3'. This can be a problem because if you have made a mistake in your program, instead of raising an exception execution will continue but your variables now have wrong and unexpected values. In a strongly typed language (like Python) you can't perform operations inappropriate to the type of the object - attempting to add numbers to strings will fail.

(Source: https://wiki.python.org/moin/Why is Python a dynamic language and also a strongly typed language)

I'm al ittle bit confused about this definition, because in comparison to Cardelli (see above, the second cite in my first post) an application is allowed to break because a type error. Eventually Cardelli means with "intended" the concept how programmers should work, so a type error will be avoided but is technically possible (cause runtime interpretation).

In a strongly typed language, you are simply not allowed to do anything that's incompatible with the type of data you're working with. (...), you can often do 'Hello' + 'And' + 'Goodbye' and get the result "HelloAndGoodBye", because strings support concatenation. But in a strongly-typed language you can't do 'Hello' + 5 + 'Goodbye', because there's no defined way to "add" strings and numbers to each other. In a weakly typed language, the compiler or interpreter can perform behind-the-scenes conversions to make these types of operations work; (...). The advantage to a strongly typed language is that you can trust what's going on: if you do something wrong, your program will generate a type error telling you where you went wrong,

(Source: https://wiki.python.org/moin/Why is Python a dynamic language and also a strongly typed language)

In conclusion I can say, QML is nevertheless not strongly typed, cause sometimes there are implicit typecasts, isn't?

[JKSH]

@fant said:

In conclusion I can say, QML is nevertheless not strongly typed, cause sometimes there are implicit typecasts, isn't?

Actually, I just realized that the authors you quoted in your original post talk about static typing, while the authors you quoted in your latest post talk about strong typing. They are not the same; which one do you want to discuss?

I also just found out that "strong" vs "weak" is very poorly-defined.

See:

• http://stackoverflow.com/questions/2351190/static-dynamic-vs-strong-weak
• https://en.wikipedia.org/wiki/Strong_and_weak_typing

Anyway, here are some questions for you:

1. Why do you wish to determine whether QML is strongly or weakly typed?
2. Do you think C++ is strongly or weakly typed?

To kick off the discussion, here are some examples of implicit type conversion in C++:

int i = 4.2; // Implicitly converting a double to an int: It loses precision, but it's legal

/* Here are 3 different ways to create a red QColor: */
QColor c1 = 0xffff0000; // Implicitly converting an int to a QColor
QColor c2 = Qt::red; // Implicitly converting an enum to a QColor
QColor c3 = "red"; // Implicitly converting a string to a QColor

C++ even allows you to define your own implicit conversions, by implementing operator=(), or implementing a constructor that takes 1 argument. However, C++ does type-checking at compile-time.

[fant]

I assumed, dynamic or static type-checking would be also a property to determine whether the language is strong typed or not, at last. So its written in Wikipedia:

In fact, many of these are more accurately understood as the presence or absence of type safety, memory safety, static type-checking, or dynamic type-checking.

And Cardelli/Wegner uses this property to argue about strongly typing. The words "static typing" and "dynamic typing" are always clearly defined in this context.

1. Why do you wish to determine whether QML is strongly or weakly typed?

First I see the definition of typing discipline in Wikipedia about QML: dynamic, strong (https://en.wikipedia.org/wiki/QML), but there is no statement, why QML should be strong. Then I did research and read the article in Stackoverflow about "Is JavaScript an untyped language?" (http://stackoverflow.com/questions/964910/is-javascript-an-untyped-language) and the explanations of Cardelli. At last I was very confused about this. :/
It seemed to be something that can be defined precisely, like the top of a house, whether the roofing tiles are red or not red.

2. Do you think C++ is strongly or weakly typed?

Yes, you are right.... when I assign "hello" to c3 it works, too...
Probably there is no clear differentiation between "strong" and "weak", instead of this it should be graded whether a language is stronger/weaker than another one. For instance C++ is stronger typed than JavaScript but weaker than Haskell.