"Bill Page" <[EMAIL PROTECTED]> writes:
| On Thu, May 15, 2008 at 9:12 PM, Gabriel Dos Reis wrote:
| > ...
| > Bill Page writes:
| > ...
| > | )abbrev domain BBB Bbb
| > | Bbb: with
| > | foo: Integer -> Integer
| > | == add
| > | foo(a: Integer): Integer ==
| > | x:Union(Integer,Float)
| > | if a>0 then
| > | x := 1
| > | else
| > | x := 2.3
| > | x case Integer => (x*x)::Integer
| > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| >
| > Here, you are *manually inserting* the right coercion. This is
| > not the same thing you did in the interpreter case.
|
| That is true however I was not trying to claim that the interpreter
| and the compiler are the same.
Well, my understanding of your proposal was that in
if cond then
x := 1
else
x := 2.3
...
the compiler would assign type Integer to `x' in the `then' branch,
and type Float in the `else' branch, and type Union(Integer,Float) at
the meet point. And from there on, the compiler should figure out
things by itself (as the interpreter does, as you showed in your
messages). That, I think is not a minor modification. The reason is
that in the `then' branch, the `x' has a specific type that does not
require coercion to obtain its value, whereas from the meet point, the
compiler has to `go back' to `fix up' the type of `x', and figured out
what to do business afterward. Prompting the question from Ralf.
If your proposal is: well, just manually declare x of type Union
before the `if', then there is nothing new; we already have that in
current Spad (and that is not going to change). In fact, it is
completely orthogonal -- whether the `if'-branches have their own
scopes or not, that is going to work, just like it works today.
| I do not agree that I am "manually
| inserting" the right coercion. Based on your explain below, it is
| clear that I could/should have written:
|
| x case Integer => x*x
^^^^^^^^^^^^^^^^^^^^^^
This is what I call manual insertion of right coercion -- not just
the fact that you wrote `::Integer' at the end of `x*x'. Because
you're manually selecting which branch does what. See the explanation
of `autoCoerce'. In contrast to what you did with the interpreter.
| x*x
|
| I do not think this is the same as manually inserting a coercion, but
It is, because you're telling the compiler that `in this branch,
please use that coercion', whereas in the interpreter, you did not.
| I admit that it is helping the compiler a little more than one might
| like.
It is more than helping the compiler: You're telling it what to do;
unlike the interpreter.
| >This is precisely where I was commenting. So, ether you do the
| > same thing in the interpreter and the compiler or you compare
| > oranges to apples.
|
| Ok, forget about the interpreter. That was just an aside.
OK; a distracting aside :-)
|
| > If you're going to manually insert the right coercions, you may just
| > as well declare the variable explicitly as being a Union.
| >
|
| I was suggesting exactly that: If you want x to be known outside the
| scope if the 'if' statement then you should be forced to explicitly
| declare it as a Union - just like the case you described with the
| 'for' loop:
|
| x:Integer
| for i in 1..10 repeat
| x:=i
| x
OK, my understanding of your suggestion was different; see above.
But, if it is the case that the programmer -- not the compiler --
has to do the manual declaration as Union, and manual insertion of
coercion, I don't see anything wrong about it: It is what we are
doing today. My focus is elsewhere: What happens when there is no
declaration? I proposed: local scope, and that has been drawing
opposition.
[...]
| > Try:
| >
| > )abbrev package BILLPAGE BillPageUnion
| > BillPageUnion(): Public == Private where
| > Public ==> with
| > foo: () -> Void
| > Private ==> add
| > makeU(): Union(Integer,Float) ==
| > even? random()$Integer => 1
| > 3.14
| >
| > foo() ==
| > x: Union(Integer,Float) := makeU()
| > y: Union(Integer,Float) := makeU()
| > x ** y
| >
|
| Unlike the interpreter, I would not expect the compiler to be able to
| handle this without some help .
Well, this is essentially what Ralf pointed out. Maybe both of us
understood something different your proposal?
-- 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
