Hi Lorenzo,
If the goal is to make Harbour compatible with Eclipse,
IMO one should rather try to contribute the relevant
parts to the Eclipse project itself, instead of changing
the Clipper language to fit into their existing concept.
Maybe it's just a matter of creating a syntax-rule file.
This was my first idea. I've contacted a Java developer but he told me
that it's not a trivial task. Language plugins are not only about
syntax coloring but also outlining, source refactoring and so on. You
need to know well the specific platform ( Eclipse is different from
NetBeans ) not only Java.
But this apart the "=" vs ":=" and the semicolon issues are general
issue that will only improve the acceptance of the language.
I don't agree to revise our syntax to make it more
"acceptable" either by users, or by certain code editors.
Python (but there could be many other language listed here)
is also an accepted language and doesn't have any such
resemblance to C or Java.
It's a big challenge to write a generic editor engine
with refactor, "IntelliSense", syntax coloring, and even
some sort of on-the-fly compiling / error reporting /
project parsing support. The solution is probably some
sort of plug-in system, where you can hook your native
compiler engine to their editor to do the required tasks
as the editing goes. So, even if Harbour would be converted
syntax-wise to be accepted by Eclipse, a lot of other
tasks would still remain unsolved.
In the shade of the above, I feel my (BTW still incomplete,
due to lack of input) error message tweaking effort for
Eclipse, was a waste of time.
PS: Just slightly related, but I'd rather find it useful
to add some switches to the compiler to warn on
obsolete, non-recommended/ambiguous or unnecessary
syntax alternatives, like '=' used as assignment. If we
are to clean or change the language syntax that is, and
drive language users to a better and more coherent syntax
style. Some other candidtates: if(), .not., <>, #, */&& comments.
Notice: Many of these come from dBase III+/Clipper <=87
times, and the only reason they are there is compatibility
with such dinosaur code.
Clearly I think the contrary for ":=" vs "=": it is the ":=" that
should be ALWAYS like "=".
Everyone can have his own choice and style preference, but
regardless, in Clipper (5.x and compatible languages) the
native assignment operator _is_ ':='. This is the only one
assignment operator which can be used in all situations and
in an unambiguous way, and in some place the only assignment
operator supported. As such, it seems like the best candidate
for 'the' assignment operator.
We can dispute whether this is good or not, but this is the
same as disputing the main goal of our project.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
