[nem-en] This sounds like a bug.

[Michal Moskal]

On Wed, Jul 14, 2004 at 10:22:45PM -0700, Maurizio Colucci wrote:
> On Wednesday 14 July 2004 12:22, Michal Moskal wrote:
> > On Tue, Jul 13, 2004 at 04:37:27PM -0700, Maurizio Colucci wrote:
> > > Hello again.
> > >
> > > Nemerle doesn't seem to be able to infer the type of "o" in the line
> > > marked (***). OTOH, if I specify the type (Obj), it compiles. But the
> > > type could be inferred by looking at the type of ForAll...
> > >
> > >
> > > using Nemerle.Collections;
> > >
> > > [Record]
> > > class Obj{
> > >   public name: string;
> > > }
> > >
> > > module Logic{
> > >
> > > public they_are_all_called_j( selected_objects : list<Obj>) : bool{
> > >     List.ForAll( selected_objects,
> > >                   fun (o ) { o.name == "j"}); // ERROR HERE (***)
> > > }
> > >
> > > } // module Logic
> >
> > Unfortunately type inference works bottom-up. That is the type of lambda
> > must be known before the ForAll is typed. We have considered having
> > certain backtracking strategies 
> 
> Thanks for the reply.
> 
> There are two things I don't understand:
> 
> 1) It seems to me the bottom-up approach should work in this case, because 
> there is only one class with a member called "name". Starting from the 
> inside, we read o.name, and we can immediately infer that "o" is of type 
> "Obj", since Obj is the _only_ class that provides a member called "name".

You should consider not only classes in your program, but also public
classes in all DLLs you -referenced:'ed. Now this can easily lead to
a situation where you add one DLL to the compilation command line and
your program suddenly refuses to compile. This is counterintuitive.

> 2) Even if there were another class with a member called "name", I still don't 
> see why you need a backtracking approach. It seems to me a bottom-up approach 
> should still work. Suppose you have three classes with a member called 
> "name":

In addition to the problem described above (adding a classes causes
compilation errors elsewhere), this would have problems with error
messages. Displaying 2-screen long list of possible types of an expression
isn't very user-friendly.

I guess we will have to add this to the FAQ.


-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: ::: Logic is a nice contrast to the Real World. :: UL++++$ C++ E--- a?