> gives effect which is hard to do in Aldor way.
Not in this case. One simply has to add "return".
bar(x: Boolean, y: Boolean): String ==
str: String := "init"
if x then
y => return (str := "TT")
str := "moo" + str
str
> More precisely, Aldor has 'goto' which solves this and more general
> problems. But ATM Spad has no 'goto', so it is hard to get the same
> effect with Aldor semantics.
I actually don't understand why SPAD has a meaning for
(a; b; x => c; d) (1)
and a meaning for
(a; b; if u then (r; x => c; d; e); f) (2)
AFAIU, in your last mail you explained that in both cases the outer
block is left with value c.
> We can change Spad to match Aldor. However, the remark above shows
> that to gain regularity we loose some expressive power.
Either I don't understand the SPAD semantics or if it is really as I
describe it above then I find that irregular (i.e. the meaning of =>
depending on an if-context) and I would strongly prefer the Aldor
semantics, i.e. (2) is equivalent to
(a; b; if u then (r; if x then c else (d; e)); f)
i.e. (2) ends with value f.
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/d/optout.
