Recent

Author Topic: Compiler extension  (Read 4787 times)

Shpend

  • Full Member
  • ***
  • Posts: 167
Re: Compiler extension
« Reply #15 on: December 14, 2019, 05:33:56 pm »
hi, i am happy to see so many interessted in this topic, nice :)

But to the topic: I already assumed that this should be a heavy task, to say the least, even tho, a lot of you guys are negating the implementation-possibility, I am somehow internally very attracted to the idea as also very optimistic that this might be done at some point , although with a proper difficulty surrounding it.  Yea I am not a compiler developer, but you also have to remember,that people who were kinda "prediciting" that we were able to communicate with eachother from like completly different places in earth, within seconds, yea those people got very laughed at and declared mentally ill :D
 (There are dozens of such cases btw)

But atleast I can have the hope to make something like this myself (atleast to start it, and attracting people to it at some point) when I am ready to do so, since again, I need to learn these things still.

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

I would have already started and not asked a question if this is a good idea or not, when I had the knowledge to do so :---D



guest64953

  • Guest
Re: Compiler extension
« Reply #16 on: December 14, 2019, 06:16:58 pm »
Your idea is very unrealistic. The closest thing I could think about should be LLVM, and your extension would be frontends like clang and emscripten... I got a list of LLVM frontends from there, you could check it yourself: https://gist.github.com/axic/62d66fb9d8bccca6cc48fa9841db9241

guest64953

  • Guest
Re: Compiler extension
« Reply #17 on: December 14, 2019, 06:26:03 pm »
About readablility, I don't want to start another holy war but I think we should debunk the theory that Pascal syntax is easier to read and understand than C syntax. I found it another way around. C syntax with [data type] [variable name] is more natural and intuitive than Pascal's [variable name] [data type].

It's: [property] [object], but not [object] [property], e.g: do you say in English a round ball ([round] [ball]) or, a ball that is round ([ball] [round])? Which do you found more intuitive?

At least with me, I prefer the syntax of C. I could read and understand C syntax immediately but having to parse Pascal syntax before I could understand it.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Compiler extension
« Reply #18 on: December 14, 2019, 06:46:50 pm »
I'm ambivalent on the merits of Pascal vs C /syntax/: they're both ALGOL-derived languages, and unlike some (Lisp, Smalltalk, APL) their evaluation order is broadly in line with what's been taught in elementary mathematics classes for the last couple of hundred years.

The /semantics/ of C on the other hand is obscene, with far too many pitfalls for the unwary.

My conclusion about declaration order was entirely based on parsing concerns. If you put the type (or some other kind of template) first it's almost like instantiating a class, you're effectively saying "this is the class, what follows is an implicit instantiation, and the validity (hence length) of the text describing the instantiation is class-specific".

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: 3944
Re: Compiler extension
« Reply #19 on: December 14, 2019, 07:05:41 pm »
I am somehow internally very attracted to the idea as also very optimistic that this might be done at some point
A few languages implement the idea. 

What really matters is, does implementing a feature enable a programmer to create code that is simpler and easier to understand than without that feature ?, for the extensible grammar feature, the answer is clearly: no. 

The reason is very simple, a program that uses that feature, requires the programmer to inspect and understand a dynamically defined grammar then mentally put together how that grammar applies to the problem the program as a whole is attempting to solve.  That's a whole lot more work than dealing with a static grammar whose actions are (hopefully) clearly documented in the language definition. 

IOW, extensible grammars result in programs that use undocumented constructs since their definition is found in only one place: the programs that defines them. 

Extensible grammars are a bit like self-modifying code.  They enable the programmer to do some rather fancy stuff but, they are rather detrimental to ease of understanding.

Academically, they are very interesting, in practice, they really aren't desirable in a program that is easy to understand and maintain.  Not to mention that tracking down a bug resulting from a problem in the dynamically defined grammar can greatly increase the proliferation of the bald gene in the programmer's genetic pool.

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

valdir.marcos

  • Hero Member
  • *****
  • Posts: 1106
Re: Compiler extension
« Reply #20 on: December 14, 2019, 07:10:08 pm »
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.
It's a pity that nobody here had studied or worked with those pioneers to better reconstitute that part of Pascal's history.

https://en.wikipedia.org/wiki/Niklaus_Wirth
https://en.wikipedia.org/wiki/Brian_Kernighan
https://en.wikipedia.org/wiki/Ken_Thompson
https://en.wikipedia.org/wiki/Dennis_Ritchie


Why Pascal is Not My Favorite Programming Language [paper]
Brian W. Kernighan [coauthor of the AWK and AMPL programming languages]
April 2, 1981
http://web.eah-jena.de/~kleine/history/languages/Kernighan-WhyPascalIsNotMyFavoriteProgrammingLanguage.pdf
------------------------
The programming language Pascal has become the dominant language of instruction in computer science education. It has also strongly influenced languages developed subsequently, in particular Ada.
Pascal was originally intended primarily as a teaching language, but it has been more and more often recommended as a language for serious programmingas well, for example, for system programming tasks and even operating systems.

