[nem-en] Clarification on type-inference rules.

[Michal Moskal]

On 11/12/05, Gerard Murphy <g.j.murphy at sageserpent.com> wrote:
> > Yes, this would be possible, though I would call it a hack :-)
>
> My dialect of English calls that a, ahem, *feature*. ;-)

:-)

> Well, I was thinking more of:-
>
> interface __tmp_hack: IComparable[__tmp_hack]
> {
> }
>
> sort (new List.Nil[__tmp_hack]());
>
> Still, it's basically the same idea: equally as horrible.

Ha! But simpler, no need to implement methods :-)

> > > I wonder if you could adopt a similar solution to what I think you do
> > for
> > > lists - use a special subclass for the polymorphically-typed empty array
> > > values by analogy with 'list.Nil'. I know that lists are algebraic data
> > > types with variants, and arrays are not, but perhaps there's a way out
> > in
> > > that direction?
> >
> > I don't quite get it.
> >
>
> I was thinking that however the type inference system currently deals with
> empty lists could be leveraged to deal with empty arrays - so in effect
> there would be 'array['x]' on one hand and 'empty_array' on the other,
> analogous to 'list.Cons', 'list.Nil'.

There is no difference between a list and an array here. The example
works exactly the same with an empty list instead of an empty array.

There are also no mutability problems involved (at least not explicitly).

The subtyping relations for list constructors are list['a].Cons <:
list['a] and list['a].Nil <: list['a]. Note that there is a separate
Nil for each type of elements stored in the list. You can observe this
with the following program:

def f(x : object) { System.Console.WriteLine (x.GetType()) }
f ([] : list [int]);
f ([] : list [string]);

which prints:

Nemerle.Core.list`1+Nil[System.Int32]
Nemerle.Core.list`1+Nil[System.String]

(the + is used inside CLR to denote a . in nested type, and `1 is
internal encoding for number of type parameters).

> Still, this suffers from the same faults as the '__tmp_hack' solution above:
> the 'empty_array' type is visible via reflection, and instances of
> 'empty_array' can escape local scopes via upcasting to System.Object or
> System.Array.
>
>
> You've made me realize that it might not be worth fixing up this corner case
> in the language after all.
>
> I say this because most of the time, empty arrays will arrive in a local
> scope via some expression whose type can be inferred (e.g. a function
> argument), rather than from an empty array constructor expression. That's
> both useful in real life and perfectly permissible as the array element type
> is known.
>
> Even if an array constructor expression *is* used to create an empty array,
> chances are that a couple of lines further down in the code, there will be
> some use of the array that will cause type inference to bind the type
> variable to something concrete.
>
> This leaves code like my example as the remaining open case - and to be
> honest I can probably live without that after all. Provided the compiler
> emits a suitable error message...
>
> "Gerard, you dolt, why are you creating an empty array that you could never
> do anything useful with?"
>
> ...then I'd be happy!

:-)

Anyway the actuall problem is not with the empty array, but with
unused empty array restricted to IComparable['a], which is even less
common.

But as Kamil said it would be probably possible to special case
IComparable just for better error messages. I've not seen any other
useful cyclic type yet ;)

Cheers!

--
   Michal Moskal,
   http://nemerle.org/~malekith/