Separating definition and implementation parts

[PascalDragon]

But what happens if it is /natural/ to embed something in the main Pascal source, which needs preprocessing in order to make it available as a resource etc.? The canonical example of this is embedded SQL.

If it would be with the yet to be integrated multiline string then it's just that: a string in an include file or the file itself.
If it would be with the yet to be integrated $IncludeString directive then the included file in question would be handled like an ordinary include file as far as recompilation detection is concerned.
If it would be with the $R directive to include a Windows-like resource then I can't answer whether this would currently work correctly. Ideally the compiler should handle changed resource files as well. What would definitely not work however is if you have a $R something.res (meaning you use a precompiled resource instead of having the compiler generate it by calling fpcres) and you change the original file that was compiled into the resource then FPC would have no way to detect that, cause the res file contains no information about the original files.

I suppose that you could have a stub file that included both the definition and an implementation selected by conditionals, but that's getting /heavy/. My own opinion is that the copyright+license argument is significant, but separating the files also allows definitions to be locked against unauthorised modification

The stub file approach is in fact something that's used quite some time in the RTL

Since the wiki is basically annotating a non-public standard, and since "Standard" and "Extended" Pascal arguably did more harm than good to the language, I'm not at all sure that having keeping that page of "aspirational features" is in FPC's interest.

Extended Pascal was much less used than ISO Pascal, so it can't have done much bad. And sadly it came too late to unfold the good it promised (and if you take the time to read the Extended Pascal standard it has quite some goodies).

And keeping the page about the Extended is definitely in FPC's interest, cause it's about keeping track which features of Extended Pascal are already implemented. And while it's not a priority it is our goal for FPC to also be a full ISO Extended Pascal.

Factual documentation of what FPC actually implements and what "standard" features it omits is obviously useful. A list of suggested extensions to the standards which can't be xrefed to the content of the actual standards isn't.

I agree. As such I have clarified on the Wiki that the part about the two-file-modules is merely a suggestion.

Edit: nearly forgot this:

To come back to your problem: as you see it should work correctly. However we know from past experience that something there is fishy when multiple include files are used, but we've not yet been able to pinpoint the problem. Or maybe it was indeed solved already. That's the problem: we don't have a reproducible case and thus don't know whether the problem has been solved or not.

Bearing that in mind, I think I'll try having separate .itf files when I've next got something I'm building as a library, and will also revisit the project I mentioned a few posts ago where stuff wasn't getting recompiled. I'll report back presently if I can pin a reliable test case down.

A reproducible test case would be very welcome.

There is this: https://gitlab.com/freepascal.org/fpc/source/-/issues/37478

This is about errors when using precompiled units. What I want is the compiler not detecting that something changed in indirectly used files and finishing successfully, but with no changes.

[MarkMLl]

As usual I'd like to express my appreciation of the work that you and the rest of the core team puts into this stuff.

Noted your comment about the RTL's heavy use of include files, which hadn't escaped me even though I didn't appreciate how robustly they were handled.

I agree. As such I have clarified on the Wiki that the part about the two-file-modules is merely a suggestion.

I find myself wondering how many make/build implementations would be broken by the double-dot scheme suggested.

MarkMLl

[PascalDragon]

Noted your comment about the RTL's heavy use of include files, which hadn't escaped me even though I didn't appreciate how robustly they were handled.

I had especially remarked about the stub file approach you suggested, not the RTL's general use of include files. Though yes, it does use quite a lot, but there the recompilation isn't a problem, because the RTL is always done using a clean build.

I agree. As such I have clarified on the Wiki that the part about the two-file-modules is merely a suggestion.

I find myself wondering how many make/build implementations would be broken by the double-dot scheme suggested.

Probably less then you'd expect. At work (in a C++ context) we make heavy use of dotted filenames for headers, source files and build artifacts (because it's much nicer to look at) and so far found no critical issues with MSVC, MSBuild or GNU make. Even FPC's ChangeFileExt handles this correctly by searching the point from the end and not from the start.

[MarkMLl]

This is about errors when using precompiled units. What I want is the compiler not detecting that something changed in indirectly used files and finishing successfully, but with no changes.

Found something when I wasn't expecting it.

An in-project unit brought into a called unit (not the main program) using

Code: Pascal  [Select][+][-]

1. uses Hash32 in '../hash32/hash32.pas';
2.  

where ../hash32 isn't set up in the Lazarus project paths (-Fu), I think that's similar to the case I had earlier, but doesn't have $unitpath muddying the water.

An edit to a primality test in hash32.pas was ignored until I did a Lazarus "Clean directory". I think I can reproduce that, please leave it with me... I mention it in case I keel over during the next few days.

MarkMLl

[MarkMLl]

where ../hash32 isn't set up in the Lazarus project paths (-Fu), I think that's similar to the case I had earlier, but doesn't have $unitpath muddying the water.