Pascal, at least in its standard form, is just plain not suitable for serious programming. This paper discusses my personal discovery of some of the reasons why.
------------------------

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: Compiler extension
« Reply #21 on: December 14, 2019, 07:27:08 pm »
Why Pascal is Not My Favorite Programming Language [paper]
Brian W. Kernighan [coauthor of the AWK and AMPL programming languages]
April 2, 1981
http://web.eah-jena.de/~kleine/history/languages/Kernighan-WhyPascalIsNotMyFavoriteProgrammingLanguage.pdf

Nice to read.
We've evolved quite a bit since then.

Bart

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Compiler extension
« Reply #22 on: December 14, 2019, 07:51:00 pm »
It's a pity that nobody here had studied or worked with those pioneers to better reconstitute that part of Pascal's history.

I'd suggest that familiarity with Wirth's sourcecode is a good first step, provided that one enjoys walking on broken glass :-)

I've put various historic links in https://wiki.freepascal.org/Make_your_own_compiler,_interpreter,_parser,_or_expression_analyzer#Ancient_history

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

simone

  • Hero Member
  • *****
  • Posts: 573
Re: Compiler extension
« Reply #23 on: December 14, 2019, 08:56:55 pm »

Why Pascal is Not My Favorite Programming Language [paper]
Brian W. Kernighan [coauthor of the AWK and AMPL programming languages]
April 2, 1981
http://web.eah-jena.de/~kleine/history/languages/Kernighan-WhyPascalIsNotMyFavoriteProgrammingLanguage.pdf
------------------------
The programming language Pascal has become the dominant language of instruction in computer science education. It has also strongly influenced languages developed subsequently, in particular Ada.
Pascal was originally intended primarily as a teaching language, but it has been more and more often recommended as a language for serious programmingas well, for example, for system programming tasks and even operating systems.

Pascal, at least in its standard form, is just plain not suitable for serious programming. This paper discusses my personal discovery of some of the reasons why.
------------------------

This article is one of the causes of the underestimation of the pascal language. I note only that it is about the original pascal, not the object pascal. The latter does not have the limitations described in the Kerninghan article, as explained in the following wiki:

https://wiki.freepascal.org/Why_Pascal_is_Not_My_Favorite_Programming_Language
« Last Edit: December 14, 2019, 09:02:48 pm by simone »
Microsoft Windows 10 64 bit - Lazarus 3.0 FPC 3.2.2 x86_64-win64-win32/win64

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: Compiler extension
« Reply #24 on: December 15, 2019, 12:27:06 am »

April 2, 1981
http://web.eah-jena.de/~kleine/history/languages/Kernighan-WhyPascalIsNotMyFavoriteProgrammingLanguage.pdf

Even if you overlook the historic aspect that was already (correctly) mentioned by Simone, in that same period he released books on Pascal:

https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427 (1981, Addison Wesley).





simone

  • Hero Member
  • *****
  • Posts: 573
Re: Compiler extension
« Reply #25 on: December 15, 2019, 10:21:21 am »

April 2, 1981
http://web.eah-jena.de/~kleine/history/languages/Kernighan-WhyPascalIsNotMyFavoriteProgrammingLanguage.pdf

Even if you overlook the historic aspect that was already (correctly) mentioned by Simone, in that same period he released books on Pascal:

https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427 (1981, Addison Wesley).

Again for those who love history: the above book is an adaptation for the Pascal language of a previous book that Kernighan wrote in 1976 using RatFor (Rational Fortran) as language. Curiously he has never written a version for the C language.
« Last Edit: December 15, 2019, 11:21:20 am by simone »
Microsoft Windows 10 64 bit - Lazarus 3.0 FPC 3.2.2 x86_64-win64-win32/win64

guest64953

  • Guest
Re: Compiler extension
« Reply #26 on: December 15, 2019, 01:32:46 pm »
I'm ambivalent on the merits of Pascal vs C /syntax/: they're both ALGOL-derived languages, and unlike some (Lisp, Smalltalk, APL) their evaluation order is broadly in line with what's been taught in elementary mathematics classes for the last couple of hundred years.

The /semantics/ of C on the other hand is obscene, with far too many pitfalls for the unwary.

My conclusion about declaration order was entirely based on parsing concerns. If you put the type (or some other kind of template) first it's almost like instantiating a class, you're effectively saying "this is the class, what follows is an implicit instantiation, and the validity (hence length) of the text describing the instantiation is class-specific".

MarkMLl

Anyway, I still found C is easier to write and understand. It could be because my first programming language is Java  ;)

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: Compiler extension
« Reply #27 on: December 15, 2019, 07:25:25 pm »
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".


This gave me a good chuckle... :)   :D
-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