Gpc April 1997

gpc@gnu.de

24 participants
111 discussions

Relevance of Borland Pascal (was: Standard compatibility)
by Peter Gerwinski 04 Apr '97

04 Apr '97

According to Kevin A. Foss: > > I have to admit I'm in favor of defaulting to ISO standard behavior, but > that is just my personal preference. I'm mainly concerned with the last > comment... is it true that 'thousands of dos-pascal-programs' will be > ported to linux'? Yes. There is an incredible number of Borland Pascal programmers out there. Just watch news://comp.lang.pascal.*: most questions, even those posted to comp.lang.pascal.ansi-iso, concern Borland Pascal. Some of them (~50%???) happily change to Delphi and move to Windows 95 without ever looking out of the (MS-) Window. Some others (which I would consider the best ones;) want to try Linux and are looking out for a Pascal compiler. > I don't see a majority of the DOS-based TP programs > being all that useful, Of course not all of that is useful, but enough to make it worth the effort. In addition: think of games. Not useful, but they can make Linux more attractive. Many games are written in Borland Pascal for DOS. I have heared of game authors who would be happy to have a 32-bit Pascal for DOS. If they see that there is a compiler which supports Linux as well, they will give Linux a try. > or all that many TP programmers perceiving a need to > port their software to gpc. Granted there was a lot of good software > written with TP and which should be ported, but I think your numbers are > over stated. I think these numbers are realistic. (Just what I guess from conversation with other programmers.) > The comment also begs the question. is gpc's role to provide a facility for > porting 10 year old DOS programs or for the creation of new programs? I > would think primarily the latter and that decisions on gpc's defaults > should serve that end. GPC is for the creation of new programs. It should provide facilities to port existing programs (all those --command-line-switches), but this should not become our primary goal. This also guided my decision in favour of a default field width of 0: Most programs written today don't sequentially read in columns of numbers, process them and put out some other columns of numbers. Today's programs process strings and interact with the user; most numbers appear in sentences like Frank's "There are 7 items." Thus GPC's default behaviour should support the latter one; those of us who need the first one (including myself, sometimes) are experienced enough to change GPC's default by configuration, a command-line switch, or even an explicit field width specification. For programs intended to be portable the latter method is the most secure one anyway. Greetings, Peter

1 0

Standard Compatibility: my plans
by Peter Gerwinski 04 Apr '97

04 Apr '97

Hi, everybody! Here are my plans for GPC's default `write'/`writeln' behaviour: * I will fix that bug which suppresses output when the field width is 0. * String clipping will be ON by default, thus GPC will follow ISO and UCSD, not Borland. It can be switched OFF either with `--borland-pascal' or `--delphi', or with a separate switch `--no-clip-strings'. * Field widths are 0 by default. This does comply to the ISO Standard Specifications AND corresponds to the behaviour of UCSD Pascal, Borland Pascal, and other PC Pascal compilers. This default can be changed using `--field-widths=12,24,6' (for Integer, Real, Boolean fields) which can be given either when compiling a Pascal source file ("locally") or when configuring GPC (making the default widths "global" for a site). * Although default field widths of 0 are correct by ISO, there seems to be a de-facto standard among ISO Pascal compilers that field widths must ensure at least one blank in front of Integers and Reals. For this reason, `--standard-pascal' and `--extended-pascal' will imply default field widths which will make GPC behave like other ISO Pascal compilers. * If `--field-widths' is given without arguments, it will make the field widths big enough to ensure at least one blank in front of numeric values. * I will try to make it possible to pass these command-line options as compiler directives, e.g. (*$field-widths=12,24,6*). Having this, you can write programs which will behave independently of command-line options given to the compiler. This possibility will also cover most applications of a "GPC configuration file". Okay, this will take some time to finish. I hope that everybody can live with this. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Objects and GPC
by Peter Gerwinski 04 Apr '97

04 Apr '97

