Recent

Author Topic: Post-Pascal  (Read 2081 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Post-Pascal
« on: April 12, 2021, 10:22:12 pm »
What could fairly be chopped out of Object Pascal "as we know it" and replaced by library routines and packages?

I'm not trolling, I'm just wondering to what extent the core language could realistically be made smaller.

For example, could strings be chopped out and implemented as a specialisation of dynamic arrays?

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: 11352
  • FPC developer.
Re: Post-Pascal
« Reply #1 on: April 12, 2021, 10:28:59 pm »
What could fairly be chopped out of Object Pascal "as we know it" and replaced by library routines and packages?

See the list of Embacardero for their Nextgen compiler? Not that I agree with everything on it, but it would be a discussion starting document. They pretty much backed down from that in the end.

Quote
I'm not trolling, I'm just wondering to what extent the core language could realistically be made smaller.

For example, could strings be chopped out and implemented as a specialisation of dynamic arrays?

0. specialization is a weird way of expressing it. What do you mean exactly by that?
1. Not a langauge->library thing.
2. what about codepage?
3. copy-on-write.

Anyway, if I would make something incompatible, I would start over entirely, and examine all base assumptions. Hybrids that are weak compromises are pointless.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Post-Pascal
« Reply #2 on: April 12, 2021, 10:36:14 pm »
See the list of Embacardero for their Nextgen compiler? Not that I agree with everything on it, but it would be a discussion starting document. They pretty much backed down from that in the end.

I'll chase it up in the morning.

Quote
0. specialization is a weird way of expressing it. What do you mean exactly by that?
1. Not a langauge->library thing.
2. what about codepage?
3. copy-on-write.

Anyway, if I would make something incompatible, I would start over entirely, and examine all base assumptions. Hybrids that are weak compromises are pointless.

0) Analogy more than anything else I guess. Dynamic arrays are an underlying feature, strings are built on top.

1) Not sure. A lot depends on what is actually built into the language, e.g. if the language gained a way of specifying that a certain type of quoting implied that a certain type of data structure were to be considered it would probably be viable. Note that I'm /not/ suggesting that the underlying language should be a complete and compatible Pascal implementation.

2) Implies that a dynamic array also needs attributes of various types.

3) Is there any reason why both strings and dynamic arrays should not benefit from this?

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: 11352
  • FPC developer.
Re: Post-Pascal
« Reply #3 on: April 12, 2021, 10:49:40 pm »
1) Not sure. A lot depends on what is actually built into the language, e.g. if the language gained a way of specifying that a certain type of quoting implied that a certain type of data structure were to be considered it would probably be viable.

That (conversions) of course, overload selection is another one. COM/ActiveX compatibility is another one and a possible reason for the (3) difference.

For the implied conversions (literals inclusive) I have a small text prepared from an earlier discussion, see  overview. It might be outdated, they might be more. It is our own little "Perl 6 periodic table of operators" like dirty secret

Note that I'm /not/ suggesting that the underlying language should be a complete and compatible Pascal implementation.

As said that IMHO defeats the purpose of the whole exercise. If not compatible, why keep the rest of it? Backwards compatibility is so central (with the exception of the unicode migration) that it is hard to detach from the rest.

Quote
2) Implies that a dynamic array also needs attributes of various types.

If you go too far in that direction, make everything a variant with some attributes ;-)

And for what? To save 10k of type helpers?

Quote
3) Is there any reason why both strings and dynamic arrays should not benefit from this?

Don't know. My guess is that dynamic arrays are key to some activex safe arrays implementation.

It might also be simply statistics. Deep copies of arrays are rare than strings.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Post-Pascal
« Reply #4 on: April 13, 2021, 10:23:59 am »
1) Not sure. A lot depends on what is actually built into the language, e.g. if the language gained a way of specifying that a certain type of quoting implied that a certain type of data structure were to be considered it would probably be viable.

That (conversions) of course, overload selection is another one. COM/ActiveX compatibility is another one and a possible reason for the (3) difference.

For the implied conversions (literals inclusive) I have a small text prepared from an earlier discussion, see  overview. It might be outdated, they might be more. It is our own little "Perl 6 periodic table of operators" like dirty secret

Pascal's "Periodic table of the elementals" :-)

I was of course using quoting as an example, but I've done things in the past like allowing (via pragmata and extensible syntax) / / to be defined as quotes surrounding a regex (with comparison operators) or backref (as the source of an assignment). It worked out surprisingly well.

Now I'm obviously not suggesting for one moment that regexes should be a fundamental part of the language. But perhaps having that degree of flexibility should, even if restricted to privileged users.

