One more bug in type engine: 1128

[VladD2]

http://nemerle.org/bugs/view.php?id=1128

I try fix it but I have a some problems.
Michel, maybe you allot some time for fix bugs in type engine.
It's bugs prevent development evolution of compiler and libraries.

[VladD2]

On Jul 26, 10:04 pm, VladD2 <v...@rsdn.ru> wrote:

Kamil, Michel...

How I understand in case of Kind.Overloaded (overloads) in
DoResolve.ExpectMember (name : string) : void
we should do standard overload resolution logic.
Right?

> I think bug in line 691 of http://nemerle.org/svn/nemerle/trunk/ncc/typing
> /Typer-DelayedTyping.n: [^]
> | Kind.Overloaded (overloads) =>
> def expr = DtKind.filtering_expression;
> def o' =
> if (expr == null) {
> RemoveExtensionMethods (OverloadPossibility.OnlyPossible > > (overloads, expected))
> } else {
> ...
> It code wrong. It not choise bast overload or/and not exclude
> generic methods.
> I think in this place need call GetBestOverloads(), but it case
> some problem:
> 1. GetBestOverloads() which fail on permutation_array is null.
> 2. Sometime in code above "overloads" contains overloads with
> same count of args.

1. Is correct if I fill permutation_array array (in FormalTypes :
array [TyVar property) like this:
when (permutation_array == null)
{ // The permutation_array is null if func pass into other func.
permutation_array = array (formals.Length);
foreach (i in [0..permutation_array.Length - 1])
permutation_array[i] = i;
}
and remove line:
Util.cassert (formal_types != null || permutation_array != null);
?

2. Is correct if I
| Kind.Overloaded (overloads) =>
def expr = DtKind.filtering_expression;
def o' =
if (expr == null)
{
def res1 = OverloadPossibility.OnlyPossible (overloads, expected);
def res2 = if (checkForAllOverloadsSameCountofArgs(overloads))
typer.GetBestOverloads(res1);
else res1;
res2
instade:
| Kind.Overloaded (overloads) =>
def expr = DtKind.filtering_expression;
def o' =
if (expr == null)
{
RemoveExtensionMethods (OverloadPossibility.OnlyPossible
(overloads, expected))

[Michal Moskal]

I think it makes sense. Actually any change that improves the accuracy
of overload selection and doesn't break it in some often used cases
seems good.

You're right that the permutation array should default to identity.
Michał

[VladD2]

2008/7/31 Michal Moskal <michal...@gmail.com>:

> I think it makes sense. Actually any change that improves the accuracy
> of overload selection and doesn't break it in some often used cases
> seems good.
>
> You're right that the permutation array should default to identity.
> Michał

Michał, please, check revision 8076. I not completely understand
delayed overload resolution logic...

And, Michał, without you we can't fix some issues in type engine.
Please, help resolve it.
Very important issues is http://nemerle.org/bugs/view.php?id=1103

[Dmitry Ivankov]

I was thinking about it yesterday and thought of 2 ways:
1) "Extend TyVar state"
Add flags (canBe void/tuple/fun) or lists of needed members to TyVar's state.
Add TyVar.RequireMember, taking member name (+maybe more details like header, type, ..) and modifying the state.
And check for contradictions in MType.provide/require with TyVar having this flags.
2) "Add new MType"
Add new class MType.WithMember, which acts like fresh TyVar, but can't provide/require with surely nonmatching MTypes.

Which one is more natural for the type system?
Second one looks harder to implement, but closer to pure "has member" class family.
 

[Michal Moskal]

> I was thinking about it yesterday and thought of 2 ways:
> 1) "Extend TyVar state"
> Add flags (canBe void/tuple/fun) or lists of needed members to TyVar's
> state.
> Add TyVar.RequireMember, taking member name (+maybe more details like
> header, type, ..) and modifying the state.
> And check for contradictions in MType.provide/require with TyVar having this
> flags.
> 2) "Add new MType"
> Add new class MType.WithMember, which acts like fresh TyVar, but can't
> provide/require with surely nonmatching MTypes.

The first way is much more natural. The MType was meant for types that
are resolved. Beside there are already constraints on the TyVar, the
has-member is just another kind of constraint.

Michal

[VladD2]

2008/7/31 Michal Moskal <michal...@gmail.com>:

> The MType was meant for types that
> are resolved.

To the point... maybe rename MType into ResolvedType in order to
people better understand it meaning?
The same way as rename GetMonoType (and something) into GetResolvedType.
When I first time found GetMonoType I think it function return
something bound with Mono project :).

[Michal Moskal]

Well it was supposed to refer to monomorphic type (as opposed to type
variable), but feel free to rename them.

Michał