seems there is some difference in 'load' and 'import' ,the same program can
run with 'load' and not with 'import'
about the overloading of n-arity operators i find a solution in
'define-method' :

(define ⋅ (make-procedure method: (lambda (x ::number y ::number) (* x y))
 method: (lambda (x ::matrix y ::matrix) (multiply-matrix-matrix  x y))
 method: (lambda (x ::matrix y ::vector) (multiply-matrix-vector  x y))
 method: (lambda lyst (apply * lyst))))


(insert-operator! * ⋅)

kawa -d classes
-Dkawa.import.path=".:/Users/mattei/Scheme-PLUS-for-Kawa:./kawa" -C
exo_retropropagationNhidden_layers_matrix_v2_by_vectors4kawa_classes.scm

i hoped to have a speed up by compiling the kawa code in .class files but
it is the same , i suppose that 'load' compile the code , ad he does it
with more easyness than 'require' , with 'load' the overloading features of
Scheme+ worked fine , not with 'require'



On Thu, Nov 16, 2023 at 11:53 PM Damien Mattei <damien.mattei@gmail.com>
wrote:

> (import (rename (scheme base) (* orig*)))
>
> (define * (make-procedure method: (lambda (x ::number y ::number) (orig* x
> y))
>  method: (lambda (x ::matrix y ::matrix) (multiply-matrix-matrix  x y))
>  method: (lambda (x ::matrix y ::vector) (multiply-matrix-vector  x y))))
>
> is there a way to still have * a n-arity operator with typed methods ?
> because now i have this error:
> (* 2 3 4)
> Argument  (null) has wrong type
> at gnu.mapping.CallContext.matchError(CallContext.java:185)
> at gnu.expr.GenericProc.applyToConsumerGP(GenericProc.java:132)
> at gnu.kawa.functions.ApplyToArgs.applyToConsumerA2A(ApplyToArgs.java:132)
> at gnu.mapping.CallContext.runUntilDone(CallContext.java:586)
> at gnu.expr.ModuleExp.evalModule2(ModuleExp.java:343)
> at gnu.expr.ModuleExp.evalModule(ModuleExp.java:211)
> at kawa.Shell.run(Shell.java:289)
> at kawa.Shell.run(Shell.java:196)
> at kawa.Shell.run(Shell.java:183)
> at kawa.repl.processArgs(repl.java:724)
> at kawa.repl.main(repl.java:830)
> the problem is that * is no more n-arity operator now
>
> Damien
>
> anyway there is perheaps a possibility of using a variable number of args
> but i did not think it this evening.... perheaps tomorrow...
>