Recent

Author Topic: Compiler extension  (Read 4761 times)

Shpend

  • Full Member
  • ***
  • Posts: 167
Compiler extension
« on: December 13, 2019, 01:54:29 pm »
I have just recently come across something which is called "NewPascal" created and maintained by the forum-user named: "Maciej Izak"

I have actually messaged him about this but as it seems, he isnt really caring alot about that project since 18 months now in total, unfortunately, I liked the Idea and that it attracted new people to give Pascal a try and people who wanna switch from the shitty Delphi enviroment and their respective company.

Also, this question I have had long time ago in mind but for some reason always forgot to ask any compiler developer (based on open source projects of course): Would it be able for you guys, to make the FPC compiler in such an extend modularised that NON-PASCAL-COMPILER-DEVELOPER can also bring their ideas into existence, for instance:

 as I penetrated you guys 1 year ago with the oxygene topic, to maybe implement some good stuff they have accomplished in oxygene, would it be somehow possible to extend the compiler in such a way, that external developer who are not familar with compilers, may actually create extensions (like for browsers) which extend the fpc compiler and make new features possible, which still doesnt mean, that any new feature should be added instantly to the fpc framework at the end, but just as a consideration, like, implementing for instance, tuples, just letting euphorized ppl develop it when they feel they need/want it and see if they can make itr possible and if they can (which again, fpc should provide then a good "extension-builder-toolset") we can then here in the forum discuss if it should make its way into the fpc.

Would really love to hear from you about this !

Best regards

Shpend

EDIT:
I am aware that this idea may sound like a fairytale world I live in, but I m just super curious if such a construct would be possible, but hey, better ask than sorry :D
« Last Edit: December 13, 2019, 02:05:17 pm by Shpend »

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Compiler extension
« Reply #1 on: December 13, 2019, 09:23:15 pm »
... would it be somehow possible to extend the compiler in such a way, that external developer who are not familar with compilers, may actually create extensions (like for browsers) which extend the fpc compiler and make new features possible,
It is possible BUT, not for someone who isn't familiar with compiler writing.  Dynamically extending a language's grammar may be the most complex feature of any compiler.  Definitely not for the faint of heart.

The following article might be helpful to you to get an idea of the complexity of the task, http://pauillac.inria.fr/~ddr/camlp5/doc/htmlc/grammars.html 

HTH.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Compiler extension
« Reply #2 on: December 13, 2019, 09:48:21 pm »
Thanks for that reference. Another couple that might interest are

https://en.wikipedia.org/wiki/Seed7

http://www.dlugosz.com/Perl6/web/APL.html

However, it's not fair to compare writing a compiler extension with a browser extension, since rather than extending the rules used to parse the syntax stream browser extensions normally either process certain forms of delimited data (e.g. something that has arrived formatted as test/pdf or whatever) or hook into the user interface in exactly the same way that event handlers hook into Lazarus forms. In short, browser extensions are much more akin to writing library functions than to extending the compiler.

I've written an extensible compiler (strictly, an extensible compiler compiler), but the extensions have to be written in the metalanguage so are comparatively inaccessible to untutored users (i.e. the sort of people who think that extending a compiler is easy :-) However I did skimp on making modifications local to a block etc., what I'd done was good enough for my needs and I didn't fancy the intellectual heavy lifting involved.

One side effect of having done that however was that I'm now inclined to think that Wirth's declaration change which put the variable name before the type was wrong, since if the type is at the start of the statement it is far easier to parse the remainder (which might potentially include an "unusual" variable name format or an arbitrary initialisation statement):

TTimestamp transactionStart= 2019-12-13T17:56:11Z;

MarkMLl
« Last Edit: December 15, 2019, 07:59:42 pm by 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: 11353
  • FPC developer.
Re: Compiler extension
« Reply #3 on: December 13, 2019, 10:35:49 pm »
I have just recently come across something which is called "NewPascal" created and maintained by the forum-user named: "Maciej Izak"

I have actually messaged him about this but as it seems, he isnt really caring alot about that project since 18 months now in total, unfortunately, I liked the Idea and that it attracted new people to give Pascal a try and people who wanna switch from the shitty Delphi enviroment and their respective company.

