Hello,
here is a screen session: " octave:1> for ii=1:1 ii endfor disp(ii) parse error: syntax error >>> for ii=1:1 ii endfor disp(ii) ^ octave:1> for ii=1:1 ii endfor;disp(ii) ii = 1 1 octave:2> ". Why is it so 'octave' doesn't accept the first variant ? With "traditional" 'endfor' on a new line semicolon isn't needed ? Is there any reason for newline whitespace to be treated differently than space whitespace ? Thanks, Sergei. _______________________________________________ Helpoctave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/helpoctave 
Administrator

On Aug 16, 2011, at 7:25 AM, Sergei Steshenko wrote:
> Hello, > > here is a screen session: > " > octave:1> for ii=1:1 ii endfor disp(ii) > parse error: > > syntax error > >>>> for ii=1:1 ii endfor disp(ii) > ^ > > octave:1> for ii=1:1 ii endfor;disp(ii) > ii = 1 > 1 > octave:2> > ". > > Why is it so 'octave' doesn't accept the first variant ? > > With "traditional" 'endfor' on a new line semicolon isn't needed ? > Is there any reason for newline whitespace to be treated differently than space whitespace ? > > Thanks, > Sergei. The parser treats keywords and functions differently. I am not familiar with the parser implementation, so I can't give a better explanation. To see what Octave's keywords are, you can use the undocumented function __keywords__. To see what functions are in the path, use __list_functions__. There are builtin function as well. To see those use __builtins__. Ben _______________________________________________ Helpoctave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/helpoctave 
 On Tue, 8/16/11, Ben Abbott <[hidden email]> wrote: > From: Ben Abbott <[hidden email]> > Subject: Re: space vs semicolon  why syntax error with the former ? (octave3.4.2) > To: "Sergei Steshenko" <[hidden email]> > Cc: [hidden email] > Date: Tuesday, August 16, 2011, 4:55 AM > On Aug 16, 2011, at 7:25 AM, Sergei > Steshenko wrote: > > > Hello, > > > > here is a screen session: > > " > > octave:1> for ii=1:1 ii endfor disp(ii) > > parse error: > > > > syntax error > > > >>>> for ii=1:1 ii endfor disp(ii) > > > ^ > > > > octave:1> for ii=1:1 ii endfor;disp(ii) > > ii = 1 > > 1 > > octave:2> > > ". > > > > Why is it so 'octave' doesn't accept the first variant > ? > > > > With "traditional" 'endfor' on a new line semicolon > isn't needed ? > > Is there any reason for newline whitespace to be > treated differently than space whitespace ? > > > > Thanks, > > Sergei. > > The parser treats keywords and functions differently. > > I am not familiar with the parser implementation, so I > can't give a better explanation. To see what Octave's > keywords are, you can use the undocumented function > __keywords__. > > To see what functions are in the path, use > __list_functions__. There are builtin function as > well. To see those use __builtins__. > > Ben > > I do not grasp your reply. My point is that in "normal" languages all whitespaces are created equal. So, since the following works: " octave:1> for ii = 1:1 > ii > endfor ii = 1 octave:2> disp(ii); 1 octave:3> " , and in this case 'endfor' is separated from 'disp' by newline, I also expect " octave:3> for ii = 1:1 ii endfor disp(ii); parse error: syntax error >>> for ii = 1:1 ii endfor disp(ii); ^ octave:3> ", to work (because newline and space both look like created equal whitespaces to me), but it doesn't. Thanks, Sergei. _______________________________________________ Helpoctave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/helpoctave 
Administrator