Hi everybody, hi African Chief! It seems that I am no more the only one who uses Objects. :-) According to The African Chief: > Using the latest GPC alpha (9704), I find that I cannot > import objects from a unit. I originally had the source > for TObject (below) in a unit, and used the unit in > this program (test.pas). I had compile errors all > the time. That's strange because when I put TObject below in a separate Unit everything compiles fine. However the resulting code is buggy. :-( I will investigate this. Did you recompile the Unit? The GPI file format changes with every new alpha GPC. > Then, I put the object's source into test.pas > itself, and it compiled. But when I tried to create > a descendant object (NewObj), as seen in the > source below, again, I had compile errors - > complaining about the "initializer element" for > some of the methods not being "constant". I see. You have detected a bug ... even two bugs. Thanks for reporting them! > Can anyone tell why this source does not compile, > even with the -borland-pascal flag? The `--borland-pascal' switch has no effect on this. You do not need to enable Objects, but vice versa, if you specify one of `--standard-pascal-level-0', `--standard-pascal', `--extended-pascal', or `--ucsd-pascal', you *disable* OOP. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Small success!
by The African Chief 04 Apr '97

04 Apr '97

Ahem ... I have now discovered the reason why I could not import my object from a unit (there was no .o file!). Using "--automake" ensures that the .o file is created, and the object imports okay. However, the problem still exists with creating a descendant object. I can now (magically) create one (if the parent object is in a unit), however, if I try to create a new constructor, any call (inside the new constructor) to the ancestor constructor (e.g.., "Inherited Init") causes a GPF ! The parent object is now in a unit, but the descendant object is in the main program. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

GPC for HP3000
by Achim Kalwa 04 Apr '97

04 Apr '97

Hello out there! I'm looking for GPC ported to HP3000 systems (PA-RISC cpu). At the office, i have access to two HP3000 machines, but no developer tools. As I'm pascal programmer, i would like to have a compiler on that machine(s). But prior to buying the HP pascal compiler, it would be nice to see if my ideas would work and to get a feeling for the performance. Did someone the port successfully and has a binary "distribution"? Or are there other "free" Pascal compilers fpr HP3000? Thanks in advance Achim achim.kalwa(a)do.netsurf.de

2 1

Objects and GPC
by The African Chief 04 Apr '97

04 Apr '97

Hiya! Using the latest GPC alpha (9704), I find that I cannot import objects from a unit. I originally had the source for TObject (below) in a unit, and used the unit in this program (test.pas). I had compile errors all the time. Then, I put the object's source into test.pas itself, and it compiled. But when I tried to create a descendant object (NewObj), as seen in the source below, again, I had compile errors - complaining about the "initializer element" for some of the methods not being "constant". Can anyone tell why this source does not compile, even with the -borland-pascal flag? It compiles and runs okay with BP7 and BPW. Thanks! { ---- cut -----} Program Test; {$define debug} Type pObject = ^TObject; ChildPtr = pObject; TObject = Object Parent : pObject; Child : ChildPtr; Name : String[255]; Handle : integer; { BP } Constructor Init; Destructor Done;virtual; { Delphi } Procedure Free;virtual; {calls Destroy} Destructor Destroy;virtual; Constructor Create (aOwner : pObject); End; { TObject } Constructor TObject.Init; Begin Parent := Nil; End; { TObject.Init } {////////////} Constructor TObject.Create; Begin Parent := aOwner; End; { TObject.Create } {////////////} Destructor TObject.Done; Begin Handle := 0; Name := ''; Parent := Nil; End; { TObject.Done } {////////////} Destructor TObject.Destroy; Begin Handle := 0; Name := ''; Parent := Nil; End; { TObject.Destroy } {////////////} Procedure TObject.Free; Begin {$ifdef debug}Writeln ('Free!');{$endif debug} Dispose (pObject (@Self), Destroy); End; { TObject.Free } {////////////} Type PNewObj = ^NewObj; NewObj = Object (TObject) Constructor Create (aOwner:PObject); End; { NewObj } Constructor NewObj.Create; Begin Inherited Create (aOwner); Name := 'Object Number 2 is a Child!'; Handle := -40; End; { NewObj.Create } { Program() } Var ThisObj : TObject; Begin Writeln ('Hello World!'); ThisObj.Init; With ThisObj do begin Handle := -1; Name := 'Object Number 1'; Child := New (PNewObj, Create (@ThisObj) ); Writeln ('My handle = ', Handle); Writeln ('My name = ', Name); Writeln ('Child handle = ', Child^.Handle); Writeln ('Child name = ', Child^.Name); Writeln ('Child PARENT handle = ', Child^.Parent^.Handle); Child^.Free; Done; end; { With Ob^ } Writeln ('Hello World Number 2 !!'); End { Program() }. { --- end cut ---} Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Two bugs
by Stephen Lindholm 04 Apr '97

