On Wed, 01 Oct 2008, Lorenzo Fiorini wrote:
Hi Lorenzo.
> > This is not compiler but PP issue. You will have to change
> > line concatenation character otherwise PP will make from
> > these 3 lines single lines which will be preprocessed and
> > then passed to compiler.
> > So you are asking to use some other character, f.e. '\' for
> > line concatenation.
> Sorry I was not clear enough.
You was and I perfectly understood what you need but I'm afraid
you do not understand my answer.
> I've mixed JavaScript/Eclipse issue with the syntax one.
> Let me rephrase it:
> why
> function test( a ) ; outstd( "Hello World" ) ; return nil
> is valid and
> function test( a ) ; <newline>
> outstd( "Hello World" ) ; <newline>
> return nil
> is not?
Because ';' is line concatenator in PP. Just look at .ppo file.
Prepocessor is before compiler and compiler does not know
anything about PP rules. It compiles only PP output.
If you do not like that PP concatenates lines using ';' then
we have to remove such functionality from PP. That's all.
What will happen with backward compatibility you can imagine.
> If in Harbour <newline> is the statement separator why couldn't it be
> ";<newline>" also?
Because PP has to join next lines in one sinlge line. Otherwise
PP rule will not work. F.e.;
? 1, ;
2
Wil not be translated because
? 1,
will be the 1-st line for PP and
2
will be the second one.
The preprocess code will look like:
QOut( 1, ) ;
2
> In this way I could add or not add a semicolon at the end of the
> statement but it'll be clear that semicolon is the statement separator
> that can be omitted if is followed by a <newline>.
But in Clipper and Harbour it has two meanings not only one.
It works as line concatenator when used at the and of line and
second meaing is command separator. You ask to disable the 1-st
functionality and left only the second one and yes it's enough.
Just simply comment few lines in PP which checks for ';' as trailing
character to use it as line concatenator. You cannot have at the same
time two different mutual exclusive behavior. Line concatenation with
semicolon stripping and not stripping.
> And if this will be implemented we need to change the
> HB_PP_MULTILINE_STRING separator which is now semicolon to a more
> common "\" backslash + <newline>.
We will have to change all source code which use ';' as line separator
because it will not longer work.
> > The only one reason Viktor replaced = with == in core code is
> > possible SET EXACT interaction. Otherwise it's perfectly valid
> > code. And even more. If you touch '=' operator behavior then
> > you will have to change also '<', '<=', '>', '>=' because you
> > should keep some general mathematical logic rules working, f.e.:
> > if a < b then !( a > b ) and !( a == b ) and !( a >= b )
> > if a >= b then !( a < b )
> > [...]
> What I meant is that today the are places where I HAVE to use ":="
> instead of "=".
Yes. But such places will still exists as long as we will have two
different equal operators. I do not think that people will agree to
remove one of them or change it to sth different because it will force
code rewriting. BTW many other languages also have := as assignment
operator.
> This confuses newbies developers that come from other languages since
> they don't understand where ":=" is required.
??? Do you want to say that they learned programming without studding even
some basic algorithms written in Pascal? I know that it's a time of "mouse"
programmers but I do not think that things are so bad ;-)
> IMHO it would be simpler to say that ":=" is the same as "=" and if
> you want to avoid ambiguities you have to use "==" for equal.
We cannot. We can only eliminate '=' as assignment and force ':=' usage.
'=' and '==' are two different operators used for different things and
we cannot remove existing widely used functionality. We will have to
introduce other operators as replacement. Farther we should <, <=, >, >=
to give results compatible with '=='. In practice it means full dropping
backward compatibility. At least I will not be able to use 99% of my code.
> > #xcommand VAR <vars,...> [ AS <type> ] => LOCAL <vars> [ AS <type> ]
> Thanks with these 3 lines:
> #xcommand { =>
> #xcommand } =>
> #xcommand VAR <vars,...> [ AS <type> ] => LOCAL <vars> [ AS <type> ]
> I've made happy my developers.
> BTW can I use #xcommand VAR also when hbclass.ch is used?
No, you will have exactly the same syntax for different things.
You will have to use some tricks based on current hbclass.ch rules, f.e.:
#xcommand VAR <vars,...> [ AS <type> ] => ;
VAR <vars> [ AS <type> ] _CLASS_MODE_
#xcommand VAR <vars,...> [ AS <type> ] _CLASS_DECLARATION_ => ;
DATA <vars> [ AS <type> ]
#xcommand VAR <vars,...> [ AS <type> ] _CLASS_IMPLEMENTATION_ => ;
LOCAL <vars> [ AS <type> ]
It should work as you want but these rules have to be added after
#include "hbclass.ch". Otherwise the hbclass.ch rules will have higher
priority.
#xcommand } =>
May interact with extended codeblocks. F.e.:
cb:={||
? "EXT BLOKCK"
return NIL
}
If you use them then use parenthesis to eliminate translation, f.e.:
cb:= ( {||
? "EXT BLOKCK"
return NIL
} )
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
