Martin Rubey <[EMAIL PROTECTED]> writes:
[...]
| By the way, how will this work in the interpreter? I.e., do you think it
makes
| sense to force a rewrite of the currently legal
|
| f x == (if zero? x then z := 0 else z := 1/x; g z)
|
| to
|
| f x == (z := if zero? x then 0 else 1/x; g z)
Which is equivalent to
f x ==
z := zero? x => 0
1/x
g z
Quite idiomatic in Spad, I would say.
| I'm *not* saying that the first form is better, but I doubt that one of the
two
| is *always* better. However, the first form becomes illegal SPAD and
| interpreted language is to be (as far as possible) identical.
Are you speaking for OpenAxiom case or FriCAS case?
[...]
| want to make a difference there. (I admit I didn't think through why variable
| overloading is forbidden in Aldor, but so far I didn't need that anyway).
Yeah, habit tends to trump many things.
| Note that one of the most fundamental reasons why the species (AKA combinat)
| project doesn't work well with panAxiom / SPAD, is that functions are treated
| specially in panAxiom / SPAD.
|
| If you can come up with a SPAD-compatible replacement for the construct
|
| SPECIES == (L: LabelType) -> CombinatorialSpecies L;
| Plus(
| F: SPECIES,
| G: SPECIES
| )(L: LabelType): CombinatorialSpecies(L) == add [...]
|
| you shall be praised and I'll stop talking about language semantics from now
on
| and refer to you instead.
It would be an even better deal if you also included not telling
people to implement a copy of Aldor, which is a freely available
compiler :-)
-- Gaby
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