04 Apr '97

These two should not compile, and indeed, do not compile under other compilers. program temp; var a = 1 .. 2; type b: a; begin if 1 then b := 0; end. 1 is not a boolean, yet it is accepted as boolean. b is initialized to an out-of-bounds value.

1 0

Standard Compatibility (was: New Alpha)
by Peter Gerwinski 04 Apr '97

04 Apr '97

According to Phil Nelson: > According to myself (Peter Gerwinski): > > (*** Does anybody know how UCSD behaves here? I don't want to dig > > out my old Apple //e in order to check this. ***) > Yes, it clips strings and it has a 10 for the default field size. Meanwhile I digged out my UCSD Pascal *documentation*, and it says that UCSD Pascal has a default width of 1, but it clips strings. I did not verify this on the Apple //e, but if the default width would have been something different from 1, I would remember it now. > Borland is the only Pascal compiler that I have used or heard of that does > not clip strings and uses 1 as the default field size. Does someone > know of another one (besides gpc)? Yes, almost every Pascal compiler I know for the PC. I checked it for FPK Pascal and Virtual Pascal: Both have a default width of 1 and don't clip strings. I cannot check it now, but I am sure that Speed Pascal, MS Quick Pascal, and TMT Pascal behave in the same way. Anyway, we should count programmers and source lines, not compilers. AFAIK Borland Pascal has more users than all other existing Pascal compilers together. This does, of course, not mean that Borland's way is the best one, but it means that we must not ignore Borland Pascal. > >The above does not clarify how GPC's default behaviour should be. > It should be ISO Pascal with the de-facto-standard field widths. Why? > >IMHO Borland's method is more logical than what most Standard Pascal > >compilers do. > It may be more logical, but we didn't design the language. We *are* designing a language. I already wrote some weeks ago: It is desirable to comply to existing standards, but I don't consider this compliance as an end in itself. [...] The current design of GPC is to integrate the good features from the many existing Pascal standards, and you can restrict GPC to these standards using compiler switches: --standard-pascal-level-0 Should work --standard-pascal Do conformant arrays work now? --extended-pascal Not yet fully implemented --object-pascal Just started --ucsd-pascal Almost complete --borland-pascal Almost complete --delphi Just started --pascal-sc Just started The default should be the most powerful easy-to-use and easy-to-understand compiler which can be constructed out of these standards plus GNU extensions. This is in the spirit of GCC; `info gcc invoking "warning options"' says: We recommend [...] that users take advantage of the extensions of GNU C and disregard the limitations of other compilers. Aside from certain supercomputers and obsolete small machines, there is less and less reason ever to use any other C compiler other than for bootstrapping GNU CC. If it is possible to have something better (in this case: more logical) than most Standard Pascal compilers, this better solution should be the default, and there must be a compiler switch to emulate those other compilers. And, anyway, we are talking about a default width of 1, not about string clipping, so this would not even violate the ISO Standard. > [...] > I can not live with either being the standard behavior. If you do make > Borland behavior standard, at least make it a configure option to not > make Borland behavior standard so I don't have to maintain local changes > to gpc to get what I really want. Similarly, if you choose to make > Standard Pascal the default behavior, have a configure option to choose > Borland for those who want it. Better yet, make gpc change depending > on whether it is run as gpc (Standard Pascal) or bpc (Borland Pascal). I never intended to make GPC's standard behaviour to emulate Borland Pascal, but I also don't intend to restrict GPC by default to the ISO Standard. GPC shall be something superior to both Borland Pascal and ISO Pascal. It is a very good idea to make GPC's behaviour depending on the name it is invoked with. What about the following: pc ISO 7185 Standard Pascal compiler epc ISO 10206 Extended Pascal compiler bpc Borland Pascal compatible compiler ... (other de-jure or de-facto standards) gpc Integrate all good features (not the misfeatures) of these standards in one compiler. People who need compatibility to other ISO Extended Pascal compilers will invoke GPC as `epc' and will not notice any Borlandish behaviour. (If they do, the may report it as a bug.) Vice versa, those who want a "32-bit Borland Pascal" will call GPC as `bpc'. Those who call GPC as `gpc' will profit from both (and more) dialects. One typical example is to allow components of structured variables as `for' loop control variables (according to Borland). This is a harmless extension to the ISO Standard - nobody will use this unintentionally -, so `gpc' will accept it. (`epc' will not.) Now we can combine this with Extended Pascal's set member iteration (to be implemented soon): for i [ k ] in [ 2, 3, 5, 7, 11 ] do ... I intend, for example, to combine Extended Pascal's schema types with Borland Pascal's object types. > > * When an Integer value is being output with a field width of zero, > > output is suppressed. Is this ISO Standard (doesn't seem so), > > or a bug? > > This is not conforming and needs to be changed. It should be the same as 1. Okay, I will be happy to change this. > > * When a Real value is being output with a too narrow field width, > > other compilers bother to make the output as short as possible. > > Should GPC do the same? > > It should follow 6.9.3.4.1 (ISO 7185) [...] Okay, I'll take care of that. (Although I wouldn't mind if somebody else would hack the runtime library for such things, so I can face schema types instead ...) > > [blank in front of Reals] > > Yes, they are following the standard. I have no problem with the switch > as long as it is not standardly on. Okay. It will be "off" by default. > Is it possible we should ask Juki what the standard behavior should be? > Borland vs Standard? Since Juki is on this list, he should read all this. Hey, Juki, what's your point of view? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Standard Compatibility [was: Re: New Alpha]
by Kevin A. Foss 04 Apr '97

