pattern matching and type coercion

[lutzhamel]

Consider the following program,

let x:%real = 0.

This fails with message pattern match failed: expected typematch real got a term of type integer . This failure is interesting because technically we have the hierarchy integer < real allowing for automatic type conversions thus any integer can be interpreted as a real making the failure above questionable. Furthermore, in any other language with type hierarchies the analog of the above let statement succeeds. We should be considering an automatic type promotion on the right in order to fulfill the type match and perhaps make Asteroid behave more like other programming languages. Here is another program with the type promotion issue in a function setting,

load system "io".
load system "math".

function c
  with 0.0 do
    return 0.0.
  orwith x:%real do
    return sin(x)/(x*pi).
end

println (c(1)).

Here the call c(1) fails but it probably shouldn't.

It gets even more interesting because we have the hierarchy integer < real < string thus the following statement should succeed,

let ".*010.*" = 10101.

This implies that we can use regular expressions on ANY value in our type hierarchies!

*With a pattern as a type, would these mean we could match a regular expression against a structural pattern? *

With a pattern as a type, would these mean we could match a regular expression against a structural pattern?
That is an interesting question. The following program would succeed if we implement pattern matching with type coercion,

let ".*41.*" = (41,14).

because tuple < string. However, currently the following program,

let ".*41.* = pattern with (41,14).

would fail because the type relationship pattern < string is currently not defined. Should we define that?

Could we match a regular expression against another regular expression?

Yes, that works already in the current implementation because regular expressions are of the type string . The following program succeeds in the current implementation,

let ".*\+.*" = "[0-9]+".

Does the type coercion during pattern matching have an impact on the overlap-detector?

Consider the following function,

load system "io".

function c
  with x:%integer do
    return 1.
  orwith y:%real do
    return 2.
end

println(c(1)).

calling c with 1 when considering type promotion during pattern matching makes the function multi-dispatch ambiguous because 1 can be considered both an integer and a real.

[lutzhamel]

At this point I am not convinced that we should be supporting this. It makes a mess out of pattern matching.

[lutzhamel]

Since the let statement is a pattern match statement and not an assignment we will not apply type promotions to the expression on the right side. Applying type promotion during pattern matching is messy and unpredictable. In particular, consider the implicit matching in with clauseswhere we rely on the fact that we can pattern match on types like here,

function c
  with x:%integer do
    return 1.
  orwith y:%real do
    return 2.
end

This kind of code would no longer work but is fundamental for the proper definition of functions.

This true for all implicit pattern matching as well as the is predicate.

[lutzhamel]

Regular expressions in pattern matching. The following let statement will fail because we don't allow for implicit type promotion during pattern matching,

let q:".*41.*" = (41,14).

but can be rewritten as

let q if type @tostring q is ".*41.*" = (41,14).

which will succeed.

[lutzhamel]

For now there are no type promotions applied at pattern match sites.