Recent

Author Topic: likely bug in variable definitions  (Read 1807 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 12194
Re: likely bug in variable definitions
« Reply #30 on: October 04, 2022, 06:06:48 pm »
That grammar was used internally too and not just for documentation.
Manuals, manuals, manuals first.
You have incompetence and sheer incompetence.

Thaddy

  • Hero Member
  • *****
  • Posts: 12194
Re: likely bug in variable definitions
« Reply #31 on: October 04, 2022, 06:08:47 pm »
You can't build a compiler from that.

MarkMLl
Actually you CAN! But only partially conformant to the actual release Delphi compilers.
You can actually build A Pascal compiler from the BNF that resembles D7.

And that BNF grammar was leading. Some stupid ghosts - management, money - dropped that guidance along the way. Much like Agile causes more problems than it solves..... >:D
Dropping functional design... in favor of spaghetti code.
« Last Edit: October 04, 2022, 06:18:43 pm by Thaddy »
Manuals, manuals, manuals first.
You have incompetence and sheer incompetence.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10392
  • FPC developer.
Re: likely bug in variable definitions
« Reply #32 on: October 04, 2022, 06:17:35 pm »
That grammar was used internally too and not just for documentation.

Folding paper airplanes ?   ;D

y.ivanov

  • Hero Member
  • *****
  • Posts: 554
Re: likely bug in variable definitions
« Reply #33 on: October 04, 2022, 06:24:18 pm »
@PascalDragon
There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att.
It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering.
Reference: appendix A of the Delphi language guide for D7.
I am a bit bemused you are not aware of that? ;)


( At that time, though, most proper Elvises had left the building(s))
Unfortunately not a proper BNF. See e.g.
Code: Text  [Select][+][-]
  1. TypedConstant -> (ConstExpr | ArrayConstant | RecordConstant)
  2. ArrayConstant -> '(' TypedConstant ',' ')'
  3. RecordConstant -> '(' RecordFieldConstant ';'... ')'
Is it :
Code: Pascal  [Select][+][-]
  1. (1,) // can't add more after the comma
a proper array constant?
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

PascalDragon

  • Hero Member
  • *****
  • Posts: 4744
  • Compiler Developer
Re: likely bug in variable definitions
« Reply #34 on: October 05, 2022, 09:06:58 am »
@PascalDragon
There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att.
It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering.
Reference: appendix A of the Delphi language guide for D7.
I am a bit bemused you are not aware of that? ;)

Please read again what I wrote (I know that you like to simply skim posts and only extract those parts that you think are relevant) - emphasis mine:

There never was a formal grammar we began with. And the syntax diagrams that exist are derived from what the compiler supports (and even then some are faulty, because the one writing the documentation didn't find out everything that the compiler itself understands).

Yes, there was the grammar included in the TP manuals, but that does not mean that it was used. (And the syntax diagrams is a reference to our own manuals).

MarkMLl

  • Hero Member
  • *****
  • Posts: 5561
Re: likely bug in variable definitions
« Reply #35 on: October 05, 2022, 09:20:16 am »
Yes, there was the grammar included in the TP manuals, but that does not mean that it was used. (And the syntax diagrams is a reference to our own manuals).

I'm afraid that I get the impression that somebody is unaware that there is a class of tools including YACC etc. that takes a compiler definition as input and spits out a substantial part of a compiler as output. One quite simply can't use a "partially correct, nigh complete" description for automated compiler generation, in the same way that one can't use any other kind of sourcecode in that state.

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: 12194
Re: likely bug in variable definitions
« Reply #36 on: October 05, 2022, 11:58:41 am »
What did I skip? Other way around! Yes, there was the grammar included in the TP manuals, but that does not mean that it was used. (And the syntax diagrams is a reference to our own manuals).
Not TP but D5-D7, and that WAS used. I was there, you know that. I may have forgotten that: Borland used almost always internal tools, also for their flavor of BNF.
E.g: Their IDE parser was built with it. Not after it.... You can ask anyone who was at Borland at the time. They will confirm it.

Note: as I said before, I did only "minor" work with the rtl/vcl and analysis.

But it is definitely a case of the programmers left the parser in the dark.
« Last Edit: October 05, 2022, 12:04:21 pm by Thaddy »
Manuals, manuals, manuals first.
You have incompetence and sheer incompetence.

 

TinyPortal © 2005-2018