"Bill Page" <[EMAIL PROTECTED]> writes: | >> Bill Page wrote: | >> | Wouldn't it be enough to treat 'f' in this context as a constant | >> | unrelated to the parameter 'f'? | >> | > On Wed, Aug 6, 2008 at 8:09 AM, Gabriel Dos Reis wrote: | >> Why should the 'f' in signature declaration in | >> | >> MyCat(f:Symbol):Category == with | >> f:X->Y | >> | >> be unrelated to the f in the parameter list? | >> | >> | Or do you think that this is just an accident of the design of the | >> compiler? | >> | >> I don't have enough evidence to select `accident' over `logical | >> consequence of the design'. | > | | On Sun, Aug 10, 2008 at 7:15 AM, Gabriel Dos Reis wrote: | | > Now, I have enough information to conclude that the compiler's | > behavior and the interpreter behavior are *contradictory*. The following | > function will always return the integer 1, no matter the value of input | > integer: | > | > f(a: Integer): Integer == | > a: Float := 1.0 | > | > As someone who like proper scoping discipline, given the choice | > between the interpreter behavior and the compiler behavior, I'll chose | > the interpreter behavior. Given free hands, I'll make both invalid. | > | | I do not prefer what the interpreter does. I think that when compiling | this function the interpreter is even consistent with itself. For | example, a sequence of operations like this is not allowed in the | interpreter: | | (3) -> b:Integer:=1 | | (3) 1 | Type: Integer | (4) -> b:Float:=2 | | You cannot declare b to be of type Float because either the declared | type of b or the type of the value of b is different from Float . | | But the following function compiles without any error: | | f(a:Integer):Integer == | b:Integer:=1 | b:Float:=2 | b | Whether 'b' is a local variable or if it is passed as a parameter like | 'a', should not matter. In either case the first declaration is | silently ignored. This is just wrong, no?
My view on scoping is that b:Integer:=1 b:Float:=2 in the same scope should be an error. | The original question concerned the status of the exports in the | 'with' clause. You previously seemed to be arguing that in this | context | | f:A->B | | is an expression, all parts of which are subject to evaluation. This | still makes a certain kind of sense to me. I would like to get the record straight: Previously, I was not arguing for one position or another. I was merely explaining why you were seeing the behaviour you were seeing -- which was the main question you asked. When you pressed me to take position, I said I did not have enough information -- which was true. Now I do, which is why I sent the message you were replying to. | If we wanted a similar kind of evaluation to take place in the body of | a function, then I think it is necessary to distinguish at least two | kinds of evaluation. Evaluation to the left of the ':' would be have | to be something like "evaluate to name" while to the right it would be | evaluate to value. Given this we might have expected | | (1) -> f(a:Symbol):Integer == (b:Integer:=1;a:Float:=2;b) | Function declaration f : Symbol -> Integer has been added to | workspace. | Type: Void | (2) -> f(a) | Compiling function f with type Symbol -> Integer | | (2) 1 | Type: PositiveInteger | (3) -> f(b) | | (3) 1 | Type: PositiveInteger | | ---- | | to return 2 for f(b). But I am not sure that such a thing would make | sense in the context of a statically typed language. If I read the function definition correctly, `b' is the last expression in the body. I do not understand why the function would be expected to return `2' for f(b). -- Gaby ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
