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

Sean Charles (emacstheviking) objitsu at gmail.com
Wed Aug 17 20:04:18 AEST 2022


OK, I think I understand now but the last paragraph is my only bone of contention now as it seems to go against the fundamental nature of literate programming, at least as I have always executed it, that I have the ability to define the code in any order I see fit that makes sense to explain, and the tool stitches it into the compiler correct sequencing into a file/compilation unit.

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

``` <<defining.foo>>
:- foo(io::di, io::uo) is det.

foo(!IO) :-
    <<foo.preamble>>
    <<foo.content>>
    <<foo.postamble>>
```

And then I should be at liberty to explain the named blocks shown in any order that I see fit, otherwise this feels like having to alter the way that I think about creating my LP source document just to fit the needs of a specific language compiler. If I understand what you said, I would have to do it like this:

``` <<defining.foo>>
:- foo(io::di, io::uo) is det.

foo(!IO) :-
    foo_preamble(!IO),
    foo.content(!IO),
    foo_postamble(!IO).
```

And then I would have a named block for each of those sub-predicates. That's kind of acceptable but again, I might not want to do that.
Never mind, life is full of compromises, I am sure something will crystallize soon.

Thanks,
Sean






> On 17 Aug 2022, at 10:49, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> 
> 2022-08-17 17:48 GMT+10:00 "Sean Charles (emacstheviking)" <objitsu at gmail.com>:
>> Thanks Zoltan.
>> 
>> That's killed that feature then,
> 
> I am not sure what feature you mean, but I don't see why that follows.
> The directives that you got the errors for are all totally unnecessary,
> and can be trivially deleted. This is because in code such as
> 
> :- pragma source_file(FileName).
> #N
> ... first line of code ...
> :- pragma source_file(FileName).
> #N+1
> ... second line of code
> :- pragma source_file(FileName).
> #N+2
> 
> only the first source file pragma and the first line number
> actually do anything. Any source_file pragma that names
> the same file as the previous one is a no-op, and likewise
> any occurrence of #N that occurs K lines after the previous
> #M directive, where N = M + K, is also redundant, since
> the parser's line counting would know that the current line
> number is M + K.
> 
> For example, when generating C code, the Mercury compiler
> emits #line directives just before the bodies of foreign_procs.
> It does not emit a separate directive for *each line* of the
> foreign_proc, since that would be unnecessary, for the same reason.
> 
> If you emit source_file pragmas and #Ms only if they are
> not redundant, your tool will work for any literate program
> where each clause and directive is contiguous in the
> source code. 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.
> 
> Zoltan.



More information about the users mailing list