Recent

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

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10398
  • FPC developer.
Re: Separating definition and implementation parts
« Reply #30 on: June 06, 2022, 12:51:13 pm »
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.

Doesn't sound to me as anything that would resonate with any of M2's principles.  And is static module inheritance really OO ?  Only two out of Identity, polymorphism, data encapsulation and abstraction.

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #31 on: June 06, 2022, 12:57:07 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.

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.

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.

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #32 on: June 06, 2022, 01:08:21 pm »
Doesn't sound to me as anything that would resonate with any of M2's principles.

Frankly I agree, but I was writing a disk (etc.) display program and having some sort of template definition- e.g. to present the same interface irrespective of whether media access was via PC BIOS calls or direct to an IDE controller- would have been extremely useful. As it was, the bigger problem was that the M2 compiler I was using at the time- can't remember whether it was Logitech or Topspeed- turned out to have an unreasonably-small hardcoded limit of how many modules it could deal with.

Quote
And is static module inheritance really OO ?  Only two out of Identity, polymorphism, data encapsulation and abstraction.

Definitely not. Point I was making was that OO later supplied things that weren't in M2 modularisation, but having some sort of "half-way house" might still have been useful.

I've not, unfortunately, been able to find a copy of Wirth's anti-OO rant. It was reprinted in .Exe in the mid-90s but might actually have been an interview from a few years before, Wirth might already have been arguing from the POV or Oberon rather than that of M2/Pascal but in any event it was uncomfortable reading (there's good reasons why ageing academics are shuffled out with "Emeritus" stickers :-)

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 #33 on: June 06, 2022, 01:35:35 pm »
Also keep in mind that Wirth was into system programming at that time, not application programming.

It is application programming where OO is now ubiquitous

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #34 on: June 06, 2022, 02:06:36 pm »
Also keep in mind that Wirth was into system programming at that time, not application programming.

It is application programming where OO is now ubiquitous

Compilers are system software and benefit from such things in moderation. Even at the OS level, being able to define device drivers relative to a consistent template is valuable.

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

440bx

  • Hero Member
  • *****
  • Posts: 3156
Re: Separating definition and implementation parts
« Reply #35 on: June 06, 2022, 02:07:18 pm »
It is application programming where OO is now ubiquitous
But, it should be noted that one of the most salient characteristics of OOP comes straight from systems programming which is, polymorphism.  In O/Ss, polymorphism is used to transparently redirect input and ouput by altering function pointers. 

This idea, which admittedly is a powerful mechanism, is being grossly abused and misused in OOP.

Like everything, "good" is relative and, too much "good" ends up being bad.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10398
  • FPC developer.
Re: Separating definition and implementation parts
« Reply #36 on: June 06, 2022, 02:25:33 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.

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.

It suits some developers to have a people writing up long stories in the wiki, rather than saying a firm NO! to an outlandish feature suggestion.

I have no such qualms :-)

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

FPC is a dialectal hodgepodge, but traditionally focussed on Borland/Turbo Pascal dialects (BP7 till 1.0.x, more Delphi oriented with 2.0.x+).   

Personally I think the core goal should be to avoid fragmenting what's left of the Pascal world. So that means Delphi with minor compat modes for BP and ISO Dialects (as long as there are people willing to work on them)

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #37 on: June 06, 2022, 02:36:56 pm »
(polymorphism), which admittedly is a powerful mechanism, is being grossly abused and misused in OOP.

Only when an entry point is late-bound: OO- as originally defined- is at least as much about inheritance (with an override capability) as it is about polymorphism. And if properly implemented the compiler resolves all function calls that aren't explicitly late-bound, rather than relying on explicit or implicit function pointers which IME are undesirable in a system intended to be robust.

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #38 on: June 06, 2022, 02:45:15 pm »
It suits some developers to have a people writing up long stories in the wiki, rather than saying a firm NO! to an outlandish feature suggestion.

I have no such qualms :-)

The wiki is far too public for "wouldn't it be nice" discussion that people might interpret as factual documentation. Perhaps it should have a "High and low fantasy" category :-)

Quote
FPC is a dialectal hodgepodge, but traditionally focussed on Borland/Turbo Pascal dialects (BP7 till 1.0.x, more Delphi oriented with 2.0.x+).   

Personally I think the core goal should be to avoid fragmenting what's left of the Pascal world. So that means Delphi with minor compat modes for BP and ISO Dialects (as long as there are people willing to work on them)

I agree. I was going to suggest that we should perhaps be looking at whether anybody is actually using e.g. the ISO dialect, but it can be very embarrassing if somebody wants to compile some ancient high-value codebase and we have to tell him that the current compiler no longer supports the stuff he needs (e.g. like old-style objects).

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

Thaddy

  • Hero Member
  • *****
  • Posts: 12195
Re: Separating definition and implementation parts
« Reply #39 on: June 06, 2022, 03:49:06 pm »

I agree. I was going to suggest that we should perhaps be looking at whether anybody is actually using e.g. the ISO dialect, but it can be very embarrassing if somebody wants to compile some ancient high-value codebase and we have to tell him that the current compiler no longer supports the stuff he needs (e.g. like old-style objects).