04 Apr '97

On Thu, 03 Apr 1997 18:52:18 +0200, Sven Engelhardt wrote: >gpc really shall default to borland/turbo-pascal behaviour. You could >implement reading ~/.gpcrc to change that. (For ease this could be done >with a shell script) The cause ain't 'standard' performance, as >thousands >of dos-pascal-programs will be ported to linux. I have to admit I'm in favor of defaulting to ISO standard behavior, but that is just my personal preference. I'm mainly concerned with the last comment... is it true that 'thousands of dos-pascal-programs' will be ported to linux'? I don't see a majority of the DOS-based TP programs being all that useful, or all that many TP programmers perceiving a need to port their software to gpc. Granted there was a lot of good software written with TP and which should be ported, but I think your numbers are over stated. The comment also begs the question. is gpc's role to provide a facility for porting 10 year old DOS programs or for the creation of new programs? I would think primarily the latter and that decisions on gpc's defaults should serve that end. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

[sad@utkux.utcc.utk.edu: Re: Standard Compatibility [was: Re: New Alpha]]
by Phil Nelson 03 Apr '97

03 Apr '97

From: sad(a)utkux.utcc.utk.edu Subject: Re: Standard Compatibility [was: Re: New Alpha] To: phil(a)cs.wwu.edu (Phil Nelson) Date: Thu, 3 Apr 1997 13:51:03 -0500 (EST) In-Reply-To: <199704031835.KAA01150(a)fawn.cs.wwu.edu> from "Phil Nelson" at Apr 3, 97 10:35:05 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > It should not be arbitrary! It should be large enough so MAXINT will > have at least one blank in the field. So in this case, gpc should have > the numbers depend on the MACHINE data type. Choose something like > the number of digits in MAXINT + 1 to be the default integer field size. Agreed, this is nice for number crunching (much like Fortran handles generic write(6,*)) and hence I'd prefer it to default to that. It is not so nice when you want to do fancy stringish output stuff, so I'd think there should be an option (compiler or even better, runtime) to switch to left justified output where so desired. Cheers. Stefan ======================================================================== Stefan A. Deutscher | (+1-423-) voice fax The University of Tennessee, Knoxville | UTK : 974-7838 974-7843 Department of Physics and Astronomy | ORNL : 574-5897 574-1118 401, A. H. Nielsen Building | home : 522-7845 522-7845 Knoxville, T.N. 37996-1200, USA | email: sad(a)utk.edu ========================================================================

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc April 1997