Proposal: optional -kL compiler switch to use && / || as .AND. / .OR.

[Lorenzo Fiorini]

Hi all,

I'd like to ask whether there's interest in an opt-in compiler switch that lets && and || be used as the logical operators .AND. and .OR.. I have a working implementation and would prefer to hear your view before sending a pull request.

Motivation
&& and || are the logical operators in C, C++, Java, JavaScript, C#, Python-adjacent code and so on. Developers coming to Harbour from those languages trip over the fact that && is a line comment here. The switch would make Harbour code look more familiar to them. It would be strictly opt-in.

Proposed behavior
- -kL enables it, -kL- disables it, and #pragma -kL+ / #pragma -kL- switch it per file. The default is off.
- When on, && is .AND., || is .OR., and && is no longer a comment (use // instead).
- {|| still starts an empty codeblock parameter list. {|x,y| x || y } uses || as OR.

harbour
#pragma -kL+
IF lA && ! lB || lC     // same as: lA .AND. ! lB .OR. lC
   ...
ENDIF

Implementation (small, preprocessor-only)
- New HB_COMPFLAG_CLOGIC and a fCLogic state in the preprocessor (hb_pp_setCLogic()).
- The tokenizer (src/pp/ppcore.c) emits the existing .AND. and .OR. tokens, so the lexer and grammar are unchanged and -p output stays valid for a compiler without the switch.
- Two spots needed care: a keyword directly followed by && (a&&b, where a& would otherwise scan as macro-text), and the {|| rule above.
- Touches about 10 files: hbcomp.h, hbpp.h, ppcore.c, ppcomp.c, cmdcheck.c, hbusage.c, doc/en/compiler.txt, and utils/hbtest (new rt_clogic.prg with 19 test calls).

Verification
hbtest rebuilt with the modified compiler passes 4880 of 4880 (the previous 4861 plus the new ones). I only tested on macOS with clang, so Linux and Windows builds are untested. The standard headers in include/ contain no &&, so they are unaffected when the switch is on.

Known limitations and trade-offs
- && comments stop working under the switch, so a project has to use // consistently. Third-party .ch files that use && comments would break if included in a -kL build.
- The runtime macro compiler (&("a && b")) is not covered.
- It adds one more behavior difference between Harbour and Clipper/xHarbour source. Because it is off by default and uses a normal -k switch, existing code is unaffected.

Questions
1. Is this something you'd want upstream at all, or would you prefer it stays a local patch?
2. If yes, is -kL a good letter, and is a -k switch the right place for it?
3. Should the macro compiler be covered for consistency?
4. Would you rather see && comments kept working in some form, for example only when followed by a space and a non-expression?

The patch is a single commit and I can send it as a PR against master or as a patch file. 

Thanks for your time.

Lorenzo

[Bacco]

Hi Lorenzo

My 2 cents:

it would make sense to adopt if it was more complete,

e.g. covering booleans (hb_bitand, or, shift and so on

and other cases), it seems to me this 2 cases are a

little underwelming to change the core.

I understand the motivation, I myself have a lot of

shortcuts locally, using the PP for ease of life, as:

a.b.c   =>   a["b"]["c"]

a IN (b, c, d)    =>   ((a == b) .or. (a == c) .or. (a == d))

Could you share the approach of how it's implemented

so we can give a better feedback?

Best Regards

Bacco

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/CAB9-wYtJT0_1tV%3D_qvVcSp-CoEUvkfVaGbgUypbi4g34Qog-7w%40mail.gmail.com.

[Bacco]

PS; also, I really would like to learn better the lexer

and grammar part, to implement some basic things

lacking in Hb, as 0b0110110 binary prefix, parity

between 0dNNN d"NNN" syntax and 0tNNN and

t"NNN" and a lot of QOL details. Maybe this thread

can be a start for a deeper overhaul.

I don't mind participating more, but for quite a

while I am a little tired of lack of documentation

of the deeper parts of the compiler when we

need learn to implement things that maybe aren't

the focus of the current core devs. Most of the

things I don't want someone do for me, but maybe

some better examples/description of lower level

details coult open the doors.

Example question: can someone explain how

can make a new function that also resolves at

compile time?

[marcosgambeta]

Bacco,

The changes to implement the 0b (binary base) and 0o (octal base) prefixes are not complex.

See these commits in Harbour++:

https://github.com/marcosgambeta/harbourpp-v1/commit/6e3d0ad0f599e4cfe74953c1a52b14418463876c

https://github.com/marcosgambeta/harbourpp-v1/commit/dd425eda429e1941822eb923844c86e6e3ed3265

Regards,

Marcos Gambeta

[Aleksander Czajczynski]

Hello!

0b addition looks certainly good to me! Octal doesn't feel like it is very much useful today.

On the thread's subjects, I'd see something that can disable && comments.

For the "&& ||" logic grammar I don't feel a good match with xBase spelling, but if preprocessor would be able to do something to allow extended translations && -> .AND. ; || => .OR. per user preference, why not.

Though I think PP might not cover pipe-char at all, watch out additional clashes with { || }, & being macro operator in strings (that is in string only, but I remember xHarbour issues with implementing & bitwise operators).

Best regards, Aleksander

marcosgambeta wrote:

To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/5dadd5a2-10d6-4652-9dac-e26437404210n%40googlegroups.com.