"Bill Page" <[EMAIL PROTECTED]> writes:

| On Wed, May 14, 2008 at 10:53 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke writes:
| > ...
| > | The code can also be made legal by changing the definition of
| > | halfExtendedSubResultantGcd1 and halfExtendedSubResultantGcd2
| > | to return something of type
| > |
| > |    Record (gcd: P, coef: P)
| > |
| > | No "1" or "2" in the tag of the second field. *That* is an artificial
| > | complication that is completely unnecessary.
| >
| > Yes, yes, yes.  That would solve this *particular issue*.
| > I'm concerned with the _pattern_.
| > ...
| 
| So to summarize, the pattern is something like this:
| 
|     if cond then
|         x := 1
|     else
|         x := 2.3
|     ...
| 
| If this is allowed by the compiler, the question is what is the type
| of 'x' outside the scope of the 'then' and 'else' clauses?

Yes.

| One answer is to introduce only local scope so that the variable x
| does not exist outside the scope.
| 
| If the scope of 'x' is intended to be global, then the type of 'x'
| must be a Union.

Union is one possiblity, another is a `real' overload.

| 
|     x:Union(Integer,Float)
|     if cond then
|         x := 1
|     else
|         x := 2.3
| 
| I do not see anything wrong with this proposal. It is compatible with
| only a minor change to the existing library code

I'm not sure the change is minor:  Union in Spad are different from
unions in C, in the sense that unions in Spad are tagged, which means
the the value representation of x is very different from that of
Integer or Float, and the compiler has to insert the right coercions
at the right places.  One would have to assess whether codes are
generated correctly (the `scary' part of the compiler).

| - just like the other
| scope change in OpenAxiom recently discussed by Gaby. For example one
| can write:
| 
|         hesrg:Union(c1:Record (gcd : P, coef1 : P), c2:Record (gcd :
| P, coef2 : P))
|         if mdeg(p) < mdeg(ts_v)
|           then
|             hesrg := halfExtendedSubResultantGcd2(ts_v,p)$P
|             d: P :=  hesrg.c2.gcd; n: P := hesrg.c2.coef2
|           else
|             hesrg := halfExtendedSubResultantGcd1(p,ts_v)$P
|             d: P :=  hesrg.c1.gcd; n: P := hesrg.c1.coef1
|         g := gcd(n,d)
| 
| But of course this makes it even more clear that this segment of code
| has a rather poor style and introduces this Union for on particularly
| good purpose. As others have pointed out, it should be re-factored.

The halfExtendedSubResultantGcd2 and halfExtendedSubResultantGcd1
functions are unfortunate, no question about that.

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

Reply via email to