An edit to a primality test in hash32.pas was ignored until I did a Lazarus "Clean directory". I think I can reproduce that, please leave it with me... I mention it in case I keel over during the next few days.

I've not forgotten this. The same project fails intermittently if I build from makefile with something like

Code: Text  [Select][+][-]

1. FPCFLAGS=-Fu../hash32/ -Fu../ -Sa
2.  

i.e. it's the relative path rather than the uses clause. This is currently causing me enormous pain since I've got code that fails if one of the runtime check options isn't enabled... and until I started vaping every single .o and .ppu in the tree I couldn't test it reliably.

MarkMLl

[MarkMLl]

If it would be with the yet to be integrated multiline string then it's just that: a string in an include file or the file itself.

Somewhat belated comment, wandering OT slightly.

I've previously said that I'm unhappy with the proposals for multiline strings, because apart from anything else they are likely to claim e.g. the " character and that's not something to be done lightly. I've also remarked that in some scripting stuff of my own I've allowed strings to be optionally delimited by / which made them into regexes... however while convenient that clashes with usage from at least one other language.

I wonder whether it would be possible to do something like using "..." for a multiline literal string, but mandating that it must in all cases have an associated type, and that no automatic type conversions will be made?

There might also need to be a local directive to tell the compiler how to deal with a nested " (i.e. whether to treat "" or \" specially) but in general that would allow a string to be explicitly defined as C-like (i.e. potentially using \ escapes), regex-like and so on without ambiguity.

MarkMLl

[PascalDragon]

I've previously said that I'm unhappy with the proposals for multiline strings, because apart from anything else they are likely to claim e.g. the " character and that's not something to be done lightly. I've also remarked that in some scripting stuff of my own I've allowed strings to be optionally delimited by / which made them into regexes... however while convenient that clashes with usage from at least one other language.

It uses ` (backtick, ASCII character #60), not ".

I wonder whether it would be possible to do something like using "..." for a multiline literal string, but mandating that it must in all cases have an associated type, and that no automatic type conversions will be made?

The point of the multi line string feature is that an unmodified, multi line string can be pasted into the source (as long as it doesn't contain backticks, as those need to be doubled, but these are likely much more seldom than a "). Anything else can just as well be solved with the existing concatenation.

There might also need to be a local directive to tell the compiler how to deal with a nested " (i.e. whether to treat "" or \" specially) but in general that would allow a string to be explicitly defined as C-like (i.e. potentially using \ escapes), regex-like and so on without ambiguity.

We don't want to do C-like stuff. And this is not what this feature wants to solve.

[MarkMLl]

It uses ` (backtick, ASCII character #60), not ".

I was /very/ careful to say "e.g." there. I don't want to argue for or against any particular character.

The main point I was trying to make was the desirability- in my opinion- of never making any assumptions about the actual type of a string decorated in this fashion, which is not anything I've seen argued in this forum.

MarkMLl

[PascalDragon]

The main point I was trying to make was the desirability- in my opinion- of never making any assumptions about the actual type of a string decorated in this fashion, which is not anything I've seen argued in this forum.

I don't get your point. A multiline string constant is no different from an ordinary string constant as far as its type is concerned and follows the same rules regarding e.g. Unicode. The only difference is in how it's parsed and that the compiler automatically inserts newlines and indentation (based on compiler directives).

[MarkMLl]

I don't get your point. A multiline string constant is no different from an ordinary string constant as far as its type is concerned and follows the same rules regarding e.g. Unicode. The only difference is in how it's parsed and that the compiler automatically inserts newlines and indentation (based on compiler directives).

I was originally concerned that this would be a wedge that heralded the insertion of an increasing amount of the syntactic sugar that you decry. with different decoration depending on what it was to be used for. However it occurred to me that this could be prevented with enforced typing.

"I'll get me coat."

MarkMLl

[marcov]

Even FPC's ChangeFileExt handles this correctly by searching the point from the end and not from the start.

Well, it is safe to call changefileext on a string without extension. If you have dotted filenames, you might have to sanitize your code that that never happens (since that would lob off another segment of the string).

[PascalDragon]

I was originally concerned that this would be a wedge that heralded the insertion of an increasing amount of the syntactic sugar that you decry.

Why do you think that is still not integrated? I have more important features to fry than that...

with different decoration depending on what it was to be used for. However it occurred to me that this could be prevented with enforced typing.

I still don't get what typing would solve there, especially as in Pascal the result type of an expression (on the right) does not depend on the left side (except for function pointers).

Even FPC's ChangeFileExt handles this correctly by searching the point from the end and not from the start.

Well, it is safe to call changefileext on a string without extension. If you have dotted filenames, you might have to sanitize your code that that never happens (since that would lob off another segment of the string).

For dotted filenames without extension one needs to be careful of course.