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

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

is essentially syntactic sugar for the above.

Maybe Peter Broadbery can say more about Aldor internals.

Ralf

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