Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Stranger compiler error?

Reply
Thread Tools

Stranger compiler error?

 
 
Red Orchid
Guest
Posts: n/a
 
      11-11-2006
Patricia Shanahan <(E-Mail Removed)> wrote or quoted in
Message-ID: <t755h.4869$(E-Mail Removed). net>:

>
> Knute Johnson wrote:
> ...
> > for (Enumeration<Integer> e=hash.keys(); e.hasMoreElements()
> > String[] array = hash.get(e.nextElement()); // <---- error

> ...
>
> You are confusing two very different entities, a statement and a
> variable declaration.
>
> The for MUST be followed by a statement.
>
> You have a local variable declaration, which is not itself a statement
> but can appear in a compound statement, such as a brace-enclosed block.
>
> Incidentally, it seems a bit pointless because you assign to array and
> then immediately leave its scope of declaration.
>




#0: "for ( ... ) a declaration statement;"

For a moment, let's consider the above '#0' not to be an error.
Now,
Let's take all possible cases into account.

Case 1)
#1_e:
for (...) int i = 0;

#1_c:
for (...) { int i = 0; }


Both '#1_e' and '#1_c' are useless because 'i' is never
read and '0' is constant.


Case 2)
#2_e:
for (...) int i = parse(...);

#2_c:
for (...) { int i = parse(...); }


Both '#2_e' and '#2_c' are not useless because 'parse(...)'
can change the state of some instances (ex: fields).


Case 3)
#3_e:
for (...) parse(...);

#3_c:
for (...) { parse(...); }

Both '#3_e' and '#3_c' are not useless.


From this point of view, '#*_e' are equivalent to '#*_c' .
But,
'#*_e' are errors and '#*_c' do not.

Is it valid that '#*_c' do not be errors ?
If so, what is the advantage of it ?


"Type name = ... ;" is composed of more than one statements
like a brace-enclosed block.

I think that it is unartificial that a compiler give warnings
about '#*_e', not errors.



 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      11-11-2006
Patricia Shanahan <(E-Mail Removed)> writes:
>ASCII does not work well for some of this, because it lacks
>distinct fonts.


I assume that your intention was not to refer to the encoding
of ASCII but to the format "plain text", which does not allow
markup.

ASCII is an encoding for the ASCII character set.
Your post was encoded in ISO-8859-1, but you are free to
choose UTF-8. Still, you would not have "distinct fonts",
because it still would be "plain text".

>Section 14.5 Statements lists all the productions for the
>syntax element Statement. It does not include the syntax
>element LocalVariableDeclarationStatement.


I like to have this semantic distinction:
A /declaration/ has its effect at compile time,
while a /statement/ has its effect at run time.
Naming a declaration a "statement" would blur this distinction.

 
Reply With Quote
 
 
 
 
Patricia Shanahan
Guest
Posts: n/a
 
      11-11-2006
Stefan Ram wrote:
> Patricia Shanahan <(E-Mail Removed)> writes:
>> ASCII does not work well for some of this, because it lacks
>> distinct fonts.

>
> I assume that your intention was not to refer to the encoding
> of ASCII but to the format "plain text", which does not allow
> markup.
>
> ASCII is an encoding for the ASCII character set.
> Your post was encoded in ISO-8859-1, but you are free to
> choose UTF-8. Still, you would not have "distinct fonts",
> because it still would be "plain text".


Correct.

>
>> Section 14.5 Statements lists all the productions for the
>> syntax element Statement. It does not include the syntax
>> element LocalVariableDeclarationStatement.

>
> I like to have this semantic distinction:
> A /declaration/ has its effect at compile time,
> while a /statement/ has its effect at run time.
> Naming a declaration a "statement" would blur this distinction.
>


The distinction is inherently blurred in Java because of initializers.

An initializer has many of the characteristics of an executable
statement. It has to be given a place in the execution sequence, to
define the values of variables it uses and which computations are
affected by its side effects.

Patricia
 
Reply With Quote
 
Knute Johnson
Guest
Posts: n/a
 
      11-11-2006
