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

[Sean Charles (emacstheviking)]

So much fun on a Wednesday

> ... 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:

I couldn't agree more but who knows what people might choose to do?

Well, I think I have enough background information and knowledge to to either figure out some sort of compromise, but sadly not the time again... day jobs!

Thanks all, very much appreciated as always.

Sean.





> On 17 Aug 2022, at 11:41, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> 
> 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.