Shouldn't the presence of REM and/or ! on a line make the compiler ignore a trailing ampersand (&) on that line?

print "Line 1"
REM print "line 2" ! Don't want this line &
print "Line 3" ! do want this one
end

The above will only print "Line 1". If I change the trailing "&" to "and", it will then also print "Line 3".

I realize it's better not to end comment lines with "&" but I thought the continuation character would be ignored by the compiler on comment lines.

A-Shell v6.5.1722.2 under Centos 7
COMPLP.LIT v1.1(137)

I agree that making the & continuation character work on comment lines can be an invitation to trouble, but the opposite could also be confusing. It all depends on whether you view a statement that spreads over multiple source lines as a single entity (in which case a single comment marker should suffice).

In any case, it has been this way for as long as I can remember, making me think that it was a carry-over from AMOS. (I no longer have access to a working AMOS box so I can't easily confirm that.)

The problem with reversing the behavior is that there's no easy way of knowing who will be adversely affected. Fortunately, in most cases you'll get a compilation error if you comment out only part of a multi-line statement, but that's not a guarantee if the multi-line statement contains multiple statements stitched together with colons. The way it is now is more likely to not warn you with a compiler when you end up accidentally commenting-out more than you intended by not seeing the &.

I'm open to suggestions, but would be worried to make any changes that affect backwards compatibility.

Wow this is a landmine...

I would agree with Steve that anything after a "!" would be ignored, that would include the "&", tho u can see why the compiler added line 3 to the original REM.

Since this could retroactively cause havoc with legacy code i vote to leave the behaviour as is. Anyone coding fresh can code around any anomaly.

FWIW i use this frequently and it works:

If X=1 then & ! comment here
do this : &
do this

The last thing I want is for you to make changes that affect backwards compatibility. I was just surprised to encounter this situation.

I agree with both of you. It would be interesting to verify just what AMOS did, but I'm not sure anyone can. And in any case, it's probably more dangerous to change the behavior. This is a good example of a situation where the compiler might issue warning messages, but such warnings would rapidly become annoyances to anyone aware of the situation and happy to leave their code as is. Then of course we could add more switches (display warnings, ignore warnings, treat warning as errors, specify the sensitivity level of the warnings, etc.)

It could certainly turn into pandoras box but there could be some sort of switch like /w that could "warn" of potential unexpected runtime results even though the statement is "legal". I don't know if such an animal is required for our purposes but could be valuable. Problem is who defines what a "potential runtime snafu" really is? Perhaps one mans snafu is anothers coding style.

Exactly. As an example, I'd be tempted to offer a warning for your example...


The other problem is that while requiring a /W switch to enable warnings takes care of the annoyance factor for those who don't want them; it almost certainly means that you'll never get the warning that really would have helped, unless you always compile with /W.

But while on the subject, I will note that there is one warning that I don't think I've ever received a complaint about (unmapped variables) ...

I suppose we could add to that a message like "# comments continued to next line". But before long that compact approach to warnings will become unwieldy, requiring us to go to more detailed messages (which must then be easily distinguishable from errors, both for humans reading the messages and for external editors that are looking to capture them to identify errors to be edited).

Good suggestion! OR add [*potential runtime conflicts detected. Review .LST file] You could add a [WARNINGS] are to the prog.lst file. Would work similar to searching for the unmapped vars and not require specific switches and would rely on the programmer to review manually if they so choose. And who knows if we receive enough Naggs might me enough to change nested IF then statements to IF/ENDIF!

I like the warning message idea, but for me, such warnings might get overlooked when compiling en masse (which I often do via RECOMX, for example after changing a common INCLUDE file). Instead (or in addition), if you inserted that warning inside affected LSX files, I could make a search for it part of my compile routine.

Or perhaps you could create a stand-alone utility to scan specified files for this particular situation and produce a list of affected modules. That way, we could run it periodically to find potential problems without having to compile anything. And you wouldn't have to change the compiler.