On Wed, 01 Oct 2008, Lorenzo Fiorini wrote:
Hi Lorenzo,
> JavaScript is a widely used and known language and I've found that
> with few changes an Harbour source can be "digested" by IDEs like
> Eclipse or NetBeans as a JavaScript source and that these changes can
> also "fix" some "ambiguities" of the actual language.
> Moreover I think this "alternative" syntax would increase the
> acceptance of Harbour to new developers that use C, C++, C#, Php, etc.
> Please understand me I'm not suggesting to use the new syntax in
> Harbour codebase and everything need to be optional, I only want to
> understand if the pp can be used and how and where changes to the
> compiler are needed.
It's not such simple as you may think and I do not talk about
technical problem with intorducing new syntax. This is rather
trivial.
> 1) {} to enclose function's body. This valid code:
> function test( a )
> if a == 1
> return .t.
> else
> return .f.
> endif
> using -w gives: warning: W0007 Function 'TEST' does not end with
> RETURN statement, so it would be good to have:
This have to be fixed in compiler.
> function test( a ) {
> if a == 1
> return .t.
> else
> return .f.
> endif
> }
> the rule could be: "if after the function there is an open curly brace
> there must be a close brace at the end and at least one return inside"
I do not see how it can help in fixing above warning message.
There is no relation at all. We will still have it. To fix it
it's necessary to update internal logic so it will work correctly
also for code like:
function test( a ) {
if a == 1
return .t.
elseif a == 3
return .f.
elseif a == 4
if f2()==5
return .t.
elseif f3()==10
break;
else
return .f.
endif
else
return .f.
endif
without warnings and for:
function test( a ) {
if a == 1
return .t.
elseif a == 3
return .f.
elseif a == 4
if f2()==5
return .t.
elseif f3()==10
++a
else
return .f.
endif
else
return .f.
endif
with warnings.
> 2) ";" as statement separator. This is a valid code:
> function test( a ) ; outstd( "Hello World" ) ; return nil
> but not if I simply "reform" the code:
> function test( a ) ;
> outstd( "Hello World" ) ;
> return nil
> the rule could be: ";" is the statement separator but is optional if
> it is followed by a <newline>
> ( HB_PP_MULTILINE_STRING could be changed to "\" <newline> )
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.
> 3) "=" vs "==" vs ":="
> Viktor took some time to change <> to !( == ) and = to := so it could
> be that = is always assignment and == is always equal
> ( clearly activated via a compiler switch ) so we could have:
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 )
[...]
You do not have to think about them but when you are writing code
then you are using such rules mechanically because they are intuitive
and you used to use them from ground school. If we change only one
operator then we will create really crazy world. We will have to
change all to keep above rules working. It will cause that the most
of existing code will have to be rewritten and we will use very
important for many people functionality: current '=', '<=', '>=',
'<' and '>' behavior which can greatly simplify a lot of code.
> function test( a )
> var a = 1;
> instead of
> function test( a )
> local a := 1
> in classes we already use VAR for "local" members.
It's PP rule. We also support DATA. You can use any other names
if you will add new PP rule. You can also use VAR instead of LOCAL
if you will make:
#xcommand VAR <vars,...> [ AS <type> ] => LOCAL <vars> [ AS <type> ]
> These changes are enough to get a correctly outlined source with the
> syntax highlighted.
Syntax highlighting in some editors is not a problem. It's enough to update
highlighting rules in used editor. AFAIR in the past Giancarlo created .prg
rules for eclipse or some other popular IDE.
Such things should never force language syntax modification.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