The problem is that about the only thing those people have in common is some irrational anger against Delphi. It is like a development tool's version of Brexit. Just like real Brexit, there is a lot of spin, but nobody will like the inevitable outcome. And even if they get free reign, their visions are not compatible beyond the anti-delphi sentiment

 
Quote
Also, this question I have had long time ago in mind but for some reason always forgot to ask any compiler developer (based on open source projects of course): Would it be able for you guys, to make the FPC compiler in such an extend modularised that NON-PASCAL-COMPILER-DEVELOPER can also bring their ideas into existence, for instance:

No. Unlike what most people think modularization is not a free thing. It comes with tremendous cost, both initial work, and maintenance thereafter. This is not a constructive direction. It is not a minor one-off backdoor to be implemented but an immensely complicated interface that needs constant care and political will to work. And it is not there.

And anyway, it is just a trick to bounce the costs of a fork back to the developers instead of the people doing an extension.

If you really think there is a lot to gain, don't be a coward, just fork and carry your vision into the future! Accept no compromise! Don't be shy! If your vision is successfull, people will flock to it and make it the "greatest compiler ever".

Even if it not is going to dominate, forking some stable compiler as a base for a long time view might be a good thing. Modularized interfaces evolve too.
« Last Edit: December 13, 2019, 11:09:29 pm by marcov »

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Compiler extension
« Reply #4 on: December 13, 2019, 11:05:18 pm »
https://en.wikipedia.org/wiki/Seed7

http://www.dlugosz.com/Perl6/web/APL.html
Interesting reading, thank you.  I wasn't aware of Seed7, looks quite interesting, I plan on checking it out sometime.

I'm now inclined to think that Wirth's declaration change which put the variable name before the type was wrong, since if the type is at the start of the statement it is far easier to parse the remainder (which might potentially include an "unusual" variable name format or an arbitrary initialisation statement):
I guess that's two different schools of thoughts.  I strongly prefer Wirth's approach than the reverse, used in C and others. 

The reason is, I am firm believer that a language grammar should be _humanly_ easily understandable and as intuitive as possible.  Visualizing a Pascal statement is most of the time trivial, whereas in C, I often have to mentally parse the declaration/statement to figure out what it does/is.  I consider that work that should not be necessary and, it is one of the many reasons I strongly dislike C (even though I still use it.)

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Compiler extension
« Reply #5 on: December 13, 2019, 11:08:36 pm »
Oh /please/, Marco, don't make light of Brexit: Her Majesty and I, as the two people who subjectively matter, now have to put up with Johnson for an indeterminate number of years. (But I did like the joke about the cat called Brexit, who wakes his owner up every morning meowing to go out but when she opens the door he just stands there, undecided, and when finally pushed out wants to come back in.)

I think there /is/ one thing that an interested and talented outsider could usefully do, which is to examine the existing range of types and find some way that the "specials"- strings and dynamic arrays- could be re-implemented inside an elegant system which supported only scalar types and objects (preferably with hooks for automatic release and garbage collection).

In short, WELL DONE THAT VOLUNTEER :-)

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: 11353
  • FPC developer.
Re: Compiler extension
« Reply #6 on: December 13, 2019, 11:13:28 pm »
Oh /please/, Marco, don't make light of Brexit: Her Majesty and I, as the two people who subjectively matter, now have to put up with Johnson for an indeterminate number of years.

To make things easier for us bl*dy foreigners, we like to call him "British-Trump". But, indeed, Brexit is serious matter, but so is forking the project, so I think it is appropriate.

Quote
I think there /is/ one thing that an interested and talented outsider could usefully do, which is to examine the existing range of types and find some way that the "specials"- strings and dynamic arrays- could be re-implemented inside an elegant system which supported only scalar types and objects (preferably with hooks for automatic release and garbage collection).

