> 
> 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 fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to