[nem-en] overloads & inference

[Michal Moskal]

On 6/18/07, Dmitry Ivankov <divanorama at gmail.com> wrote:
>
>
> On 6/18/07, Michal Moskal <michal.moskal at gmail.com> wrote:
> >
> > Clearly this is sort of a hack. We just need to use the available
> > information to somehow proceed with typing. It might be possible to
> > first try resolving operators only if both types are known, and only
> > after we're stuck, try to do a single argument lookup. I'm not quite
> > sure though, if it's worth the effort.
>
> How to do that 'if stuck'?
> I've attached current patch, I suppose that logic should in
> + | [one] when t1.Hint.IsSome || (t2 != null && t2.Hint.IsSome) => //!!!
> maybe we should wait until there are both hints
> + SetKind (Kind.Resolved (one.Compile ()))
> But how to do it? Something like following?
> | [one] when OnlyOneHint =>
>    solver.PushState ();
>    def ok = !IsError ( try_type (one, final = false));
>    solver.PopState ();
>   when (ok)
>      SetKind (Kind.Resolved (one.Compile ()))
> | [one] when AllHints =>
>   SetKind (Kind.Resolved (one.Compile ()))
>
> Wouldn't it be too slow? (compared to having set of all possible operators
> of all seen types, or to real stuck detection)

There is this Typer.BadnessAllowed thing. It is supposed to be used as
a 'stuck-detection'. The typing looks roughly as follows:

BadnessAllowed = 0
do normal typings, saving delayed typings
while BadnessAllowed < limit && there are unresolved expressions
  run delayed typings, until you cannot do anything
  BadnessAllowed++

It is now used not to commit ourselves to a single overload too early,
probably this logic needs to be extended.

-- 
   Michał