Well, that touches the other irrational illusion, that a language can make it based on its inherit elegant syntax (alone).  If you really believe that, look at the set of popular languages [C,C#,C++, Python and Javascript], and start to meditate.

The problems of a development system are only very minorly in the language part beyond the most base subset that most languages share.
« Last Edit: December 14, 2019, 11:27:10 am by marcov »

valdir.marcos

  • Hero Member
  • *****
  • Posts: 1106
Re: Compiler extension
« Reply #7 on: December 13, 2019, 11:55:41 pm »
Thanks for that reference. Another couple that might interest are

https://en.wikipedia.org/wiki/Seed7

http://www.dlugosz.com/Perl6/web/APL.html

However, it's not fair to compare writing a compiler extension with a browser extension, since rather than extending the rules used to parse the syntax stream browser extensions normally either process certain forms of delimited data (e.g. something that has arrived formatted as test/pdf or whatever) or hook into the user interface in exactly the same way that event handlers hook into Lazarus forms. In short, browser extensions are much more akin to writing library functions than to extending the compiler.

I've written an extensible compiler (strictly, an extensible compiler compiler), but the extensions have to be written in the metalanguage so are comparatively inaccessible to untutored users (i.e. the sort of people who think that extending a compiler is easy :-) One side effect of having done that however was that I'm now inclined to think that Wirth's declaration change which put the variable name before the type was wrong, since if the type is at the start of the statement it is far easier to parse the remainder (which might potentially include an "unusual" variable name format or an arbitrary initialisation statement):

TTimestamp transactionStart= 2019-12-13T17:56:11Z;

MarkMLl
I believe that identifiers-type order were a novelty of Pascal since all previous languages, including Algol W by Niklaus Wirth himself used the type-identifiers order.
Maybe he did that for readability, simplicity, elegance or learning purposes...

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Compiler extension
« Reply #8 on: December 14, 2019, 12:30:03 am »
N. Wirth himself. 1972
Programming Language Pascal (Revised Report)
[scanned typewriter pages, no searchable text]

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwiZga7z4LPmAhUP36QKHdwYDigQFjAAegQIAhAC&url=http%3A%2F%2Fweb.eah-jena.de%2F~kleine%2Fhistory%2Flanguages%2FWirth-PascalRevisedReport.pdf&usg=AOvVaw373b-3jN8XYzAJE0h9tfiq

...a natural and convenient representation ... of Pascal


Winni

valdir.marcos

  • Hero Member
  • *****
  • Posts: 1106
Re: Compiler extension
« Reply #9 on: December 14, 2019, 03:28:19 am »
N. Wirth himself. 1972
Programming Language Pascal (Revised Report)
[scanned typewriter pages, no searchable text]

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwiZga7z4LPmAhUP36QKHdwYDigQFjAAegQIAhAC&url=http%3A%2F%2Fweb.eah-jena.de%2F~kleine%2Fhistory%2Flanguages%2FWirth-PascalRevisedReport.pdf&usg=AOvVaw373b-3jN8XYzAJE0h9tfiq

...a natural and convenient representation ... of Pascal
The introduction of the document you cited is an outstanding class of history!
Thank you.

The Programming Language Pascal (Revised Report), Niklaus Wirth, November 7972 5
http://web.eah-jena.de/~kleine/history/languages/Wirth-PascalRevisedReport.pdf
--------------------------
1. Introduction

The development of the language Pascal is based on two principal aims. The first is to make available a language suitable to teach programming as a systematic discipline based on certain fundamental concepts clearly and naturally reflected by the language. The second is to develop implementations of this language which are both reliable and efficient on presently available computers.

The desire for a new language for the purpose of teaching programming is due to my deep dissatisfaction with the presently used major languages whose features and constructs too often cannot be explained logically and convincingly and which too often represent an insult to minds trained in systematic reasoning. Along with this dissatisfaction goes my conviction that the language in which the student is taught to express his ideas profoundly influences his habits of taught and invention, and that the disorder governing these languages directly imposes itself onto the programming style of the students.


There is of course plenty of reason to be cautious with the introduction of yet another programming language, and the objection against teaching programming in a language which is not widely used and accepted has undoubtedly some justification — at least based on short—term commercial reasoning. However, the choice of a language for teaching based on its widespread acceptance and availability, together with the fact that the language most widely taught is thereafter going to be the one most widely used, forms the safest recipe for stagnation in a subject of such profound pedagogical influence. I consider it therefore well worth—while to make an effort to break this vicious circle.

Of course a new language should not be developed just for the sake of novelty; existing languages should be used as a basis for development wherever they meet the criteria mentioned and do not impede a systematic structure. In that sense Algol 60 was used as a basis for Pascal, since it meets the demands with respect to teaching to a much higher degree than any other standard language. Thus the principles of structuring, and in fact the form of expressions, are copied from Algol 60. It was, however, not deemed appropriate to adopt Algol 60 as a subset of Pascal; certain construction principles, particularly those of declarations, would have been incompatible with those allowing a natural and convenient representation of the additional features of Pascal.

The main extensions relative to Algol 60 lie in the domain of data structuring facilities, since their lack in Algol 60 was considered as the prime cause for its relatively narrow range of applicability. The introduction of record and file structures should make it possible to solve commercial type problems with Pascal, or at least to employ it successfully to demonstrate such problems in a programming course. The syntax of Pascal is summarised in graphical form in the Appendix.

The language has been implemented on the CDC 6000 computers. Pascal 6000 is described by a few amendments included here as a separate chapter to demonstrate the brevity of a manual necessary to characterise a particular implementation."
--------------------------

Thaddy

  • Hero Member
  • *****
  • Posts: 14169
  • Probably until I exterminate Putin.
Re: Compiler extension
« Reply #10 on: December 14, 2019, 09:15:56 am »

The language has been implemented on the CDC 6000 computers.
--------------------------
I fear that platform is not supported by Freepascal.....
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Compiler extension
« Reply #11 on: December 14, 2019, 09:58:47 am »
Maybe he did that for readability, simplicity, elegance or learning purposes...

I believe he did it because of the politics behind the minority report and his resignation from the ALGOL-68 committee.

I'd suggest noting pp43-44 of the edition saved at https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/68910/eth-3059-01.pdf?sequence=1&isAllowed=y which shows comments delimited by /* */ if { } were unavailable in the computer's character set. It appears that Wirth switched to (* *) after noticing that the others were already used in B (a successor to BCPL and precursor to C), and is just one example of his determination to be incompatible with as many other language implementations as possible.

Note here that I'm not knocking Pascal, which is still basically the exemplar of usability to which many other languages- in particular those derived from C- are attempting to revert. However I /do/ believe that Wirth's motives when hurriedly designing it were not the purest: He was furious after the rejetion of ALGOL-W, and was out to break things.

MarkMLl
« Last Edit: December 14, 2019, 12:03:39 pm by 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: 5444
  • Compiler Developer
Re: Compiler extension
« Reply #12 on: December 14, 2019, 11:10:09 am »
Also, this question I have had long time ago in mind but for some reason always forgot to ask any compiler developer (based on open source projects of course): Would it be able for you guys, to make the FPC compiler in such an extend modularised that NON-PASCAL-COMPILER-DEVELOPER can also bring their ideas into existence, for instance:

 as I penetrated you guys 1 year ago with the oxygene topic, to maybe implement some good stuff they have accomplished in oxygene, would it be somehow possible to extend the compiler in such a way, that external developer who are not familar with compilers, may actually create extensions (like for browsers) which extend the fpc compiler and make new features possible, which still doesnt mean, that any new feature should be added instantly to the fpc framework at the end, but just as a consideration, like, implementing for instance, tuples, just letting euphorized ppl develop it when they feel they need/want it and see if they can make itr possible and if they can (which again, fpc should provide then a good "extension-builder-toolset") we can then here in the forum discuss if it should make its way into the fpc.
Short answer: No.
Long answer: marcov already explained some of it.
Also one part of the parser might influence another part (e.g. as generics in Delphi can be ambigous (take the fragment SomeVar<SomeVar2 where SomeVar and SomeVar2 are both variables as well as type names, thus this can both be an expression or a specialization up to this point) they stretch into many parts of the compiler). Thus it would mean quite some effort to invent and implement an infrastructure that would allow the compiler to be extended. Time that is better spent fixing bugs and implementing features that the majority (including the core devs) agree on should be included.

Oh /please/, Marco, don't make light of Brexit: Her Majesty and I, as the two people who subjectively matter, now have to put up with Johnson for an indeterminate number of years. (But I did like the joke about the cat called Brexit, who wakes his owner up every morning meowing to go out but when she opens the door he just stands there, undecided, and when finally pushed out wants to come back in.)
That definitely reminds me of my own cat...  :P

Thaddy

  • Hero Member
  • *****
  • Posts: 14169
  • Probably until I exterminate Putin.
Re: Compiler extension
« Reply #13 on: December 14, 2019, 12:08:17 pm »
Schrödinger? Also known as sfoefi... That was a real cat. Died 2001.
« Last Edit: December 14, 2019, 12:13:33 pm by Thaddy »
Specialize a type, not a var.

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Compiler extension
« Reply #14 on: December 14, 2019, 01:01:16 pm »

The language has been implemented on the CDC 6000 computers.
--------------------------
I fear that platform is not supported by Freepascal.....

No so important. Only one CDC 6000 (designed by Seymor Cray) survived.
It resides at the  Chippewa Falls Museum of Industry and Technology in the Cray collection.

http://www.cfmit.org/


Winni

 

TinyPortal © 2005-2018