Ticket #123 (new defect)

Opened 5 months ago

Can't find Csr when Csr.mul(...) is overloaded

Reported by: jmaessen Assigned to: jmaessen
Priority: major Milestone:
Component: interpreter Version:
Keywords: Cc:

Description

Uncomment the following code in source:trunk/Library/Sparse.fss :

(* Right now uncommenting unearths an obscure unification bug.
mul[\nat p\](other: Csc[\N,m,p\]) = do
        (* Follow the structure of our rows, return Csr matrix. *)
        resultRows = rows.replica[\SparseVector[\N,p\]\]()
        resultRows.init(i,sparse(row other)),  (i,row)<-rows.indexValuePairs()
        Csr[\N,n,p\](resultRows)
  end
*)

Doing so yields the following error:

com.sun.fortress.interpreter.evaluator.ProgramError: 
/Users/jmaessen/PFC/Library/Sparse.fsi:34:7~10: Missing type Csr
Context:
/Users/jmaessen/PFC/Library/Sparse.fsi:34:7~10
ProjectFortress/tests/sparseMatrix.fss:81:2~29
ProjectFortress/tests/sparseMatrix.fss:81:2~29

	at com.sun.fortress.interpreter.evaluator.ProgramError.error(ProgramError.java:91)
	at com.sun.fortress.interpreter.evaluator.CommonEnv.getType(CommonEnv.java:165)
	at com.sun.fortress.interpreter.evaluator.EvalType.forId(EvalType.java:446)
	at com.sun.fortress.interpreter.evaluator.EvalType.evalType(EvalType.java:75)
	at com.sun.fortress.interpreter.evaluator.types.FTraitOrObject.unifyNonVarGeneric(FTraitOrObject.java:305)
	at com.sun.fortress.interpreter.evaluator.types.FTypeObjectInstance.unifyNonVar(FTypeObjectInstance.java:85)
	at com.sun.fortress.interpreter.evaluator.types.FType.unify(FType.java:573)
	at com.sun.fortress.interpreter.evaluator.EvaluatorBase.inferAndInstantiateGenericFunction(EvaluatorBase.java:238)
	at com.sun.fortress.interpreter.evaluator.values.FGenericFunction.applyInner(FGenericFunction.java:204)
	at com.sun.fortress.interpreter.evaluator.values.Fcn.apply(Fcn.java:100)
	at com.sun.fortress.interpreter.evaluator.EvaluatorBase.functionInvocation(EvaluatorBase.java:87)
	at com.sun.fortress.interpreter.evaluator.EvaluatorBase.functionInvocation(EvaluatorBase.java:77)
        ...

Which is clearly a runtime name-lookup problem of some sort.