On 05/13/2008 12:47 PM, Gabriel Dos Reis wrote:
> On Tue, May 13, 2008 at 4:32 AM, Ralf Hemmecke <[EMAIL PROTECTED]> wrote:
>
>> If all this discussion, however is just to enforce the programmer to
>> create the variable j before the loop then I am all for it. But don't let
>>
>> j := 0
>>
>>
>> be different from
>>
>> j: Integer := 0
>>
>> if the compiler would be able to infer an appropriate type in the first
>
> In most cases, they are the same thing and no type annotation is required.
> If you read my original message, you'd notice that the only time they
> are different
> is when the second form is intended to `capture' a declaration in an
> enclosing scope.
If I have something like
j: Integer := 0
for i in 1..5 repeat
j: Integer := i2
output(j::OutputForm)$OutputPackage
that should not be allowed at all. Since it declares j twice in the same
scope (yes, you caught me with that "declaration" stuff).
As I understand you openaxiom now introduces a new scope for the for-body.
> In Aldor, you would use `free' to make that happens
Yes and no. No, because the for-body does not form a new scope. And yes
for new scopes, but then, of course, without the ": Integer" part.
-- Spad has no free. In
> OpenAxiom, you leave out the type annotation. Otherwise, in both
> Aldor (at least according to
> my reading of the specification) and OpenAxiom, the variable is local. If my
> understanding of the Aldor specification is incorrect, please slowly
> walk me through
Bill has already cited that part of Section 8.1 from the AUG:
These forms may be nested to any depth. Note that the last two bind
names in particular positions in the expression, and **do not form
general scope levels**.
Also the first sentence of Section 8.6 is in line with 8.1.
New variables are created by declaration statements (described below),
or implicitly by the first assignment to a variable inside a scope. In
the implicit case, the variable is lexical and local to the scope.
Something related...
In Aldor the following program does not need a "free" for the j even
though the function body introduces a new scope.
However, if you add "j:=1;" just before "stdout" that would make j local
according to the first sentence of Section 8.6. Unfortunately, I haven't
yet found that part of the AUG that says that the program below should
exactly behave as what the current Aldor compiler produces.
#include "aldor"
#include "aldorio"
import from Integer;
j: Integer := 2;
main(): () == {stdout << j << newline;}
main();
No output this time... ;-) Actually, it was not meant specifically for
you, but rather to save some time for the reader and to record in the
mailing list the current situation. I know that I cannot prove anything
along these lines by compiler output.
Ralf
-------------------------------------------------------------------------
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