Quote
Note that I'm /not/ suggesting that the underlying language should be a complete and compatible Pascal implementation.

As said that IMHO defeats the purpose of the whole exercise. If not compatible, why keep the rest of it? Backwards compatibility is so central (with the exception of the unicode migration) that it is hard to detach from the rest.

Give the core language the responsibility for code generation, in particular stackframe management. Keep it simple and clean enough that maintainers have less of an argument that every single trivial change (e.g. more C-style operators extending the += etc. family) is something that they'd have to maintain, because it was actually defined and implemented at the library level.

Quote
Quote
2) Implies that a dynamic array also needs attributes of various types.

If you go too far in that direction, make everything a variant with some attributes ;-)

And for what? To save 10k of type helpers?

In this particular case, I was thinking of the case where a codepage number was potentially saved with each string. In the more general case, if type helpers would allow all of this to be moved out of the core language then that's fine by me.

Quote
Quote
3) Is there any reason why both strings and dynamic arrays should not benefit from this?

Don't know. My guess is that dynamic arrays are key to some activex safe arrays implementation.

It might also be simply statistics. Deep copies of arrays are rare than strings.

True. Whatever, I'm trying to make some general points here.

* A core "pascal-like" language handling code generation. Very strongly typed, extensible operators and possibly extensible syntax.

* Around that a shell language compatible with Pascal "as we know it", isolated from code generation etc. and fairly accessible to people who want to tinker.

* RTL, FCL, LCL, Lazarus plugins etc.

People who simply want to do things like adding operators shouldn't need to get anywhere near the code generation, and they shouldn't be able to do anything that breaks the system. And $DEITY help us, that potentially includes people who want to replace begin/end with braces... let 'em try, their attempt might even result in something from which others can learn.

As I've said: some of this stuff I've done myself, although I'm quite a long way down the ladder as far as compiler proficiency goes. There's also https://en.wikipedia.org/wiki/Seed7 and https://web.archive.org/web/20201112030222/www.dlugosz.com/Perl6/web/APL.html ... both of these demonstrate a useful amount of extensibility but I think they emphasise that due to having to specify associativity etc. they might be beyond most application-grade programmers.

But I think the lesson is that particularly with today's computing power, it's realistic for a core/shell compiler to build itself (incorporating all required syntax) at the start of each run.

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: 11352
  • FPC developer.
Re: Post-Pascal
« Reply #5 on: April 13, 2021, 02:52:44 pm »

I was of course using quoting as an example, but I've done things in the past like allowing (via pragmata and extensible syntax) / / to be defined as quotes surrounding a regex (with comparison operators) or backref (as the source of an assignment). It worked out surprisingly well.

In my experience it can look fine while it is simple and if you maintain a no-compromise attitude (clean form over features/convenience).

What I'm afraid for is scaling it up to a production compiler and when legacy, features and external connectivity will force you to compromise.
 
Quote
Now I'm obviously not suggesting for one moment that regexes should be a fundamental part of the language. But perhaps having that degree of flexibility should, even if restricted to privileged users.

I think such very complex systems should be separate from the real language. Latex and Tex so to speak.

Quote
Give the core language the responsibility for code generation, in particular stackframe management. Keep it simple and clean enough that maintainers have less of an argument that every single trivial change (e.g. more C-style operators extending the += etc. family) is something that they'd have to maintain, because it was actually defined and implemented at the library level.

You want things like string performance to be top notch. Shuffeling it away to the meta programming language layer doesn't help that.

Quote
In this particular case, I was thinking of the case where a codepage number was potentially saved with each string. In the more general case, if type helpers would allow all of this to be moved out of the core language then that's fine by me.

It is not that black or white. Even if there is in language support, many operations can be deferred to the RTL rather than actively generating code for it.

Quote
* A core "pascal-like" language handling code generation. Very strongly typed, extensible operators and possibly extensible syntax.

* Around that a shell language compatible with Pascal "as we know it", isolated from code generation etc. and fairly accessible to people who want to tinker.

* RTL, FCL, LCL, Lazarus plugins etc.

For a toy language experiment you'll probably never get that far. All these language experiments fail to take the next step.

 
Quote
As I've said: some of this stuff I've done myself, although I'm quite a long way down the ladder as far as compiler proficiency goes. There's also https://en.wikipedia.org/wiki/Seed7 and https://web.archive.org/web/20201112030222/www.dlugosz.com/Perl6/web/APL.html

Not one but TWO kisses of death ? Yeah, I know Thomas Mertes and Seed7, you can look up the discussions in early 2000s c.l.misc

Anyway, I don't believe in this route.

