On 04/11/2018 07:20 PM, Waldek Hebisch wrote:
>> 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)

Oh. You really mean that there is no colon and return type between ")"
and "==" ?

To be honest, even though after the == there is enough information about
the return type, I would somehow want all the type information before
the "==".

But that is only a side remark.

> 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.

Yes, I faintly remember that I fell into this trap before. Maybe I'm too
Aldor "spoiled". ;-)

> Remark: implementing Aldor way does not look very hard.

THAT would be great.

> 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.

I remember a discussion with Gaby Dos-Reis, where I said that there is a
difference between t: T and  t(): T, i.e., something like 0: % in Aldor
vs. Zero(): % in Spad. I agree that they would be the same in a truely
functional language, but for me a nullary function can still have side
effects. Aldor clearly distinguishes between t: T and t: () -> T. And I
find that behaviour very clean. Also treating 0 and 1 as a letters in
certain contexts in SPAD would avoid the need for Zero(), and actually 0
shouldn't be a nullary function, it's a constant. If SPAD wouldn't
sometimes treat constants and nullary functions equally, I would really
appreciate it. I don't even currently know any rule when or even how the
SPAD compiler treats nullary functions and constants.

> Remark2: One syntactioc extention that is very tempting to to
> treat:
>     foo(x : T, y : U) : V
> essentially as
>     foo : (T, U) -> V

You probably know Chapter 6.6 of http://www.aldor.org/docs/aldorug.pdf .
I hope you don't invent something other.

It should be

    foo : (x : T, y : 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.

Please not that way. When I see

  f(a: A)(b: B): C == BODY

then BODY should return a value of type C. How do you tell a programmer
that he should consider

  f(a: A)(b: B): C == (b: B): C +-> BODY

and not

  f(a: A)(b: B): C == (a: A) +-> (b: B): C +-> BODY


> 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.

Well I cannot say anything about the implementation of the Aldor
compiler, but tha AUG suggests that the basic form of a function looks like

  f: A -> B == (a: A) : B +-> BODY-RETURNING-AN-ELEMENT-OF-B

and that


is essentially syntactic sugar for the above.

Maybe Peter Broadbery can say more about Aldor internals.


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