MarkMLl
Well, I am using it to try to compile some old - very old - code. And it can be fun.
But in general old freaks like me use it, but it is not a "standard" for a long time.
Note I predate most of the FPC developers by almost two decades.
« Last Edit: June 06, 2022, 03:51:35 pm by Thaddy »
Manuals, manuals, manuals first.
You have incompetence and sheer incompetence.

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #40 on: June 06, 2022, 04:42:01 pm »
Well, I am using it to try to compile some old - very old - code. And it can be fun.
But in general old freaks like me use it, but it is not a "standard" for a long time.
Note I predate most of the FPC developers by almost two decades.

I'm using code originally written in '64 actively, although it's been transcribed, and I've done various things with ALGOL of about the same vintage. Apart from that the oldest Pascal code I've dealt with was an APL interpreter for a CDC from the mid 70s... in other words about the same time that I went to university.

But whether I've been selling, supporting or discussing in academia, the impression I've always got is that ISO standardisation of Pascal and Modula-2 was pretty much ignored, and contributed to the popular perception that they were unusable niche languages.

But DaveP's question a few days ago about converting some 1990s Modula-2 to Pascal is a useful reminder that the more dialects we can support (without making the codebase unmaintainable) the better.

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 #41 on: June 06, 2022, 04:55:30 pm »
I agree. I was going to suggest that we should perhaps be looking at whether anybody is actually using e.g. the ISO dialect, but

Because? Where is the actual hurt?

Quote

it can be very embarrassing if somebody wants to compile some ancient high-value codebase and we have to tell him that the current compiler no longer supports the stuff he needs (e.g. like old-style objects).

No different when people notice missing features in the Delphi dialect, or don't understand why their D7 code with 40% pure assembler routines doesn't work on 64-bit ARM ?
« Last Edit: June 06, 2022, 05:01:28 pm by marcov »

MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #42 on: June 06, 2022, 05:35:19 pm »
I agree. I was going to suggest that we should perhaps be looking at whether anybody is actually using e.g. the ISO dialect, but

Because? Where is the actual hurt?

The more weird linguistic features piled into the language, the more it risks becoming an unmaintainable pile. As an example, the desirability of supporting Modula-2 style syntax has been raised in the past but the bottom line is that it's not feasible to shoehorn an increasing number of features into the syntax- even if isolated by mode selection.

Quote
Quote

it can be very embarrassing if somebody wants to compile some ancient high-value codebase and we have to tell him that the current compiler no longer supports the stuff he needs (e.g. like old-style objects).

No different when people notice missing features in the Delphi dialect, or don't understand why their D7 code with 40% pure assembler routines doesn't work on 64-bit ARM ?

Actually yes, very different. "Missing features in the Delphi dialect" is arguably a bug, and no sane developer who knows he has embedded assembler would expect it to be portable... irrespective of the example shown by Macs with on-the-fly binary translation. However saying to somebody "no, that mode used to be supported but isn't any more" is simply embarrassing: there's obviously things dropped like GTK v1 and the earlier versions of Win-32 but that can generally be justified by pointing to inadvisability of running an OS sufficiently old that it demands that API not to mention the rarity of hardware that supports those OSes.

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 #43 on: June 06, 2022, 10:56:23 pm »
The more weird linguistic features piled into the language, the more it risks becoming an unmaintainable pile. As an example, the desirability of supporting Modula-2 style syntax has been raised in the past but the bottom line is that it's not feasible to shoehorn an increasing number of features into the syntax- even if isolated by mode selection.

True. But I would rather cull objfpc than mode ISO. 

Quote
Quote
No different when people notice missing features in the Delphi dialect, or don't understand why their D7 code with 40% pure assembler routines doesn't work on 64-bit ARM ?

Actually yes, very different. "Missing features in the Delphi dialect" is arguably a bug, and no sane developer who knows he has embedded assembler would expect it to be portable...

Euh, as for the latter, how long have you been answering questions here ?  ;) ;)


MarkMLl

  • Hero Member
  • *****
  • Posts: 5567
Re: Separating definition and implementation parts
« Reply #44 on: June 06, 2022, 11:26:24 pm »
Euh, as for the latter, how long have you been answering questions here ?  ;) ;)

Not nearly as long as I was active on the ML, but... well /yes/ :-)

But I tried to phrase that to indicate that the bigger problem is when the developer doesn't know because he's just using an off-the-shelf library.

There's a big earthmover manufacturer in the UK with yellow products and a three-letter name. In the 1970s they were a Burroughs customer, but their DPM was taken on a few "jollies" by a competitor who assured him that anything B could do they could do better.

He signed the replacement contract on Friday. On Monday the content of his desk was waiting for him at the gatehouse. You see, those computers were optimised to run COBOL with an almost one-to-one correspondence between COBOL and assembler statements... with the result that many application programmers skipped the COBOL and wrote directly in medium-systems assembler.

The joke is that if names are anything to go by, the engineer most likely to have tipped off the customer's senior management was last heard of working for the company behind the Hercules mainframe emulator... which is something that IBM /really/ doesn't like.

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

 

TinyPortal © 2005-2018