On Aug 16, 2011, at 8:03 AM, Sergei Steshenko wrote: > > >  On Tue, 8/16/11, Ben Abbott <[hidden email]> wrote: > >> From: Ben Abbott <[hidden email]> >> Subject: Re: space vs semicolon  why syntax error with the former ? (octave3.4.2) >> To: "Sergei Steshenko" <[hidden email]> >> Cc: [hidden email] >> Date: Tuesday, August 16, 2011, 4:55 AM >> On Aug 16, 2011, at 7:25 AM, Sergei >> Steshenko wrote: >> >>> Hello, >>> >>> here is a screen session: >>> " >>> octave:1> for ii=1:1 ii endfor disp(ii) >>> parse error: >>> >>> syntax error >>> >>>>>> for ii=1:1 ii endfor disp(ii) >>> >> ^ >>> >>> octave:1> for ii=1:1 ii endfor;disp(ii) >>> ii = 1 >>> 1 >>> octave:2> >>> ". >>> >>> Why is it so 'octave' doesn't accept the first variant >> ? >>> >>> With "traditional" 'endfor' on a new line semicolon >> isn't needed ? >>> Is there any reason for newline whitespace to be >> treated differently than space whitespace ? >>> >>> Thanks, >>> Sergei. >> >> The parser treats keywords and functions differently. >> >> I am not familiar with the parser implementation, so I >> can't give a better explanation. To see what Octave's >> keywords are, you can use the undocumented function >> __keywords__. >> >> To see what functions are in the path, use >> __list_functions__. There are builtin function as >> well. To see those use __builtins__. >> >> Ben > > I do not grasp your reply. My point is that in "normal" languages all > whitespaces are created equal. So, since the following works: > > " > octave:1> for ii = 1:1 >> ii >> endfor > ii = 1 > octave:2> disp(ii); > 1 > octave:3> > " > > , and in this case 'endfor' is separated from 'disp' by newline, I also > expect > > " > octave:3> for ii = 1:1 ii endfor disp(ii); > parse error: > > syntax error > >>>> for ii = 1:1 ii endfor disp(ii); > ^ > octave:3> > ", > > to work (because newline and space both look like created equal whitespaces to me), but it doesn't. > > Thanks, > Sergei. As I said, I am not familiar with the parser. What I did notice is that the parser is treating keywords differently than functions. I am also aware of a feature of both Matlab and Octave that means all space are not equal. Consider that each of the commands below are valid syntax. disp("Hello World") ... and ... disp ("Hello World") ... and ... disp "Hello World" Also consider that each of the commands below are also valid syntax ("Hello World") "Hello World" In Octave/Matlab spaces are not equal. Back to your example, there is more than one interpretation of ... for ii = 1:1 ii endfor disp ii ; Ben _______________________________________________ Helpoctave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/helpoctave 
In reply to this post by Sergei Steshenko
A newline is the end of a statement. If you want to end statements in
the same line, you use semicolons or commas. You always use semicolons if you want to end a statement and not echo its result and commas if you don't. Octave is hardly the only language that works this way; bash comes to mind as another language where you need to write, e.g. for i in *; do foo $i; done; echo "done" and if you miss the semicolon after done, it's a syntax error in bash, similar to Octave. HTH,  Jordi G. H. _______________________________________________ Helpoctave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/helpoctave 
In reply to this post by bpabbott
 On Tue, 8/16/11, Ben Abbott <[hidden email]> wrote: > From: Ben Abbott <[hidden email]> > Subject: Re: space vs semicolon  why syntax error with the former ? (octave3.4.2) > To: "Sergei Steshenko" <[hidden email]> > Cc: [hidden email] > Date: Tuesday, August 16, 2011, 5:24 AM > Back to your example, there is more than one interpretation > of ... > > for ii = 1:1 ii endfor disp ii ; > > Ben > 'endfor' "balances" 'for', i.e. the parser may forget _completely_ (except for input text pointer position) about the whole 'for' loop, and after that parse the 'disp' (in this case) part. I.e. I still don't see how different interpretation can be present in this case  to me it looks like the 'for' loop statement is unambiguously over, and no special separator (e.g. ';') is necessary  simply because of 'endfor' detection. Regards, Sergei. _______________________________________________ Helpoctave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/helpoctave 
