> > Is this form (which would certainly work in Aldor) actually available in > SPAD? > > foo1!(t : MI, n : NNI)( > bm : MI, N : NNI, k : Z, j : Z, q : Z) : MI == > for i in 1..n repeat > t(k, i) := t(k, i) - q*t(j, i) > foo(bm, N, k, j, q)
No, such form is currently unsupported. In this case the following would probably work: foo1!(t : MI, n : NNI) == ( bm : MI, N : NNI, k : Z, j : Z, q : Z) : MI +-> for i in 1..n repeat t(k, i) := t(k, i) - q*t(j, i) foo(bm, N, k, j, q) In general Spad compiler may have trouble deciding what return type of 'foo1!' is but it seems that arguments of 'foo1!' are enough to decide which of overloaded exported sugnatures to use. In principle Spad compiler could infer from definition above return type of 'foo1!'. IIRC this problem appeared in the past. Remark: implementing Aldor way does not look very hard. I am more concerned with problem that various well-intended syntactic extensions may clash. We had several such problematic things from in the past and current 'Zero' problem is similar in spirit: internal data structure of compiler were extended to effectively pretend that 0 and 1 are symbols. So currently removing such problematic extensions for me have more priority than adding new ones. Remark2: One syntactioc extention that is very tempting to to treat: foo(x : T, y : U) : V essentially as foo : (T, U) -> V With such convention one could use exactly the same text in export list of category and in function definition. But applying literaly this convention would lead to: foo1!(t : MI, n : NNI)( bm : MI, N : NNI, k : Z, j : Z, q : Z) : MI == (bm : MI, N : NNI, k : Z, j : Z, q : Z) : MI +-> for i in 1..n repeat t(k, i) := t(k, i) - q*t(j, i) foo(bm, N, k, j, q) That is 'foo1!' would get correct type, but you would still need to provide correct value, that is lambda expression. Coming back to possible extensions, IIUC essence of Aldor way is implicit insertion of lambda. Omiting types is routine business and in case when body is single typed lambda expression inferring return type is trivial. I must admit that I am more supportive toward idea of reconstructing types than to idea of inserting code (which implicit lambda is doing): IME code insertions are much more likely to cause problems than inferred types. -- Waldek Hebisch -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to email@example.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.