On Tue, May 13, 2008 at 6:40 AM, Ralf Hemmecke <[EMAIL PROTECTED]> wrote:
> 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.
Why?
> Since it declares j twice in the same
> scope (yes, you caught me with that "declaration" stuff).
But, why do you think they are the same scope?
>
> As I understand you openaxiom now introduces a new scope for the for-body.
A loop body, where explicit for or a collect or a reduce implicitly
introduces a scope to shield local computations from enclosing scope.
> > 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.
My opinion is that is unfortunate for Aldor. In loops, I do local
computations and I don't want to see local declarations unnecessarily
pollute the enclosing scope (apparently some algebra code made similar
assumptions).
>
>
> -- 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),
and you asserted earlier that there is variable declaration in Aldor.
Which is which?
> 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.
yes, the same is true in OpenAxiom.
>
> However, if you add "j:=1;" just before "stdout" that would make j local
That would still refer to the 'j' in enclosing scope - in all flavours of AXIOM.
> 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.
That is why I'm looking at the specification. :-)
>
> #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
>
-- 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