Sorry, but taking your reasoning literally is bogus: let's consider if (0>1) disp('Problem'); end; disp(36) if you take for granted that the 'end' close the expression, then then previous line should be equivalent to ; disp(36) which is a syntactically incorrect. Regards Pascal 
 On Tue, 8/16/11, CdeMills <[hidden email]> wrote: > From: CdeMills <[hidden email]> > Subject: Re: space vs semicolon  why syntax error with the former ? (octave3.4.2) > To: [hidden email] > Date: Tuesday, August 16, 2011, 10:03 AM > > Sergei Steshenko2 wrote: > > > >  On Tue, 8/16/11, Ben Abbott <[hidden email]> > wrote: > > > > > >> Back to your example, there is more than one > interpretation > >> of ... > >> > >> for ii = 1:1 ii endfor disp ii ; > >> > >> Ben > >> > > > > 'endfor' "balances" 'for', i.e. the parser may forget > _completely_ (except > > for input text pointer position) about the whole 'for' > loop, and after > > that parse the 'disp' (in this case) part. > > > > I.e. I still don't see how different interpretation > can be present in > > this case  to me it looks like the 'for' loop > statement is unambiguously > > over, and no special separator (e.g. ';') is necessary >  simply > > because of 'endfor' detection. > > > > > > Sorry, but taking your reasoning literally is bogus: let's > consider > if (0>1) disp('Problem'); end; disp(36) > if you take for granted that the 'end' close the > expression, then then > previous line should be equivalent to > ; disp(36) > which is a syntactically incorrect. > > Regards > > Pascal > >  > View this message in context: http://octave.1599824.n4.nabble.com/spacevssemicolonwhysyntaxerrorwiththeformeroctave342tp3746937p3747777.html > Sent from the Octave  General mailing list archive at > Nabble.com. And why should it be syntactically incorrect in the first place ? E.g.: " sergei@amdam2:~/junk> perl e ';print "36\n"' 36 sergei@amdam2:~/junk> ". Or: " sergei@amdam2:~/junk/semicolon_in_c> cat n main.c 1 #include <stdio.h> 2 3 int main() 4 { 5 ;printf("%u\n", 36u); 6 return 0; 7 } sergei@amdam2:~/junk/semicolon_in_c> ~/AFSWD/install/gcc4.4.6/binsh/gcc Wall Wextra main.c sergei@amdam2:~/junk/semicolon_in_c> ./a.out 36 sergei@amdam2:~/junk/semicolon_in_c> ". Normal languages do not care about semicolon before a function call. Regards, Sergei. _______________________________________________ Helpoctave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/helpoctave 
