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

[Kamil Skalski]

> Well, I was thinking more of:-
>
> interface __tmp_hack: IComparable[__tmp_hack]
> {
> }

Well, we could have some common interface, like
Nemerle.Builtins.IComparableInstance,
but this would be limited to this single type. For other self
referencing constraints the tmp_hack would be necessary anyways. But
maybe it is worth to have this single special case, to avoid *some*
confusing error messages.

So the question is, how much of user's confusion could we save? If it
is just a special corner case, which is not present in real-life...

>
> sort (new List.Nil[__tmp_hack]());
>
> Still, it's basically the same idea: equally as horrible.
>
> As you reminded me, arrays are immutable, so either variation might work for
> empty arrays too.
>
> > Note that without the constraint we would use List[object] type, which
> > can also be argued to be not expected...
> >
> > This isn't exactly the case you described, but the instantiation
> > problem is the same.
>
> I agree with your diagnosis, though - when I thought of this I forgot about
> upcasting and reflection.
>
> *** SNIP ***
>
> > >
> > > 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'.
>
> 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!
>
>
> Cheers,
>
> Gerard
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>


--
Kamil Skalski
http://nazgul.omega.pl