Quote
... both of these demonstrate a useful amount of extensibility but I think they emphasise that due to having to specify associativity etc. they might be beyond most application-grade programmers.

This is always the problem with metaprogramming. It is only very easy for the guy that made it.

Quote
But I think the lesson is that particularly with today's computing power, it's realistic for a core/shell compiler to build itself (incorporating all required syntax) at the start of each run.

That's a matter of making a bullet list of pros and cons. I'm not entirely sure what the pros are worth for all the downsides.

Anyway it doesn't share any core values of the Free Pascal project. (which is stated as creating a production level language and compiler, deliberately not prioritising "clean")

But if I had to do something, I would start with a source2source compiler for the basic level, and see how far I come. Only if it works out start implementing a real cg.

« Last Edit: April 13, 2021, 03:08:46 pm by marcov »

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: Post-Pascal
« Reply #6 on: April 14, 2021, 06:28:04 pm »
Anyway, if I would make something incompatible, I would start over entirely, and examine all base assumptions. Hybrids that are weak compromises are pointless.

Really good point...
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Post-Pascal
« Reply #7 on: April 14, 2021, 07:31:26 pm »
Anyway, if I would make something incompatible, I would start over entirely, and examine all base assumptions. Hybrids that are weak compromises are pointless.

Which, let's remember, is what With himself did:
Pascal -> add a lot of features -> Modula -> extreme simplification -> Oberon

In fact, since Pascal today is a lot like Modula, maybe the OP woud be happier with Oberon ;)
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Post-Pascal
« Reply #8 on: April 14, 2021, 08:04:18 pm »
In fact, since Pascal today is a lot like Modula, maybe the OP woud be happier with Oberon ;)

Perhaps, except that would obviously mean sacrificing the rich FPC libraries, not to mention Lazarus.

I'm not saying that I dislike what FPC and Lazarus have matured into. What I'm saying is that I both strongly dislike and am deeply worried by the "we aren't going to entertain any language changes because it would cause maintenance problems" attitude: if that's the case then I consider there to be a strong incentive to find some way of restructuring things so that the core team didn't have to be involved if somebody wanted application-specific operators or whatever.

However it's quite clear that my opinion isn't shared by anybody else, so I'm not putting effort into arguing the case.

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: 11352
  • FPC developer.
Re: Post-Pascal
« Reply #9 on: April 14, 2021, 08:19:12 pm »
Which, let's remember, is what With himself did:
Pascal -> add a lot of features -> Modula -> extreme simplification -> Oberon

In fact, since Pascal today is a lot like Modula, maybe the OP woud be happier with Oberon ;)

I'm also a Modula2 fan for certain base principles, and I programmed M2 from say 1994 to 1997-2000. But it is matter of weighing things. So while e.g. I still think the Modula-2 blocks structure is superior, in the end it is all about getting things done. On the other hand I think that string handling in Modula-2 is too minimalistic.  Too focussed on statically allocated strings in a period that dynamically allocated strings were becoming the norm.

In the end I migrated to Free Pascal (then still mostly Dos/go32v2 based)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Post-Pascal
« Reply #10 on: April 14, 2021, 09:56:22 pm »
I'm also a Modula2 fan for certain base principles, and I programmed M2 from say 1994 to 1997-2000. But it is matter of weighing things. So while e.g. I still think the Modula-2 blocks structure is superior, in the end it is all about getting things done. On the other hand I think that string handling in Modula-2 is too minimalistic.  Too focussed on statically allocated strings in a period that dynamically allocated strings were becoming the norm.

Agreed all points.

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

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: Post-Pascal
« Reply #11 on: April 15, 2021, 12:53:38 am »
I'm not saying that I dislike what FPC and Lazarus have matured into. What I'm saying is that I both strongly dislike and am deeply worried by the "we aren't going to entertain any language changes because it would cause maintenance problems" attitude: if that's the case then I consider there to be a strong incentive to find some way of restructuring things so that the core team didn't have to be involved if somebody wanted application-specific operators or whatever.

Maybe it's just me, but the primary arguments that I have seen used has not necessarily focused on maintenance problems (although that has been mentioned on occasion), but on changes that violate the spirit of Pascal.

Even if we limit the discussion to the "maintenance" issues, it is mostly about "who will implement and then maintain such a feature" rather than "I'm fine with maintaining it, but it will be hard."

The latter issue would certainly suggest some refactoring or rearchitecting, but the former problem is more about resource constraints -- insufficient, capable developers with stamina and interest in the area being discussed.    And with that being the main issue, it will be hard to get any traction around major refactoring anyway.

Fix the resourcing issue, and a lot of other problems start to become less intractable.
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

 

TinyPortal © 2005-2018