Patricia Shanahan wrote:
> Knute Johnson wrote:
>> Patricia Shanahan wrote:
>>> Knute Johnson wrote:
>>> ...
>>>> for (Enumeration<Integer> e=hash.keys(); e.hasMoreElements()
>>>> String[] array = hash.get(e.nextElement()); // <---- error
>>> ...
>>>
>>> You are confusing two very different entities, a statement and a
>>> variable declaration.
>>>
>>> The for MUST be followed by a statement.
>>>
>>> You have a local variable declaration, which is not itself a statement
>>> but can appear in a compound statement, such as a brace-enclosed block.

>>
>> I understand the issue here I just can't find in the JLS where it is
>> not a statement. In fact, JLS 14.4.4 Execution of Local Variable
>> Declarations "A local variable declaration statement is an executable
>> statement.", would seem to say otherwise.

>
> ASCII does not work well for some of this, because it lacks distinct
> fonts. Also I should have capitalized "Statement". I meant the syntax
> element "Statement", not the English word "statement".
>
> Section 14.5 Statements lists all the productions for the syntax element
> Statement. It does not include the syntax element
> LocalVariableDeclarationStatement.
>
> The production:
>
> IfThenStatement:
> if ( Expression ) Statement
>
> definitely requires a syntax element Statement.
>
> Patricia


Patricia:

So do you think this was an arbitrary distinction or is there some
reason that a LocalVariableDeclarationStatement had to be immediately
contained by a block (read that braces). Is it because of the
possibility of multiple execution within the containing block of a 'for'
or other loop?

I found this by accident debugging some code. It would probably never
come up in normal usage. I do find I learn a lot about the subtleties
of the language though when you answer my questions.

Thanks,

--

Knute Johnson
email s/nospam/knute/
 
Reply With Quote
 
Patricia Shanahan
Guest
Posts: n/a
 
      11-12-2006
Knute Johnson wrote:
....
> So do you think this was an arbitrary distinction or is there some
> reason that a LocalVariableDeclarationStatement had to be immediately
> contained by a block (read that braces). Is it because of the
> possibility of multiple execution within the containing block of a 'for'
> or other loop?

....

No, I think it may be because of the sheer logic of what a declaration is.

My first thought was something like "Well, they could act as though
every statement were in braces of its own, so it can function as block",
but that does not work for declarations:

{
int a = 3;
System.out.println(a);
}

is different from:

{
{int a = 3;}
{System.out.println(a);}
}

The language can't get away with wrapping implicit blocks around
declarations. They have to be written by the programmer, or there is a
risk of messing up scope.

Also, there is a human factors issue. A declaration by itself after an
"if" is at least as likely to be due to missing braces, and the first
line of a longer block, than to be intentional.

Patricia
 
Reply With Quote
 
Knute Johnson
Guest
Posts: n/a
 
      11-12-2006
Patricia Shanahan wrote:
> Knute Johnson wrote:
> ...
>> So do you think this was an arbitrary distinction or is there some
>> reason that a LocalVariableDeclarationStatement had to be immediately
>> contained by a block (read that braces). Is it because of the
>> possibility of multiple execution within the containing block of a
>> 'for' or other loop?

> ...
>
> No, I think it may be because of the sheer logic of what a declaration is.
>
> My first thought was something like "Well, they could act as though
> every statement were in braces of its own, so it can function as block",
> but that does not work for declarations:
>
> {
> int a = 3;
> System.out.println(a);
> }
>
> is different from:
>
> {
> {int a = 3;}
> {System.out.println(a);}
> }
>
> The language can't get away with wrapping implicit blocks around
> declarations. They have to be written by the programmer, or there is a
> risk of messing up scope.
>
> Also, there is a human factors issue. A declaration by itself after an
> "if" is at least as likely to be due to missing braces, and the first
> line of a longer block, than to be intentional.
>
> Patricia


Thanks Patricia.

--

Knute Johnson
email s/nospam/knute/
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-12-2006
Red Orchid wrote:
> Patricia Shanahan <(E-Mail Removed)> wrote or quoted in
> Message-ID: <t755h.4869$(E-Mail Removed). net>:
>
>> Knute Johnson wrote:
>> ...
>>> for (Enumeration<Integer> e=hash.keys(); e.hasMoreElements()
>>> String[] array = hash.get(e.nextElement()); // <---- error

>> ...
>>
>> You are confusing two very different entities, a statement and a
>> variable declaration.
>>
>> The for MUST be followed by a statement.
>>
>> You have a local variable declaration, which is not itself a statement
>> but can appear in a compound statement, such as a brace-enclosed block.
>>
>> Incidentally, it seems a bit pointless because you assign to array and
>> then immediately leave its scope of declaration.
>>

>
>
>
> #0: "for ( ... ) a declaration statement;"
>
> For a moment, let's consider the above '#0' not to be an error.
> Now,
> Let's take all possible cases into account.
>
> Case 1)
> #1_e:
> for (...) int i = 0;
>
> #1_c:
> for (...) { int i = 0; }
>
>
> Both '#1_e' and '#1_c' are useless because 'i' is never
> read and '0' is constant.
>
>
> Case 2)
> #2_e:
> for (...) int i = parse(...);
>
> #2_c:
> for (...) { int i = parse(...); }
>
>
> Both '#2_e' and '#2_c' are not useless because 'parse(...)'
> can change the state of some instances (ex: fields).
>
>
> Case 3)
> #3_e:
> for (...) parse(...);
>
> #3_c:
> for (...) { parse(...); }
>
> Both '#3_e' and '#3_c' are not useless.
>
>
> From this point of view, '#*_e' are equivalent to '#*_c' .
> But,
> '#*_e' are errors and '#*_c' do not.
>
> Is it valid that '#*_c' do not be errors ?
> If so, what is the advantage of it ?
>
>
> "Type name = ... ;" is composed of more than one statements
> like a brace-enclosed block.
>
> I think that it is unartificial that a compiler give warnings
> about '#*_e', not errors.


The Java(tm) language is what it is and it ain't what it ain't.

- Lew
 
Reply With Quote
 
Patricia Shanahan
Guest
Posts: n/a
 
      11-13-2006
Red Orchid wrote:
....
> Case 2)
> #2_e:
> for (...) int i = parse(...);
>
> #2_c:
> for (...) { int i = parse(...); }
>
>
> Both '#2_e' and '#2_c' are not useless because 'parse(...)'
> can change the state of some instances (ex: fields).


However, making them variable declarations rather than expression
statements is useless. All side effects of 'parse(...)' happen for

for (...)
parse(...);

Patricia
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
New releases: Lost S3, Perfect Stranger & Veronica Mars: Updated complete downloadable R1 DVD DB & inof lists Doug MacLean DVD Video 6 06-15-2007 07:02 AM
Orson Welles The Stranger...any good transfers? DVD Video 1 01-20-2007 01:35 AM
DVD Verdict reviews: THE RINGER, WHEN A STRANGER CALLS (2006), and more! DVD Verdict DVD Video 0 05-16-2006 09:11 AM
HELP!!! What's the best version of Welles's The Stranger Edward Holub DVD Video 0 08-17-2005 02:18 AM
me again, even stranger problem. MajBach Computer Support 3 03-28-2005 04:45 PM



Advertisments