You can add a type declaration into the standard library even when there's no constructors; we do this for strings, numbers etc. data Any; gives you a type, and you will be able to remove a lot of special cases that you discuss above.

You can add a type declaration into the standard library even when there's no constructors; we do this for strings, numbers etc. data Any; gives you a type, and you will be able to remove a lot of special cases that you discuss above.

Thank you for that hint. My latest commit now reimplements Any using a "data Any;" declaration and I was able to remove the special cases. I also added some additional tests.

As a sanity check, before continueing with the pull request, I would like to first merge back this reimplementation into my thesis project and check if everything still works. I think I can do this on monday.

Re your point 2, we currently have not only equality comparison but also ordering (less-than) in ABS -- see https://abs-models.org/manual/#sec:pure-expressions, subsection "Semantics of Comparison Operators".

With Any we can now compare values of different type, so we'll need an ordering relation between them. We can do the same thing as Erlang and just define such a relation (see http://erlang.org/doc/reference_manual/expressions.html#term-comparisons).

I anticipate the next thing after Any will be demand for downcasting (we have this for object references, with the implements and as expressions; see the manual), so any run-time type info needed for comparisons between values of different types could probably be used for that as well.

I anticipate the next thing after Any will be demand for downcasting (we have this for object references, with the implements and as expressions; see the manual), so any run-time type info needed for comparisons between values of different types could probably be used for that as well.

Hmm, if possible I would like to try to avoid adding explicit additional run-time type info to values, since then we would need to adapt most of the erlang backend to be compatible with the new data format, if I'm not mistaken.

Instead, I would try to infer the type from the current representation as cmp:lt (frontend/src/main/resources/erlang/absmodel/src/cmp.erl) seems to be doing already.
For the Java backend, instanceof checks could probably be used.

By the way, by how many/which backends should the Any type ideally be supported for now? Would it be sufficient to implement comparisons for Erlang?

With Any we can now compare values of different type, so we'll need an ordering relation between them. We can do the same thing as Erlang and just define such a relation (see http://erlang.org/doc/reference_manual/expressions.html#term-comparisons).

My use case for comparisons across types was restricted to equality comparisons of future references (see first post). Should we implement a less-than hierarchy like Erlang without knowing whether someone will use it in the near future? We could also define the result of all comparisons across types to be false, but allow comparisons of references and keep the conversion of numbers. This would probably result in implementing fewer special cases. But I'm also not sure, whether this would make the language "unintuitive", if there are incomparable elements a, b which satisfy !(a < b || b < a || a == b).

What do you think?

By the way, by how many/which backends should the Any type ideally be supported for now? Would it be sufficient to implement comparisons for Erlang?

Erlang is sufficient, yes.

With Any we can now compare values of different type, so we'll need an ordering relation between them. We can do the same thing as Erlang and just define such a relation (see http://erlang.org/doc/reference_manual/expressions.html#term-comparisons).

My use case for comparisons across types was restricted to equality comparisons of future references (see first post).

I learned through experience that adding a feature specialized to my own use case leads to unhappy users, who reasonably expect generality and orthogonality of features. That's the price of working on a tool with users that I don't personally know. (The reward, of course, is also working on a tool with users that I don't personally know.)

Should we implement a less-than hierarchy like Erlang without knowing whether someone will use it in the near future?

A medium-term goal for me is to redefine sets and maps to use red-black-trees or similar; in that case we have to have an ordering relation. This would mean we couldn't have Set<Any> ...

We should have an arbitrary ordering, e.g., future < reference < string < number < user-defined datatype, and compare user-defined datatypes similar to https://abs-models.org/manual/#sec:pure-expressions, subsection "Semantics of Comparison Operators" (where we describe how we compare terms with different constructors of the same user-defined datatype). In erlang, we would need to add the name of the datatype to values, or add a constructor -> datatype name mapping (constructor names are already contained in values, since we use them for pattern matching).

Anyway, I could have a look at implementing this if you agree that the semantics are basically sane.

You are right that adding a new type which does not support the less-than operation is probably a bad idea since it would create a special case for the users and the language, as it is the only type which does not support it.

Also, just defining the result of a less-than comparison of different types to be always False is also more confusing than an arbitrary ordering, since it would create a new kind of values where !(a < b || b < a || a == b) as I mentioned above.

As we discussed in Gitter, quite a lot of type information can already be extracted from the runtime representation. However, there are some cases where explicit type annotations will be required. For example, for empty lists we can't derive the type of the elements it stores at runtime:

{
   List<Float> l1 = Nil;
   List<Bool> l2 = Nil;
   List<Any> ll1 = l1;
   List<Any> ll2 = l2;

   Bool x = ll1 == ll2; // Should this be true or false?
}

Anyway, I could have a look at implementing this if you agree that the semantics are basically sane.

I don't want to increase your workload due to an issue I caused. So if we are not in a hurry, I could also look into implementing this. However, I'm quite busy for the next few weeks and will probably only be able to pick this up again in the middle of March : /

There's also always the possibility of restricting the less-than operator to numbers and strings. We would lose the possibility of generalized sorting and container implementations, but gain implementation efficiency. If I remember correctly e.g. Reiner was in favor of eliminating the general less-than operator, but not enough so to make a strong case for it.

Please do keep reminding me about this issue; I would not want to be a bottleneck for developing ABS.

If this issue is still open at the ABS workshop in Torino, I will bring it up then.

As we discussed in Gitter, quite a lot of type information can already be extracted from the runtime representation. However, there are some cases where explicit type annotations will be required. For example, for empty lists we can't derive the type of the elements it stores at runtime:

{
   List<Float> l1 = Nil;
   List<Bool> l2 = Nil;
   List<Any> ll1 = l1;
   List<Any> ll2 = l2;

   Bool x = ll1 == ll2; // Should this be true or false?
}

I'm not sure if there's a more sophisticated argument to be made here, but I'd make a case that the code above is equivalent to the following, which is trivially true:

{
   List<Any> ll1 = Nil;
   List<Any> ll2 = Nil;
   Bool x = ll1 == ll2; // true
}

I created a new branch and opened a new pull request for introducing the restricted version of Any that we discussed: #309.

This is because I based that new version on the current state of master and I want to preserve the old branch for reference.