Recent

Author Topic: Separating definition and implementation parts  (Read 4243 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #15 on: June 02, 2022, 10:24:12 am »
Thanks very much for the detailed answer, and my apologies for causing you extra work.

the compiler does store the included files and their timestamps in the PPU.

/Aha/, that's something I didn't adequately appreciate.

That's actually an argument that you could probably use when tiresome people (such as, on occasion, myself) opine that there could usefully be an accessible preprocessor stage: it would need some way of annotating the .ppu later produced by the compiler.

Quote
I say likely, because if you only change a typo in a comment and that change doesn't lead to a change of the file position for the remainder of the code (meaning for example that you didn't insert or remove a line) then the relevant content of the unit (from the compiler's PoV) is still considered the same and thus the compiler doesn't see the need to recompile Y.

Interesting. Something I'm tinkering with at the moment uses the Linux FAM API, and I noticed an interesting situation where a changed file (containing test data) was always detected if touched etc. but wasn't detected reliably if simply /saved/ by Lazarus. Leaving aside for the moment the potential that the IDE has for not really saving something that hasn't had a significant change (e.g. all changes have been undone), that turned out to mainly be because Lazarus was using the "unix doctrine" of renaming the original and creating a new file.

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

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 4749
  • Compiler Developer
Re: Separating definition and implementation parts
« Reply #16 on: June 02, 2022, 02:01:40 pm »
That's actually an argument that you could probably use when tiresome people (such as, on occasion, myself) opine that there could usefully be an accessible preprocessor stage: it would need some way of annotating the .ppu later produced by the compiler.

You don't need to look at some accessible preprocessor stage: if you define different defines at the command line for different runs of the compiler a compiled unit won't be recompiled (that's why Lazarus triggers a complete build if you changed some project settings).

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #17 on: June 02, 2022, 02:26:40 pm »
You don't need to look at some accessible preprocessor stage: if you define different defines at the command line for different runs of the compiler a compiled unit won't be recompiled (that's why Lazarus triggers a complete build if you changed some project settings).

Yes, the existing conditional directives etc. are beyond reproach... the multiline macro expansion is a joy (even if some argue that being able to interpolate even limited parameters would make it even better).

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.

Please take that to be a rhetorical question, I'm definitely not trying to criticise the status quo (since I said I wanted to avoid doing that on OP).

Quote
A reproducible test case would be very welcome.

I'll see what I can do.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Kays

  • Sr. Member
  • ****
  • Posts: 465
  • Whasup!?
    • KaiBurghardt.de
Re: Separating definition and implementation parts
« Reply #18 on: June 03, 2022, 09:43:01 am »
FYI, regarding ISO 10206 “Extended Pascal” modules there is (or was) the plan to have *.int.* (interface) and *.imp.* (implementation) files beside single-file-modules (claim was inserted by Keith Bowes in 2017).
Yours Sincerely
Kai Burghardt

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #19 on: June 03, 2022, 11:08:13 am »
FYI, regarding ISO 10206 “Extended Pascal” modules there is (or was) the plan to have *.int.* (interface) and *.imp.* (implementation) files beside single-file-modules (claim was inserted by Keith Bowes in 2017).

Thanks for that detail. I've been trying to be careful with my use of "interface" in the discussion above because of its widely-accepted meaning in the context of OO programming etc. My tentative choice of .itf was because it was the extension adopted by TopSpeed Pascal, and that was originally a sibling of their Modula-2 compiler which Niels Jensen took when he left Borland allegedly after Philippe Kahn bought in an externally-developed C compiler.

On reflection, I think it's worth remarking that filenames with the pattern modulename.imp.{p,pp,pas} etc. are sufficiently "un-DOS" (by extension, "un-Windows", "un-OS/2" and so on) and for that matter "un-unix" that I have to wonder what sort of platform the ISO committee envisaged as being suitable for hosting a Pascal compiler. There's a definite whiff of the Ada ailment creeping in there: a prerequisite of being able to run a compiler is having access to a large multiuser system capable of running a committee-designed workbench.

I'm tempted to start a new thread to discuss how many of the features in https://wiki.freepascal.org/Extended_Pascal have been (or might realistically at some point be) implemented. However TBH I feel that ISO-standard Pascal (and for that matter ISO-standard Modula-2) have even less industrial and historical significance than Ada.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10398
  • FPC developer.
Re: Separating definition and implementation parts
« Reply #20 on: June 03, 2022, 01:41:54 pm »
FYI, regarding ISO 10206 “Extended Pascal” modules there is (or was) the plan to have *.int.* (interface) and *.imp.* (implementation) files beside single-file-modules (claim was inserted by Keith Bowes in 2017).

What do you mean by planned? Planned by the ISO committee, but not implemented in the final draft?

BeniBela

  • Hero Member
  • *****
  • Posts: 847
    • homepage
Re: Separating definition and implementation parts
« Reply #21 on: June 03, 2022, 06:31:12 pm »

Quote
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

mercurhyo

  • Full Member
  • ***
  • Posts: 220
Re: Separating definition and implementation parts
« Reply #22 on: June 05, 2022, 06:19:49 pm »
My 2 cents here.

As Pr. Niklaus With, Father of the Pascal language had a "vision" He then created a successor language named Modula 2. Meaning IT IS a pascalish dialect. And Modula 2 introduced structured modular programming. Each module had 2 files, as I read along on this publication. Formally 1 file as interface (.def) and 1 file as implementation (.mod)

AT these OLD times it was so damn AMAZING that I gave up for 3 years working with turbinopasquale LOL I even saw in the industry some robots totally programmed with modula 2.

However ... due to fashion's mass effect, I came back to pascal and worked with "popular" (this world is heavy) delpinabitius .

You can never know the weight of fashion and the keys of locked minds.
« Last Edit: June 05, 2022, 06:21:51 pm by mercurhyo »
DEO MERCHVRIO - Linux, Win10pro - Ryzen9XT 24threads + Geforce Rtx 3080SUPRIM
god of financial gain, commerce, eloquence (and thus poetry), messages, communication (including divination), travelers, boundaries, luck, trickery and thieves; he also serves as the guide of souls to the underworld

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #23 on: June 05, 2022, 07:42:08 pm »
As Pr. Niklaus With, Father of the Pascal language had a "vision" He then created a successor language named Modula 2. Meaning IT IS a pascalish dialect. And Modula 2 introduced structured modular programming. Each module had 2 files, as I read along on this publication. Formally 1 file as interface (.def) and 1 file as implementation (.mod)

Yes, there are several ex-users here- and it has been alluded to if not named directly elsewhere in the thread. You've actually forgotten Modula, but I've been able to find very little relating to its structure... it might actually have been closer to Brinch Hansen's Edison.

As far as Modula-2 being a Pascalish language is concerned: one has to be extremely careful there since there was a fundamental difference between Pascal's "this conditional applies to a single statement" and Modula-2's "this conditional applies to everything up to an explicit else or end". Taking into account timeframes, I think it would be most accurate to refer to the former as "ALGOL-60/Pascal" and the latter as "ALGOL-68/Modula-2": almost all other current languages fall into one or the other of those categories.

Modula-2, particularly in conjunction with OS/2, fitted in very nicely with the DLL concept. However its failing in that area was that it wasn't possible to use a single definition module as a template for multiple implementation modules, or to have a definition module implicitly inheriting the exports of a preceding one. That is, of course, where OO techniques come into play, which initially at least attracted Wirth's scorn since he insisted that an object was nothing more than a record: an inexcusable whitewash since he'd spent at least one sabbatical at PARC.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

mercurhyo

  • Full Member
  • ***
  • Posts: 220
Re: Separating definition and implementation parts
« Reply #24 on: June 06, 2022, 09:19:47 am »
Nope! "OOP" anywhere = mistake! Pr. Wirth was a visionaire, and OOP is basically what he said. He was around 75-80 years old to explain the "sabatical" thingeys. Hope the brain of anyone here works fine in theses ages.
Yes OOP is useful but no God... by the way, even windows 10/11 is 90% C, not C++ HA!

I'm not mean, I won't say 10% hahahaha

SO!!! I'm stick on my position = ALL THAT IS ABOUT weight of fashion
« Last Edit: June 06, 2022, 09:34:28 am by mercurhyo »
DEO MERCHVRIO - Linux, Win10pro - Ryzen9XT 24threads + Geforce Rtx 3080SUPRIM
god of financial gain, commerce, eloquence (and thus poetry), messages, communication (including divination), travelers, boundaries, luck, trickery and thieves; he also serves as the guide of souls to the underworld

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #25 on: June 06, 2022, 09:29:04 am »
Nope! "OOP" anywhere = mistake! Pr. Wirth was a visionaire, and OOP is basically what he saud. He was around 75-80 years old to explain the "sabatical" thingeys. Hope the brain of anyone here works fine in theses ages.
Yes OOP is useful but no God... by the way, even windows 10/11 is 90% C, not C++ HA!

I'm not mean, I won't say 10% hahahaha

SO!!! I'm stick on my position = ALL THAT IS ABOUT weight of fashion

Rubbish.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

mercurhyo

  • Full Member
  • ***
  • Posts: 220
Re: Separating definition and implementation parts
« Reply #26 on: June 06, 2022, 09:35:58 am »

Rubbish.

MarkMLl

My pleasure, "milady" hahahahahahaha I LOVED your nonargument, marry me haahahhah
DEO MERCHVRIO - Linux, Win10pro - Ryzen9XT 24threads + Geforce Rtx 3080SUPRIM
god of financial gain, commerce, eloquence (and thus poetry), messages, communication (including divination), travelers, boundaries, luck, trickery and thieves; he also serves as the guide of souls to the underworld

Kays

  • Sr. Member
  • ****
  • Posts: 465
  • Whasup!?
    • KaiBurghardt.de
Re: Separating definition and implementation parts
« Reply #27 on: June 06, 2022, 11:44:55 am »
What do you mean by planned? Planned by the ISO committee, but not implemented in the final draft?
No, the ISO committee isn’t concerned how a computer organizes its data. I posted a link to our Wiki page, so I thought its self-explanatory this was an FPC idea.

[…] What are the technical implications of doing this […]
I think the whole idea of separating the interface and implementation into individual files makes only sense if your compiler allows you to swap alternative implementations (of the same interface) on request. If there is always a 1‑to‑1 relation, 1 interface : 1 implementation, it does (technically) not make any sense to have separate files other than for increasing complexity.
Yours Sincerely
Kai Burghardt

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #28 on: June 06, 2022, 12:09:53 pm »
No, the ISO committee isn’t concerned how a computer organizes its data. I posted a link to our Wiki page, so I thought its self-explanatory this was an FPC idea.

OK, so the operative text is Enhancements to Standard Pascal ... Modularity and separate compilation ... (not yet implemented). Frankly I think the choice of names is a nitwit idea because having multiple dots in a name is so unusual and because TopSpeed had demonstrated that .itf was workable many years earlier.

If that stuff is never going to happen I'm not sure it even belongs in the wiki, since so many people assume that it's official documentation.

Quote
I think the whole idea of separating the interface and implementation into individual files makes only sense if your compiler allows you to swap alternative implementations (of the same interface) on request. If there is always a 1‑to‑1 relation, 1 interface : 1 implementation, it does (technically) not make any sense to have separate files other than for increasing complexity.

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

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10398
  • FPC developer.
Re: Separating definition and implementation parts
« Reply #29 on: June 06, 2022, 12:34:58 pm »
No, the ISO committee isn’t concerned how a computer organizes its data. I posted a link to our Wiki page, so I thought its self-explanatory this was an FPC idea.

The Wiki is publically writable, and not in any way authoritative in any form.

 

TinyPortal © 2005-2018