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
