Quantcast
Viewing latest article 12
Browse Latest Browse All 23

Implicit Coercions in Whiley

The issue of [[Type conversion|implicit coercions]] in Whiley is proving to be a particularly thorny issue.  The following motivates why (I think) coercions make sense:

real f(int x, real y):
    return x + y

real g(int x, int y):
    return f(x,y)

I believe the above should compile without error.  However, this requires an implicit coercion from int to real in several places.  Some statically typed programming languages (notably [[ML (programming language)|ML]]) simply don’t perform any implicit coercions.  Instead, they require explicit coercions in the form of type casts.  Under this model, the above code would be:

real f(int x, real y):
    return real(x) + y

real g(int x, int y):
    return f(x,real(y))

To me, this seems rather cumbersom and, when it’s clear from the context, I want the compiler to do this for me.

So, what coercions could we support in Whiley?  Here’s a taster:

  • int –> real
  • {int x, int y} –> {int y}
  • [int] –> {int}
  • {int->int} –> {int,int}
  • [string] –> {int->string}

Unfortunately, whilst this looks all good on the surface, there are some tricky cases.  Here’s one example:

define Rec1 as { int x, real y }
define Rec2 as { real x, int y }
define Rec12 as Rec1 | Rec2

int f(Rec12 r):
   if r is Rec1:
       return r.x
   else:
       return r.y

int test():
   z = {x: 1, y: 1} // z has type {int x, int y}
   return f(z)

The problem here is that we cannot determine whether to coerce z to Rec1 or Rec2.  I guess we should report an ambiguous coercion error. Which immediately raises the question of how, in the general case, I detect this.


Viewing latest article 12
Browse Latest Browse All 23

Trending Articles