Gpc

gpc@gnu.de

5400 discussions

Promised unit "paper"
by Grant Jacobs 14 Mar '03

14 Mar '03

Well, I promised that I'd write up a brief account of what I really meant. Unfortunately I'm going to have to let it slip a little as I am extremely busy. Hope this rushed effort make its clearer, not more confusing! Looking at it briefly, if anything its redundant as all this seems to have already been covered, but all the same... I did promise more examples, which I have to admit I'm out of time for... maybe another week. Anyway, on with the show. A. Layout. Basically identical to BP units: unit DemoUnit; interface uses whatever; <export declaration part> end. implementation uses whatever, somemore; <definition part> end. The difference lies in the way the elements are used, not the syntax. Because of this, I suspect if this were to be implemented, a compiler switch such as the one Chief suggested would be appropriate. No new keywords, Frank! ;-) There are no different types of uses clauses; they always do the same thing: import stuff. The difference is what happens once the stuff is imported. The implementation doesn't import the interface, it only checks against the interface's declaration part. So it has to import its own stuff for itself; more on that in a mo'. B. Independence of action of the interface and implementation sections Firstly, let's clarify the flow of information of interface and implementation sections as this seems to have caused confusion amongst some people. Conventional units effectively work such that the declarations in the interface are imported into the implementation section of the same unit. Here, interface exports all of its contents to other units. Its declarations are *checked* against those of the implementation section. The implementation section has its own definitions; it does not import those from the interface for its use. As a consequence, it does not import the uses present in the interface section. Right? You *could* have the declarations in the interface imported as in BP units, but I believe it works best - for these types of units - if the two are more-or-less independent, bar the checking of the declarations. If you do have the implementation import the stuff from the interface, you now are asking for trouble with the uses clauses. Each section separately imports (uses) any other units that they need. This isn't checked across the interface/implementation boundary; only the declaration part is. *Everything* in the interface is exported, including any imported units (via uses). One rule, no exceptions. The interface section is a container saying that "these things ought to be exported". Everything in the implementation section is private. An interface is free to import (and hence re-export) any unit it feels relevant. It could for example import a related unit which is not needed in the implementation of the current unit, but which is useful for the users of the current unit in some way. The interface section will, of course, have to import the units needed to satisfy the declaration part of the interface. This has the effect that users of the current units get these dependencies "for free". This can work well, provided that developers of lower-level units don't place a lot of things into the interfaces that really aren't needed to be there - which they ought not to be doing anyway. Put in another way: the current unit's interface looks after the "required definitions" on behalf of any users of the current unit by exporting those that are needed. (To do this with more control - a good thing I think - you really need the ability to import only subsets of an interface.) We've already discussed how this can shield higher-level units from re-organisation of code in lower-level units. The implementation is free to import units it needs that are not needed to satisfy the interface declaration part or needed by the user of the current unit. It could, for example, import units which are effectively private to the implementation of the current unit, such as one we decided to bundle all system-dependent elements into or a unit with some obscure internal manipulations which are necessary for the implementation but really ought to be hidden from higher-level units. Because of the way things work, there will almost always be a uses in both the interface and the implementation, unlike in BP units where you can use only only one uses in the interface section and rely on the implementation section picking this up. Having the uses in the interface imported by the implementation imposes restrictions on the interface and if you left things that way the idea of re-exporting interfaces of imported units would awkward. I think this is where some people's early complaints of "re-exporting everything" come from (i.e. they are thinking of a single uses in the interface section importing everything needed for both the interface declarations and the implementation. I wouldn't want all the stuff for the implementation section re-exported either and with the two uses you don't have to.). You really need the interface and implementation sections to be more independent and you need a uses clause in both (so that they are independent) to make this work well. You could mimick the equivalent of the BP uses situation, by allowing the result of a uses clause outside both the interface and implementation sections to be 'read-only' to both sections, but personally I think this could be confusing - ? (You might have problems if the interface and implementation are placed in two separate files - haven't got time to think about this right now.) I'm really not sure what to do about the possibility of a uses clause outside of both sections, but it strikes me as being inconsistent with the rest of the approach. While you could introduce an export clause of some sort, they aren't really necessary under this scheme and it seems easier on the programmer to just remember that everything in the interface is exported, including what is brought in through uses. Its a simple enough rule. And no new syntactic elements, Frank! (But perhaps some of the behaviour differences are annoying instead?) BTW, I don't have experience with use of several interfaces for one module as Frank mentioned in a earlier post (he says this is possible in EP). If anyone has any comments on this, I'd be happy to hear them. Not recommended in general, but on rare occasion useful - you can allow users to optionally relax the type checking across the interface/implementation barrier (comparing the implementation's definitions to declaration part of the interface) to allow explicit recasting of types for the rare occasions this is useful. This isn't possible if the interface is imported into the interface section. Not exactly a feature to rest a debate on, though ;-) The inheritance is the key thing; this is just a minor aside. C. Circular references. Skating out on thin ice here... If a unit's interface has already been imported, a re-importing of it is redundant (unless you allow importing only parts of an interface, but let's keep this simple for now). This ought to be able to break the deadlock -- ? Ditto for the initialisation code. I have to get back to work, so this is where I stop. Sorry... or perhaps you're grateful?! ;-) Cheers, Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents.

