>> 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?
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.
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.
Regards,
Bill Page.
-------------------------------------------------------------------------
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
