[m-users.] Correct use of pragma source_file and #N directives together ?

[Zoltan Somogyi]

2022-08-17 20:04 GMT+10:00 "Sean Charles (emacstheviking)" <objitsu at gmail.com>:
>> .... This is as it should be: if you think you need
>> to explain one half of a clause separately from its other half,
>> then you probably should create a separate predicate
>> for one half or the other.
> 
> I completely understand what you are saying but in the `noweb` approach, which I have implemented, I am at liberty to do this:

Note that I said "probably". You can still explain each block of code
separately, because you *can* put #Ns into the middle of a clause.
It is only source_file pragmas that cannot be put into the middle
of a clause. This is because #Ns, like whitespace and comments,
are simple enough to be processed completely by the lexer, while
pragmas of all kinds, not just source_file pragmas, are processed
by the parser.

Note that there is no *technical* reason why we couldn't extend
the #N mechanism to allow the setting of file names as well as line numbers.
The reason why we do not do so is performance. At the moment,
the lexer, which is the only part of the compiler that looks at every
byte of the source file individually, carries along a piece of state
containing the line number, which it updates both when it sees
a newline character and when it sees a #N. Supporting #N therefore
does not require any extra state in the lexer. Supporting a mechanism
that would allow the reset of the filename within the lexer *would*
require it to carry extra state, the filename. In the almost 30 years of
since we started work on Mercury, this is the first time anybody
had a use case where that could conceivably be useful, and even now,
I think the case for this is very weak. This is because I think that a literate
program that would explain two different parts of a clause
in *different source files* is very bad idea: the files involved
would exhibit a tighter form of coupling than is possible
with just about any other kind language feature.

Zoltan.