--* From postmaster%watson.vnet.ibm.com@yktvmv.watson.ibm.com  Thu Dec 23 07:20:06 1993
--* Received: from yktvmv.watson.ibm.com by leonardo.watson.ibm.com (AIX 3.2/UCB 5.64/4.03)
--*           id AA10628; Thu, 23 Dec 1993 07:20:06 -0500
--* X-External-Networks: yes
--* Received: from watson.vnet.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3)
--*    with BSMTP id 0781; Thu, 23 Dec 93 07:26:24 EST
--* Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0"
--*           id <A.SANTAS.NOTE.YKTVMV.4311.Dec.23.07:26:24.-0500>
--*           for asbugs@watson; Thu, 23 Dec 93 07:26:24 -0500
--* Received: from bernina.ethz.ch by watson.ibm.com (IBM VM SMTP V2R3) with TCP;
--*    Thu, 23 Dec 93 07:26:22 EST
--* Received: from neptune by bernina.ethz.ch with SMTP inbound id <3346-0@bernina.ethz.ch>; Thu, 23 Dec 1993 13:26:15 +0100
--* From: Philip Santas <santas@inf.ethz.ch>
--* Received: from rutishauser.inf.ethz.ch (rutishauser-gw.inf.ethz.ch) by neptune id AA14805; Thu, 23 Dec 93 13:26:11 +0100
--* Date: Thu, 23 Dec 93 13:26:09 +0100
--* Message-Id: <9312231226.AA02018@rutishauser.inf.ethz.ch>
--* Received: from vinci.inf.ethz.ch.rutishauser by rutishauser.inf.ethz.ch id AA02018; Thu, 23 Dec 93 13:26:09 +0100
--* To: asbugs@watson.ibm.com
--* Subject: Re: duplicate use of parameter names in dependent products
--* In-Reply-To: Mail from 'Philip Santas <santas@inf.ethz.ch>'
--*       dated: Wed, 22 Dec 93 23:11:41 +0100
--* Cc: bronstei@inf.ethz.ch, santas@inf.ethz.ch, jenks@watson.ibm.com

--@ Fixed  by:  SSD   Tue Nov 8 10:59:39 EST 1994 
--@ Tested by:  none 
--@ Summary:    See the detailed description below. 


This example might show why the system is confused in the previous
bug-report; so that we exclude the case I mistakenly suspected that it might
be confused by the multiple curried 'x's (as Manuel said, they are
valid, ie. that was not a bug).

This code compiles:

SI==>SingleInteger
f(T:BasicType, x:T): (Y:BasicType, y:Y)->T ==
       (Y:BasicType, x:Y):Y +-> x
print(f(SI, 3)(String, "asd"))()

The type of the inner lambda is not the same as the return type
of 'f'.
Code1 of before, is a subcase of this example.

Philip

 
--+ Type inference was failing to check the type of the lambda in Code1.
--+ This bug has been fixed after v0.37.0 and the fix will appear in a
--+ subsequent version.  This code should report a type error in the defn of f.