On 08/16/2011 01:52 PM, Sergei Steshenko wrote:
> this case  to me it looks like the 'for' loop > statement is unambiguously > over, and no special separator (e.g. ';') is necessary >  On Tue, 8/16/11, CdeMills<[hidden email]> wrote: >> Sorry, but taking your reasoning literally is bogus: let's >> consider >> if (0>1) disp('Problem'); end; disp(36) >> if you take for granted that the 'end' close the >> expression, then then >> previous line should be equivalent to >> ; disp(36) >> which is a syntactically incorrect. > Normal languages do not care about semicolon before a function call. There is no such thing as a 'normal language' in this respect. Look up the debate that raged in the nineties on whether semicolon should be a separator or a terminator. One doesn't have to look far, this is covered in Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28syntax%29 There are arguments for either style, and the debate ended in a tieit appears that the score among the languages listed in the Wikipedia article is 24:21. Matlab happens to be one of the few languages with both a primary (newline) and secondary (';,') separatorprobably to make it easier for command line coding; they also overloaded the semicolon to control output silencing. It is what it is, let's get on with it :) _______________________________________________ Helpoctave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/helpoctave 
 On Tue, 8/16/11, Przemek Klosowski <[hidden email]> wrote: > From: Przemek Klosowski <[hidden email]> > Subject: Re: space vs semicolon  why syntax error with the former ? (octave3.4.2) > To: [hidden email] > Date: Tuesday, August 16, 2011, 11:33 AM > On 08/16/2011 01:52 PM, Sergei > Steshenko wrote: > > this case  to me it looks like the 'for' loop > > statement is unambiguously > > over, and no special separator (e.g. ';') is > necessary > > >  On Tue, 8/16/11, CdeMills<[hidden email]> > wrote: > >> Sorry, but taking your reasoning literally is > bogus: let's > >> consider > >> if (0>1) disp('Problem'); end; > disp(36) > >> if you take for granted that the 'end' close the > >> expression, then then > >> previous line should be equivalent to > >> ; disp(36) > >> which is a syntactically incorrect. > > > Normal languages do not care about semicolon before a > function call. > > There is no such thing as a 'normal language' in this > respect. Look up the debate that raged in the nineties on > whether semicolon should be a separator or a terminator. One > doesn't have to look far, this is covered in Wikipedia: > > http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28syntax%29 > > There are arguments for either style, and the debate ended > in a tieit appears that the score among the languages > listed in the Wikipedia article is 24:21. > > Matlab happens to be one of the few languages with both a > primary (newline) and secondary (';,') separatorprobably > to make it easier for command line coding; they also > overloaded the semicolon to control output silencing. It is > what it is, let's get on with it :) > > _______________________________________________ > Helpoctave mailing list > [hidden email] > https://mailman.cae.wisc.edu/listinfo/helpoctave > I am widening my question: why comma is more acceptable than space too: " octave:1> for ii = 1:1 ii endfor,disp(ii); ii = 1 1 octave:2> " ? I still want to see a _logical_ argument about unacceptability of space in this case. I reiterate my point: as soon as 'endfunction' is detected, it doesn't matter that the loop has been found from the point of view of parser. To me insistence on semicolon or comma or newline and unacceptability of space (and tab) is an unnecessary nuisance. Computer languages are formal ones compared to human languages  in order to achieve disambiguation. I do not see an ambiguity in such a case in the first place  end of 'for' statement is easily detected by parsing 'endfor' keyword. Thanks, Sergei. _______________________________________________ Helpoctave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/helpoctave 
On 16 August 2011 17:13, Sergei Steshenko <[hidden email]> wrote:
> I am widening my question: why comma is more acceptable than space too: > > " > octave:1> for ii = 1:1 ii endfor,disp(ii); > ii = 1 > 1 > octave:2> > " > ? > > I still want to see a _logical_ argument about unacceptability of space > in this case. Languages have syntax. If you prefer to not have the least syntax possible, use lisp. Btw, Perl, which you seem to think of as a normal language, has the weird quirk that if($foo) do_bar(); is a syntax error and instead you need if($foo) {do_bar();} for no good reason. C and C++ don't need the extra braces, but Perl does (Perl also needs a lot of other unnecessary things, like making the user spell out explicitly if something is a reference or a value). Python has whitespace. C++ has templates. Octave has semicolons. Facts of life. If you want to make Octave a normal language, patches are probably welcome: http://hg.savannah.gnu.org/hgweb/octave/file/b80b18f537ca/src/octparse.yy  Jordi G. H. _______________________________________________ Helpoctave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/helpoctave 
In reply to this post by Sergei Steshenko
1) there is no such thing as a newline whitespace. It's a newline terminator. 2) some keywords stop the parsing of the _previous_ expression: else, end, ... 3) the logic is that, if you require to pack on one line: a = 3 b = 2 you have the choice between a = 3; b = 2 or a = 3, b = 2 This way, to pack if (1> 0) c=3 else d=4 end a = 3 You need either if (1> 0) c=3 else d=4 end, a = 3 or if (1> 0) c=3 else d=4 end; a = 3 My interpretation is that ';,' used as secondary separator must come where the primary separator (newline) is expected. Quite franckly, I expect to make some keywords (end, endfor, ...) become separators of their own to be disruptive, leading to subtle and hard to track problems. Regards Pascal 
Powered by Nabble  Edit this page 