I need a complete Object Pascal syntax (preferably Delphi 2009). Some of the syntax is given by the help files, but not all information is provided. So I started collecting loose bits of information. Recently I added these to a more or less complete syntax description (EBNF like).
Although it looks extensive, there are still bugs and I'm sure parts are missing (specially in the .NET syntax). So I'm asking the SO Delphi community. Do you have any information or can you correct the errors? In return I provide the complete syntax to the community. It probably saves you some time ;-).
In the future, I like to do the same for other languages (Like C#/C++/Java).
The syntax description I already have is given: My Syntax sofar. Or if you like a Text version. (The XHTML is generated from the text version).
Please note that the syntax focusses on the syntactical part, because the lexical part is not really a problem.
Update
I have a new version of the Delphi Syntax. html version. It includes al versions including 2009. Prism extentions are still on the todo list. And I'm not sure if I'm going to keep them together.
For the real purists, it also contains the full assembler code (which does not support the full 100% of the intel set but only a few instructions are missed.).
Try this: DGrok - Delphi grammar
There is no complete, published syntax for Delphi. Bear in mind that .net and win32 delphi have different syntaxes.
This project has hand-build Delphi parser in it. And lots of test cases of code that compiles but pushes the limits of the syntax.
Delphi 7's grammar is in the back of the Object Pascal book.
You mean for a few thousand dollars they don't even send you that? Do they even send you a 6' x 6' poster?
This might be a good help. It is the parser used in TwoDesk's Castalia.
What exactly are the bugs and functionality you're missing?
From scanning over your document, it seems you mingle syntax and semantics. I do not understand why to distinguish between SimpleTypeFloat and SimpleTypeOrdinal on a syntactic level, or code operator precedence as syntactic feature in AddOp and MulOp. true, false, nil are identifiers just as any variable name you choose.
You could always read the source to the Free Pascal Compiler. It supports Object Pascal.
Related
We have large commercial app that we want to convert from Delphi 6 to 2010. Approx 10 3rd party component sets, all with source code... I have heard warnings about Unicode with 2010 - Does anyone have experience and or suggestions?
There are many resources available that you can read and that you will assist in the migration from Delphi 6 to Delphi 2009/2010 (Unicode).
You can use these articles as a guide.
Unicode Migration Statistics Tool (This utility will hopefully assist you in collecting useful statistics
on how hard (or not) it would be to migrate your older applications to
Unicode.)
Delphi 2009 and Unicode
Delphi 2009 strings explained by example
Upgrading a major project to Delphi 2009
Delphi and Unicode
Dr. Bob Delphi 2009 Unicode
Delphi 2009 - Unicode in Type Libraries
On Strings and Unicode in Delphi 2009
Delphi in a Unicode World Part I: What is Unicode, Why do you need it, and How do you work with it in Delphi?
Delphi in a Unicode World Part II: New RTL Features and Classes to Support Unicode
Delphi in a Unicode World Part III: Unicodifying Your Code
CodeRage 4 : Using Unicode and Other Encodings in your Programs
Bye.
You'll find some useful answers in these StackOverflow questions:
Move project from Delphi 3 to Delphi 2010
When and Why Should I Use TStringBuilder?
Convert function to delphi 2009/2010 (unicode)
Unicode problems with Delphi 2009 / 2010 and windows API calls
Also, for what it is worth, I purchased Marco Cantu's Delphi 2009 Handbook. It was all I needed to make a relatively smooth converstion from Delphi 4 to Delphi 2009 in only a few weeks.
I do, however, recommend that you ensure your 3rd party packages have a Delphi 2009 upgrade, or you may have some real difficulties. Converting your own code is one thing. Converting someone else's is another.
I use two 3rd party packages, both with source code. Both had upgrades available, and the developer of one of them wrote that he had a lot of trouble upgrading his very complex component to the Unicode of Delphi 2009. It took him a few months, but he completed it. And as a result, I had little trouble with my implementation of his component when I did my upgrade.
i've been in the same circumstance recently. you mostly need to pay attention to the "edges" of the app. INI files, file I/O, log files, etc. win API calls from delphi work since they've now connected the unicode API calls instead. check each 3rd party component set to make sure they're at least ready for Delphi 2009...better yet 2010. even my use of databases simply wasn't an issue...nearly everything worked right away. it just wasn't a big deal. anything that relies on the size of a character should be reviewed.
really the transition of most concern is 2007_or_earlier --> 2009_or_later.
there are plenty of discussions/blog entries about it. you could read, read, read...or you could get started & see what happens. (i did some of both). i'm sure there are "stack overflow" issues discussing your question. i'm not pretending to give a detailed description of what could happen.
it's simply not as scary as it sounds.
Approx 10 3rd party component sets, all with source code.
One thing I'd add is if the component doesn't support Delphi 2009/2010, don't try to upgrade it by hacking the code.
Following is what I posted on How do the new string types work in Delphi 2009/2010?:
See Delphi and Unicode, a white paper written by Marco Cantù and I guess
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), written by Joel.
One pitfall is that the default Win32 API call has been mapped to use the W (wide string) version instead of the A (ANSI) version, for example ShellExecuteA If your code is doing tricky pointer code assuming internal layout of AnsiString, it will break. A fallback is to substitute PChar with PAnsiChar, Char with AnsiChar, string with AnsiString, and append A at the end of Win32 API call for that portion of code. After the code actually compiles and runs normally, you could refactor your code to use string (UnicodeString).
I must add this article from Carey Jensen to others mentioned. It is labeled: "Delphi Unicode Migration for Mere Mortals: Stories and Advice from the Front Lines" (in english).
http://www.danysoft.com/free/delphiunicodemigration.pdf
As you can see in the title of it, you will find many experiences and hints and tips. I think it is the answer to your question. After carefully read it, you will sure knows what to do next. :)
Found in: http://www.danysoft.com/productos/migrar-aplicaciones-a-delphi-xe-o-cbuilder-xe.html
Another point to take care of, is the usage of Variant types with strings and the VarType function testing for strings: one needs to use varUString instead of varString.
Assuming AValue is of type Variant and has being assigned a Unicode string value, the following won't work:
if VarType(AValue) = varString then ...
and needs to be changed to
if VarType(AValue) = varUString then ...
I need to parse Delphi .pas files to work with classes with read/write ability. Adding/Modifying/Deleting fields, properties, methods etc. Any idea how to implement this? The implementation is not necessarily in Delphi, scripting languages are also allowed.
There is the Castalia Delphi Parser by Jacob Thurman currently hosted on GitHub.
CnWizards have built-in syntax highlighter so they use some parser too, but I do not remember which exactly. You can look into their sources at https://github.com/cnpack/cnwizards
PasParse is good for you ! Delphi port of the excellent (C#) DGrok.
Delphi 2007 level.
I'm pretty new to Delphi and I'm trying to use the DEHL Collections library. (see http://code.google.com/p/delphi-coll/ ) I'm have a little trouble with it from the IDE perspective. It compiles and runs correctly, but Delphi XE shows errors anywhere I use the HashSet library. The biggest grievance is that is prevents me from using code completion.
The first location I get the error is in an object declaration:
uses
SysUtils, Windows, Collections.Base, Collections.Sets, Collections.Lists,
adscnnct, adstable,
uOtherClass;
type
OneClass = class(OtherClass)
private
_bad: THashSet<string>; // THashSet underlined
_good: TList<string>; // No problems
end;
The error states: "Type arguments do not match constraints"
I don't think it's configuration as I can use TList just fine, but here is how I set it up: I've copied the library to Projects/Libs/DeHLCollections/Library and compiled the library to Projects/Libs/bin. I've included the bin directory in my global library path, which got it to compile and run. I have tried adding everything (/libs, /DeHLCollections, /Library) to it as well in hopes of getting the IDE to help me out, but it doesn't seem to be helping.
Anyway to fix this, or do I just have to deal with it?
Using DeHL Collections version 1.1.1.119
Welcome to the troubles with using Generics laden code. DeHL and generics work a lot better in Delphi XE than in any previous Delphi version, but that's not the same as it "not having any problems". The problems I experience are exactly like yours.
My opinion is that DeHL shows every sign of having been written by a master delphi programmer, and that it's a thing of beauty, in some ways. It's also a source of great pain, through no fault of its own.
Delphi contains not one or two, but at least three (maybe four?) separate parsers, including the full compiler parser, and a few IDE-parsers used for things like Error Insight (the errors you see even before you build) and the code completion data parser. Each has different language support limitations with regards to generics. It is possible perhaps that DeHL could be written to avoid parser problems with all the various Delphi parsers. I have not seen a guide ever written that shows the limitations, but I wouldn't be surprised if complex type declarations in the form TSomething<TSomething<ISomethingElse>,TBar<IFoo>> breaks more than a few of those parsers.
If you intend to use Generics very heavily, you may as well turn off Code Completion and Error Insight. You might also want to save often, and be prepared to experience a lot of compiler problems. And don't try to compile generics-heavy code and put it in packages either. I have experienced a lot of URW and AV (internal compiler faults) when I write generics based code. I find that the Delphi compiler team is great at fixing whatever gets reported, but that the Generics are really most stable for me when I restrict myself to using the Generics.Collections that come with Delphi, and not using other generics based code. It seems it is possible to write stuff using the generics features, that the IDE and two-way tools, and code-completion is not yet fully ready to handle. That means, phenomenal cosmic Generic powers come at a cost to the classic RAD IDE productivity features.
That being said, the latest DeHL sources from Subversion work fine for me and build and run with no errors, but the most recent source ZIP of the entire DeHL collection had problems for me.
I expect that over the next few releases of Delphi, whatever issues have been found (and DeHL seems to be a great place to push the boundaries, and that's one of the reasons i'm a big fan of it) will be fixed, and you won't be wondering why heavy-generics break your IDE features, because they'll all be working again.
Today I happened to compile, using Delphi 7, a code with a class definition like this
type TAudioStream = class helper of TStream;
and, to my astonishment, the compiler spits
"System unit out of date or corrupted: missing 'TClassHelperBase'".
It looks like Delphi7 has already some reserved usage of the helper word.
Delphi introduced Helper classes in Delphi 8. They were intended for binding VCL to .Net. So, is Delphi7 prescient?
I'm not sure if this a real question. Reservation of keywords for future implementation is a common practice. The roadmap and the planned features for Delphi 8 should be specified at the release date of Delphi 7. So yes, I think Delphi 7 is prescient in this case.
Remember that Delphi 7 included the ".Net preview compiler." Delphi 7 was aware of some upcoming features, and evidently, it was even somewhat aware of the implementation of those features — it knew enough to expect certain things to be in the System unit and to complain when they weren't present.
It is quite common for language designers to reserve certain words for future use. class and interface, for example, have been reserved words in JavaScript for … what, ten years now … even though they aren't expected to be used for another couple of years. goto is a reserved word in Java, even though it is never expected to be used.
It is also quite common for compiler writers to implement features for future use. Generics, for example, were already implemented in Sun's Java 1.2 javac compiler, even though they weren't added to the language specification until Java 5.
Delphi 6 is pretty old, I know. Unfortunately there are reasons why I can't upgrade which I don't want to get into here.
My problem is that it's hard to read code. I have the Castalia plugin which helps a bit (parenthesis matching, shows blocks of if, else, end) but it doesn't highlight the syntax like other IDEs do (variables, constants, procedures, etc.) in different colors. It also doesn't show the IFDEF blocks which can be very confusing at times.
For Delphi 6 what plugins can do some or all of these features?
CnPack will work on Delphi6, and it highlights {$whatever} symbols.
http://www.cnpack.org/index.php?lang=en