4D Comment-Blocks and SubSubSubCommentBlocks

What a surprise, 4D is the first language i see
in which you can have a deep hierchachical structure
of fold-able comment-blocks in levels.


That’s pretty neat. Just don’t use /* */ to comment out a block of code that contains a line like this :grinning:

$xmlNode:=DOM Find XML element($xmlRoot;"//Customer/*";$axmlNodes)

I think it is better when 4D does foldable-multi-line-comment-blocks
the same way all other programming-languages support that feature.

Other languages did this (and that have very good reasons to do it this way and not any other way),
Always the first comment block end sign asterix+slash
is the total end of the comment block!
Starting a new sub-comment-block inner a main-comment-block with slash+asterix
must be ignored, all what is written inside the comment-block must only a passive comment
and NOT starting any sub-comment-blocks with his own end-sub-comment-block.
The starting sign slash+asterix
must be ignored and be always passive comment-text inner comment-block.
Every end sign asterix+slash
is always the total end of the comment-block!

So (only) i think it is a mistake by 4D with this sub-comment-blocks,
nice to see
but can brings a lot of possible bugs behind and makes correct syntax parsing senseless difficult.

Inside a foldable comment-block only the end sign asterix+slash
is forbidden/reserved for fuctional let comment-block always total END (all other chars are passive).
This must be in all languages done this way to minimalize to only “one reserved sign” inside a comment-block.

Yes, the programmer/user must pay attention to never insert any End-Sign inner comment-block,
otherwise this breaks the comment block and you got a error.
This must done everywhere and can be done to pay attention to never insert end-sign.
This is only one rule what must respected, thats the offical philosophy.

But when you support such strange/exotic nested comment-blocks in comment-blocks,
than much more must be respected by the programmer/user when he inserts or removes something
innner the comment-block (what is not good to have more than one thing to respected always).
For example when only some comment-lines inner the comment-blocks are removed
and you do not see that one of the line contains a new start of a sub-comment-block
than you got errors.

And too any parser had a more easy+save job to interpret all correct,
when only always any end-sign asterix+slash
means always
"this is the total end of the comment block, and not of any phantasy sub-comment-blocks)

Yes, when you write at any place a end-sign in comment-block,
the comment-blocks than ends there (this is normal and in every language like this).
Inside a comment all is comment and not a activ syntax with syntax-parsing,
so you can not write inside a comment-block any codes(this are comments)

/* --- $str:="__*/__"+String(3) ---- */

This one is+must always forbidden or means comment end at first end-sign!

So please to 4D, removes this (nice looking) feature to can have nested comment-blocks.
Foldable Multi-Line-Comment-Blocks must always be one dimensional
and not with hierarchical structure like a active syntax.

1 Like

I think 4D never intended to “implement” multi-level block comment, what you describe is probably just consequential.

Most editors simply use pattern-matching (like regex) to find block comments. That is why tokens in static text, or a mixture of line and block comments messes things up. That’s pretty standard.

Atom uses a tree-sitter parser to create an abstract syntax tree for performance, but I don’t think the processing of block comments is any different.

1 Like

I think the main concern is that the compiler doesn’t produce a syntax error, even though the method editor reports the issue.

Whichever way you go, nested comments or no nest comments, there should be a syntax error if you are missing a */ or have an extra /*

Yes, i am totally with you, one of the main destination is to let compiler-syntax-check show all these kinds of syntax errors. As you can see in my last post first picture is from 4D method editor and their a warning-symbol is shown
translated: The “comment end” is missing

Now i see, that this message is not shown in compiler syntax check, thanks for point that out.

1 Like

Hi all,

The support of nested comments in 4D is a choice. They are supported by other languages such as SWIFT.
We have made some modifications to the algorithm in the code editor to remove some warning that are not errors.

Thanks for your feedback.

Hi Vanessa,

My understanding was that the code editor is working properly. It is the compiler that is not producing a syntax error for an unterminated /* comment.

In swift, a missing */ causes a compile error. I think 4D should as well since it is incorrect syntax, just like a missing bracket.


As in many other languages, 4D supports a start comment in a string.

For example


However, the end comment is not supported like other languages. You have a warning from the editor.

For example


Furthermore, while analyzing all the examples you provided us, we found that the editor displays a warning in the following case. No reason.

/* /*

The forum doesn’t manage either. :grinning:

VoilĂ !
Screen Shot 2020-06-23 at 17.39.58

It’s fixed in bug ACI0100906.


My test with newest from today: 4D v18 R3Build253195 (on mac catalina 4D-mono)
shows different normal behaviour, any StartComment or EndComment
in a DoubleQuoted String always not neutral it is the start or end of new comment-block or sub-comment-block. (?)

So i am not understand what is mean whith “4D supports start comment in a string” (?)
You see on my foto that comment block never ends…endless, because it is interpreted as a start of new sub-comment block (which needs a own end).
Bildschirmfoto 2020-06-23 um 19.15.29

But my wishes goes into a total other way, to remove completly the sub-comment-block-feature.
Just i think, comment block must passive. String in doubleQuote or any syntax interpretation not exist inner a comment-block! So every end-comment-block sign must be the total end of main comment-block. Any start-commetn-block signs are must always ignored inner a comment block, because no sub-comment-blocks exist (same as no sytax interpretation exist inner a commentBlock).
But anyway, this is only my think about it and the world is big enough to have other concepts. I like apple and apple phylosophy, but for putting this in swift for sub-comments i think that apple goes here the wrong way in my eyes (but anyway, not all must think like my strict way thinking about programming/syntax concepts/phylosophy).

Greetings Lutz

(anyway, i must learn to live with it when 4D not removed it, when i am not too old to learn new things :wink:


I’m sorry, I wasn’t clear.

I wanted to share with you the results of our analysis and tests, as well as what we have improved thanks to all examples in this discussion.

For the integration of the fix in the versions, I advise you to follow the bug ACI0100906. The fix will be integrated soon in v18 LTS and v18 Feature Release.

Thanks for your help.