4 8

--pack-struct
by Adriaan van Os 13 Mar '03

13 Mar '03

We are running into a real problem while porting the Apple Pascal Interfaces to gpc. Consider the following record definition: type word16 = cardinal( 16); word32 = cardinal( 32); rec = record a: word16; b: word32 end; For binary compatibility, the size of the 'rec' type must be 6 rather than 8. Section 7.2.16 of the gpc manual reads as follows: "GPC by default aligns fields of records and arrays suitably for higher performance, while BP doesn’t. If you don’t want the alignment (e.g., because the program relies on the internal format of your structures), either declare the relevant structures as ‘packed’ (which BP also accepts, but ignores), or give the ‘--pack-struct’ option." Now, the problem is: (1) --pack-struct doesn't seem to be available as a source code compiler option. (2) adding 'packed' to records makes it impossible to pass any field of the record as an actual 'var' parameter. For these two reasons I have an urgent feature request, which is to make --pack-struct available as a compiler option that can be added to the Pascal source code. Regards, Adriaan van Os

7 20

Re: Pascal compilers for/from Apple [was: Promised unit "paper"]
by Tom Verhoeff 12 Mar '03

12 Mar '03

Adriaan van Os wrote: >Frank Heckenbach wrote: >> I might be a little confused about the Pascal compilers by Apple >> and/or for Mac, since I've never used one of them myself. > >Yes, it is confusing, so I have listed the Pascal compilers for >Macintosh that I know of: I miss the UCSD Pascal system that ran (very well) on the Apple ][. I believe it was based on Wirth's p-system, producing p-code. It had a text-based UI with menus. A typical prompt looked like Program-name: C(ommand1, C(ommand2, ...: Because almost all the system software was written in UCSD Pascal as well, the language had been extended with numerous facilities for writing efficient system software. Many of these Pascal extensions have survived in one form or another. We had a large group here in the Netherlands that did wonderful things with this system on homemade Apple ][ clones. These had been extended with 1 MB RAM disks (lightning fast). There were no hard disks at that time; only the slow 5.25" floppies for your OS, tools, and program and data files. I still have such a machine in my attic, but I have not tried to boot it in a very long time. Tom Verhoeff

6 6

Re: Dynamic array sizes
by Wood David 12 Mar '03

12 Mar '03

Adriaan van Os wrote: > > (1) What about this: get a pointer to the first array element > and then > clear sizeof-array-element * array-size bytes ? > > (2) With modern risc processors, the time delay for > operations on large > data sets is typically in memory stalls, not in processor > instructions. > Are your records densely packed or unaligned on the processor's > "natural" data bounds ? Did you actually try to zero the > array in a for > loop per record (with a low-level routine if you want) ? Did you > profile the software ? Thanks Adriaan (and Frank) for your comments. I'm pleased to say I've sorted out all my problems (and successfully converted another 15000 lines of DEC Pascal to gpc with approx. 2000 line changes to get around DEC specifics - mostly the use of x:= ZERO to clear anything). You're right - execution time wasn't the key issue. It was more to do with the fact that I had various records with > 10 components, each element having a unique array type. So working out the size of each record was tedious and zeroing with loops meant coding lots of sub-loops for the arrays within the records. I have effectively adopted approach (1), which is in line with the fact that my_dyn_arr^ points to the first array element already. But for simplicity, I support Frank's suggestion that in future gpc releases, my_dyn_arr^ points to the start of the whole schema so I can do `FillChar' on sizeof(my_dyn_arr^) and then `Initialize' . However, is it really true that a floating point 0.0 isn't always all zero bytes? Regards David Wood. The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

4 7

Re: gpc-20030209
by Prof A Olowofoyeku (The African Chief) 12 Mar '03

12 Mar '03

On 12 Feb 2003 at 05:45, Frank Heckenbach wrote: > > > But it should be possible with moderate effort to implement > > > something like > > > > > > export Foo = all (FileMode => GPC_FileMode); > > > > > > so one won't have to name all interface declarations, but only the > > > re-exports and renamings explicitly. > > > > Ok. I'd rather not touch any EP stuff (e.g., modules) at all. > > However, if that is going to be the only realistic option, then I > > guess it would have to do ... > > Even when QI will work sometime, I think export renaming is still the > better solution (shorter to write, and a little more efficient), so you > might as well get used to it. :-) > > As I said, the problem currently is that the syntax given above > doesn't work yet, but you'd have to name all regular exports in the > `export' clause as well. > > Any opinions (also from others interested) on whether I should add > this feature, and if so, with the syntax above or differently? I can't see many responses to this, so perhaps I am the only one who needs it. The syntax that you suggest above is quite fine by me. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

2 1

gpc with gdb
by Mehdi Khaldi 11 Mar '03

11 Mar '03

Hi, I want to debug my pascal program with gdb. I can't examine my variables when I run my program in the debugger. Nevertheless, I compile with gcc -gstabs foo.pas and I got that : Line number 0 is out of range for "<implicit code>". list foo.pas:1 (xxgdb) p d $1 = 42 (xxgdb) break 5 Breakpoint 1 at $120002948: file foo.pas, line 5. (xxgdb) run Breakpoint 1, pascal_main_program () at foo.pas:5 (xxgdb) p d $2 = { i = {0, 1076887552}, d = 16 } How to get value at all the time???? Thanks

2 1

updated pascal editor
by Russell Whitaker 11 Mar '03

11 Mar '03

Hi About a year ago submitted a pascal editor to the list. Attached is an updated version. Most of the changes are in the search section. One improvement I think you will like: added a "Identifier" option to the search menu. This checks the character just before, and the character just after, (if any), to see if they are not in [ A..Z, a..z, 0..9, _ ]. Handy for searching for a short identifier in a long program. Enjoy Russ

2 2

"Result" as return value for operator?
by Peter N Lewis 11 Mar '03

11 Mar '03

It seems to me that there is a delphi extension where the variable Result can be used for any function return value. Eg: function sum( a, b: integer ): integer; begin Result := a; Result := Result + b; end; Given this, I expected operator to work the same way: operator + ( a, b: integer ): integer; begin Result := a + b; end; But this results in "parse error before `:'". I would think the above operator code should work given the Result extension. Would it make sense to allow this? Perhaps giving an error if the Result extension is disabled? Thanks, Peter. -- <http://www.interarchy.com/> <http://download.interarchy.com/>

2 1

GPC on Solaris 9
by Cserzo Miklos 06 Mar '03

06 Mar '03

Hi Folks, we need to install GPC on Solaris 9 (64-bit sun). Compilation stops at the rts part. Most probably due to the 64-bit architecture. Is there a protocol around this? Cheers, miklos

4 8

Range Checking
by Frank Heckenbach 05 Mar '03

05 Mar '03

Hi, after some friendly requests and discussion, I'm planning to implement range checking as one of the next major things in GPC (probably in Januaray, if nothing urgent gets in between ...). Note, I'm using "range checking" in the specific meaning I explained recently, not generally for all kinds of runtime checks, and not including overflow checking of arithmetic operations etc. (that will be a separate issue). Also, as I said before, I'll do an "easy" implementation. I'm still not convinced that anything more is worth the (big) effort when the programmer in the rare (AFAICS) cases where it matters could just as well use explicit types etc. to avoid checks where he doesn't want them. Since some of you have said they'd like to help, but can't code in the compiler itself, here are at least 2 chances: 1. Help finding all places where range checking must be applied In mean this from a Pascal point of view, covering, of course, all standards, dialects and extensions that GPC supports. So far I've found the following ones: - assignment to variables and function results, - value parameter passing to user-defined and built-in (e.g., `Chr', `FillChar', ...) routines, - array indexing (R/W), - array slice indexing (R/W), - `for' loop bounds, - conformant array range, - actual schema discriminants, - initialization of types, variables and typed constants, - `asm' targets 2. Write test programs Test programs should follow the guidelines in the manual. In particular, since most of the tests will check for errors, each one must be a separate test for each situation (each of the cases above plus any that others of you will come up with). For a way to test runtime errors see, e.g., fjf424d.pas. Range checking will be on by default, and can be switched on/off with the options `--[no-]range-checking' and the compiler directives `{$[no-]range-checking}', and `{$R+}', `{$R-}'. A complete set of tests should also test all of those. If you'd like to do so, please post a short note, so several of you won't duplicate efforts, but can coordinate. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

6 15

Jump to page:

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