On 02/14/2014 07:12 PM, Waldek Hebisch wrote:
> _Before_ compiling 'e pretend T' Spad compiler has to compile 'e'.
I probably don't understand much of that compilation stuff, but yes that
is what I would expect. In fact, I would want that compilation is unique
(with out the pretend). In other words, the compiler should have enough
context information to compile e.
Suppose, the compiler knows about foo: S->T1 and foo: S->T2 and then
sees (foo(s) pretend T3). I would like the compiler to shout because of
this ambiguity.
I would even want it to shout, if T1 and T3 were identical, because in
this case 'pretend' is pretty superfluous.
> 'pretend' affects compilation of 'e', because due to 'pretend' Spad
> prefers 'T' as the result type.
This is what I don't like. Why should 'pretend T' behave like '@T'?
> I think that general rule is the same for Spad and Aldor. And
> probably you use '(x@%) pretend T' to avoid consequences of this rule
> in Aldor.
Maybe. That macro is, in fact, from aldor.as.
But obviously the compilation in SPAD seems to ignore the fact that x is
to be compiled with the goal of getting type % and only *after* that is
achieve to turn the *result* into somthing of type T.
> I do not know if Aldor has user definable 'elt', if it has,
> then details of its handling may differ. Or maybe Aldor 'pretend'
> skips some steps of compilation of 'e'.
Well, the aldor equivalent of 'elt' is called 'apply', but basically
behaves like 'elt'. I.e. if the compiler sees a juxtaposition of s:S and
t:T and there is a function apply: (S, T) -> X in context and X fits to
resolve types then 'apply is thrown in.
I think the special case where S = T->X is treated differently in Aldor,
i.e. normal function application is preferred even in the presence of
apply: (T -> X, T) -> X
(Sorry, I havent tried that out.)
> If you define 'elt' you presumably want it to be used, so element of
> your domin behave like functions.
Yes, of course. But why does that mean that
(x@%) pretend S->S
needs to throw in that dummy argument?
What I would expect is, that x should be compiled to get type %. Then
that type is simply replaced by S->S and any value of x simply behaves
as if it were of type S->S (crashes welcome).
I'm probably to naive here since I don't understand the underlying
compilation technique.
> If you want an example which uses only 'basic' things the following
> may do:
>
> -------------------
>
> )abbrev domain MYPAIR MyPair
>
> MyPair(T : Type) : with
> ....
>
> -------------
I think the use of Record would be easier to understand than your lambda
abstraction example.
Maybe choosing function composition for an introduction to programming
in SPAD is not the best idea, but I wanted to choose something that is
not too that elegantly achieved in other programming languages.
I'll try to continue with my example. It's 'work in progress' and
newcomers will decide whether it's interesting and/or helpful.
Feedback is always welcome.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.
