According to Stephan Duehr:
> I have install gcc and would like to take 2.7.2.2.
> I read that gpc 2.0 is for gcc 2.7.2.1. Is it difficult
> to make it work with 2.7.2.2?
I don't know, but you can do the following:
* Some of the GPC source files contain a lot of "#ifdef GPC" constructs.
(Mostly gpc-*.c.) Find their GCC source counterparts.
* See which of these files have changed from GCC-2.7.2.1 to GCC-2.7.2.2
and apply the changes to the GPC source files.
* Compile, …
[View More]and keep your fingers crossed.
* Send us a diff with the necessary changes, so we can upgrade GPC from
GCC-2.7.2.1 to GCC-2.7.2.2. Please take the most recent (alpha)
GPC source.
Greetings,
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 - http://home.pages.de/~gnu-pascal/ [970125]
[View Less]
> Hmmm ... how to tread `protected Var' parameters???
Exactly like const or vice versa (like Borland does: push small bytes on the
stack, pass structures as pointers). With protected var the programmer is on his
own.
Groetjes,
Berend.
> would it be necessary that const parameters have
> clear semantics concerning side-effects?
It doesn't hurt to document them. But the standard already defines protected var
as alias dependent, so you should not use that case (it's always a bug, there is
no program where this feature is useful or required). I've been hurt by using
Borland's const a few times myself (in a case like Peter described).
BTW, const and protected var are the same. There is no difference between them.
This …
[View More]is mainly a way of saying: this var shouldn't altered (source code as
documentation) and speed up it's parameter passing.
protected is: this variable shouldn't be altered, even if I make a mistake (by
aliasing some things), parameter passing speed is not a problem.
Groetjes,
Berend.
[View Less]
Hi,
I thought that GPC did not support varargs. In fact, I
was hoping that it would support the VAX Pascal syntax for
doing so. What is the status of variable arguments for GPC?
--
Ronald Perrella
perrella(a)mindspring.com
Roswell, Georgia, USA.
Hi,
I have install gcc and would like to take 2.7.2.2.
I read that gpc 2.0 is for gcc 2.7.2.1. Is it difficult
to make it work with 2.7.2.2?
--
Stephan Duehr <Stephan.Duehr(a)FernUni-Hagen.de>
----------------------------------------------
In news:comp.lang.pascal.borland, there's just a discussion about
variable number/types of procedure/function parameters going on.
Since Borland Pascal doesn't support this, the discussion has moved
quite a bit away from BP towards gpc. That's why I'm forwarding my
posting to this list. The complete thread can be seen in the
mentioned newsgroup under the same subject as this mail. Perhaps
there are some more ideas about this topic in the gpc community,
or even some of the things below have been …
[View More]implemented that I don't
know about. Certainly, this would rather be a long-time project,
and it's not as urgent as removing bugs and implementing some
other nice features...
Norsk / Hoaxers wrote (in several postings, cut together):
> On Tue, 04 Mar 1997 04:46:26 GMT, rdonais(a)southeast.net (R.E.Donais)
> wrote:
>
> >Since Pascal knows the file is a text file, the programmer is not required to
> >perform conversions on binary values. In "C", the programmer would at some
> >point have to convert the integer to string using something like itoa().
Not explicitly call itoa(), but (s)he'd have to specify the type by a format
specifier ("%d") in the format string. This, of course, provides no means of
type checking, and is therefore not suited for Pascal.
> >I doubt that you want to write separate routines for every combination of
> >variables that you plan to write to a text file. Yet, that's what you imply in
> >your example. :-\
Yes, I think one has to distnguish overloading from "varargs" (allowing to
pass any number and type of parameters). Many useful things can be done with
overloading, but Writeln definitely needs varargs, otherwise you'd have to
declare an infinite number of Writeln variants.
> It was JUST an example. Allow me to give you a better one:
>
> Load_PcxPicture(s:String;segg,off:Word;
> Load_PcxPicture(s:String;segg,off:Word;var Pal:Palettestructure);
I don't think it's a good example. In this case, I would pass Pal as a pointer
with NIL meaning no palette. Easy to implement and easy to call. I don't think
you would write two procedures with similar functionality, so in the end, you'd
probably be doing something like this, anyway.
But this would be a case for default values as in C++. If you could declare
something like
procedure LPP(s:String;segg,off:Word;PPal:PPalettestructure value NIL);
and call it with wither 3 or 4 parameters (in the former case, the 4th
parameter would be implicitly NIL), that would be nice sometimes...
(Yet another feature that could be desirable!)
> No, i didnt miss it at all, i just found it silly actually. You see,
> by implementing "variable syntax" or whatever i should call it, you
> dont make it like cobol, basic, fortran or whatever, you -just- make
> it more flexible. whats so friggin wrong about that? I really dont
> understand whats wrong with it.
I don't think there's anything wrong with it, but Borland will not do it.
They've dropped TP, face it! So if you want these changes, don't look at
TP, but perhaps at GNU Pascal. AFAIK, gpc already supports declaring and
calling a procedure with variable arguments, like C - but only to allow
calling C functions with varargs. There's not (yet) a way to implement such
a procedure in Pascal, but the gpc developers are always looking to enhance
the language, so if you've got some concrete ideas (or can even help to work
on the compiler), you're always welcome to join the team.
> Thats not what I where aiming at. You could make the product better,
> and alas get more satisfied customers.
That's how the gpc developers/maintainers feel too, I think.
> As far as i can remember (this might be wrong) GNU pascal dont have
> oop.
By now, AFAIK, gpc has (nearly) the same OOP as TP, but doesn't implement the
Object Pascal (not-yet-)standard.
> >To each his own. If you want overloading and procedures with variable number of
> >parameters, then check out languages that support them.
> Belive me, I have .. But I really dont like C. Its so.. what should I
> say.. pee->(wee&&) .. I just dont like it :)
I don't think that's valid in C (provided there's anything that's not valid in
C - not sure if there is... :-> ), but I know what you mean. I'd also prefer
to have the Pascal syntax and yet many of the other features.
> I think that would be a bit to much trouble really. I was just
> presenting the idea to get a feeling of other people's thoughts on
> the matter.
If you're serious about it, join the gpc mailing list.
I'll post a copy of this message to the list, since it's quite much about gpc.
> Writeln, reset, and a whole bunch of others allready support it. it's
> just not any way for the -user- to define procedures like that.
>
> and that is a shame . :)
But of course, it's much more difficult to provide a way for the user to
declare and implement such procedures than to just allow some specially
handled procedures like Writeln.
> >Works great as long as it's blindingly obvious which one is going to be
> >called, but consider the following:
> >
> > Procedure MyProc(C: Char);
> > Begin ... End;
> > Procedure MyProc(S: String);
> > Begin ... End;
> > Begin
> > MyProc('A');
> > End.
>
> In that example, you would use the c:char. I guess you would need a
> set of rules, but these rules are allready implemented in borland
> pascal, since some procedures have this. They have just stopped US
> from defining such procedures.
That's indeed a problem. The only predefined procedure with this particular
ambiguity is (AFAICS) Write[ln], and there it doesn't matter which one is
called because the result is the same. That would not be true in general if
the user could define the procedures.
> I see a couple of -possible- solutions to this.
>
> One, not very good, would be to require VAR types in function
> overloading (thats what you called it, right?), like this:
> function f(var nr:byte);
>
> This would remove the problem all together, but its not a very
> flexible way of doing it.
Quite restricting...
I'm curious for other suggestions. If you have some, just tell us about them.
There are problems with ambiguities, and they can be worse than here, as AME
demonstrated. One has to find a way to cope with them (or restrict so much
that no ambiguities remain). And of course, the rules should be relatively
logical and comprehensible and implementable and ... :-)
>As a side note: Doesn't FPK support function overloading?
>
> ?? It does?
AME replied:
> Either FPK or GNU, I can't remember which. I can't even remember if it
> was fully implemented.
AFAIK, gpc supports part of the PCSX (Pascal scientific extensions) standard.
I don't know this standard, and haven't used these extensions, but I think
there is some kind of overloading. You might want to find out if there were
any ambiguity problems involved, and how they were solved.
> On Wed, 05 Mar 97 07:05:42 GMT, babis(a)hol.gr (Babis Athineos) wrote:
>
> >Once upon a time a programmer made a tiny little mistake:
> >instead of writing procedure Store (var S:TStream);
> >he wrote........ procedure Store (var S:PStream);
> >Did you see the difference? Store procedures in TV use the stream,
> >not the pointer. Pascal compiler would normally find the mistake.
> >But Store procedures are not called normally. You pass the address
> >of the procedure in a TStreamRec structure and then a TStream.Put
> >method calls the Store procedure via the address you passed. No
> >type checking! So everything worked OK, except that it didn't save
> >right... (I hope I remember correctly the details of the error -
> >it's been some years and I don't have the time to try it again...)
> >
> >Did you get the point?
To me the point is that the extensions, however implemented, must still allow
Pascal's strong type checking. (In this example, the type checking was
annulled by assembler code, type casts or (unnecessarily) untyped pointers,
I'd guess from what I know about TV.)
> >with variable number and type of parameters, I wouldn't normally
> >use it (except maybe in cases like Writeln), but I would consider
> >it useful. But if I couldn't choose (e.g. $VT-), I would say it
> >is not a Pascal any more...
>
> I agree fully!! It's a matter of being allowed to chose!
Sure. And gpc already has compiler switches to ensure that certain features
are [not] used. All the extensions discussed here would be object to these
(or additional) switches, too.
At last, I've got some suggestions for the varargs problem, too:
Apart from overloading (which I'm not talking about now), I'd suggest the
following two extensions. Both of them combined would be something like
"typed varargs", and allow declaring and implementing Writeln et al.:
1. Unknown number of arguments
To the procedure, this would be very much like Open Arrays (cf. TP/BP 7.0).
The procedure could get their number with (something like) High, and access
them (e.g.) as Parameter[i].
To the caller, however, it's much easier to write than with an Open Array.
Anyone who's used these WVSPrintf (or similar) things in TP knows what I mean
(declaring an array, assigning the parameters to the elements of the array and
then calling the procedure with the array as an argument...)
Alternatively, it would suffice to allow "array expressions" like:
procedure varnumargs(p:array of integer); begin ... end;
var a,b,c:integer;
begin
varnumargs( (a,b,c,2,c-b,27) )
{^^^^^^^^^^^^^^^^ array declaration as in a "typed const"}
end.
Ok, one pair of brackets more, but OTOH this allows for more than one open
array in the parameter list of a procedure, like:
anyproc( (...,...,...),(...,...) )
Probably both ways are useful and have their place...
2. Unknown type of an argument
Ok, there are untypes arguments in TP, but they don't allow for any type
checking when used, so they're not suited here. Furthermore, the procedure
doesn't get any information about the type, so this information would have
to be passed separately (as in the printf format string in C), which is not
acceptable.
So the type must be passed internally, and there must be a way for the
procedure to check the type, and to access the parameter as its real type.
I could imagine something like the following:
procedure Write(Const a);
var s:String[255];
begin
IFTYPE a,Boolean then
if a then WriteStr('True') else WriteStr('False')
{^^^^^^^^ this is legal, since a is a Boolean now}
else
CASETYPE a OF
Char: WriteStr(a); {Now a is a Char}
String: WriteStr(a); {Here, a is a String - String would include any
string type, not just String[255]}
LongInt: {Since any integer type in TP can be seen as a subrange of
LongInt, this includes all integer types.}
begin
{In this block, a is an integer}
if a<0 then begin
WriteStr('-');
a:=-a
end;
...
end;
Real: ...;
Extended:...;
...
else Error('Cannot write variables of this type!')
end
end;
Note the IFTYPE statement. It would not just check for the type of a, but if
successful, cast a into this type for the "then" block. Since the block can
only be reached if the type matches, this is type-safe.
Similarly the CASETYPE, only for simplified writing. (Of course, the IFTYPE
above could be part of the CASETYPE, I just wanted to show both ways.)
(This syntax is only tentative, it doesn't have to be called IFTYPE and
CASETYPE.)
Of course, the SizeOf function would work on a and return the actual size.
I pointed to some possible problems with "similar" types (string types,
subranges). There will be some problems (e.g. subranges with different sizes,
esp. with reference parameters), but I think they can be solved.
Of course, it would be nice to elimiate the "else" of the CASETYPE above, and
instead cause a compiler error at any attempt to call the procedure with any
type not listed in CASETYPE. This would be a behaviour like the real Write.
One has to investigate if and how this is possible (considering multiple,
possibly nested IFTYPEs/CASETYPEs)...
Another idea is whether it is possible and/or useful to compare types of
different arguments:
procedure equal(const a,b);
begin
IFTYPE a,b then {Compare SizeOf(a) bytes at @a and @b}
else Error('Comparison of different types not allowed!')
{^^^ or again, rather a compiler error...}
end;
It also seems useful to declare local variables of the same type as an
argument:
procedure swap(var a,b);
var temp:TYPEOF(a);
begin
IFTYPE a,b then begin temp:=a;a:=b;b:=temp end
else Error('Swapping different types not allowed!') {see above}
end;
(I think, Extended Pascal (gpc???) has some kind of type inquiry, but probably
only for known types. Anyway, this one could, of course, use the same syntax
as EP (it's probably not the syntax above, since I don't know the EP syntax).)
Concerning the implementation, I'd say that for each "vartype" parameter an
additional (invisible) parameter is passed that describes the type uniquely.
Since the compiler has to keep track of all the types somehow anyway, it
shouldn't be hard to generate a unique number for each type. The numbers don't
have to have any other meaning except being unique, since the IFTYPE/CASETYPE
comparisons would be the only things they're used for. Oh, sorry... subranges
might have to be considered, but that should also be feasible...
The size (for SizeOf) would either be passed as another additional parameter
(if used at all in the procedure), or be retrieved through a lookup table via
the type number.
The varying size of the arguments on the stack (in the case of value
parameters) also seems to be a little problem, but I think it can be solved,
too. (Perhaps with the help of the SizeOf parameter as far as necessary, or by
passing temporary copies by reference...)
Type inquiry would be rather easy, since the procedure would only need to know
the size of the local variable which can be obtained like the SizeOf above.
Many ideas... many problems... much to do...
This message is distributed under the terms of the GNU General Public License.
The license can be retrieved from many ftp and www sites, e.g. from:
ftp://sunsite.unc.edu/pub/gnu/COPYINGhttp://www.mi.uni-erlangen.de/~heckenb/COPYING
If you can't get this file, mail me, and I'll send you a copy.
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm
[View Less]
Hi everyone!
I've got a few more bugs:
1. For loops with chars don't seem to work:
PROGRAM p;
VAR c:Char;
BEGIN
c:='A'; {OK}
c:='Z'; {OK}
FOR c:='A' TO 'Z' DO {"incompatible types in assignment"}
END.
2. Under DJGPP, program arguments don't work correctly, as the following
program shows. Under Linux it seems to work ok. However, the problem
seems to have something to do with Pascal, since gcc programs under
DJGPP don't show the problem.
{Call the compiled program as "p …
[View More]longparam 2 3" or similar}
PROGRAM p;
{From info/gpc.i7, slightly modified:}
CONST
Max_length = 255; { Max length of each argument.
If some arg is longer, the run time system
traps it. }
TYPE
Arg_type = String(Max_length);
FUNCTION _p_paramcount : Integer; C;
FUNCTION _p_paramstr (num: Integer; VAR str: String): Boolean; C;
FUNCTION ParamCount: Integer;
BEGIN
ParamCount := _p_paramcount;
END; { ParamCount }
FUNCTION ParamStr (arg_num: integer): Arg_type;
VAR
Str : Arg_type;
Success : Boolean;
BEGIN
Success := _p_paramstr (arg_num, Str);
(* Should perhaps do something else on failure.
*
* Now it returns the empty string, which is also a valid
* parameter.
*)
IF Success THEN
ParamStr := Str
else
ParamStr := '';
END; { ParamStr }
{}
VAR a:Integer;
BEGIN
FOR a:=1 TO ParamCount DO Writeln(ParamStr(a))
END.
The result is something like:
longparam[some other chars]
2ongparam[some other chars]
3ongparam[some other chars]
Obviously the length is not set correctly.
Frank
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm
[View Less]
Peter Gerwinski wrote:
> [...]
> It needn't be an explicit assignment; it might be a call to a function
> which makes the value of `x' change. To pass everything by value *is*
> the only possibility.
I must admit, I didn't think of these cases.
> But I will modify `Const' parameters to pass small things by value and
> to work with implicit temporary variables when a constant is passed as
> a `Const' parameter.
You mean, for big things!? I don't think you need any …
[View More]temporary variables
for small things that are passed by value, regardless whether a variable,
constant or an evaluated expression is passed. For big things passed by
reference, you need a temporary variable if a constant or expression is
passed, I think.
> Then it's up to the programmer to take care that
> the `Const' parameter doesn't change its value due to side effects.
Then it would be like Borland's. However, speaking from a purist's point of
view, I can see the problem that it would be implementation-dependent whether
a parameter is passed by value or by reference. This means it is "undefined"
whether side-effects can happen or not. Would it be permissible (well, const
parameters aren't standard anyway, I mean in the "spirit" of the standard)
to leave that undefined, or would it be necessary that const parameters have
clear semantics concerning side-effects?
> Hmmm ... how to tread `protected Var' parameters???
As far as I understood it up to now (Berend, correct me if that's not what
the standard says), "protected" only means that the compiler must make sure
that the parameter isn't altered, and never changes the way of passing the
parameter.
That would mean:
'const' parameters would be used if the programmer is sure that there can't
be any side-effects (which is true in the majority of cases, e.g. if the
procedure operates only on local variables and will not be called with the
same parameter twice; or e.g. if the procedure reads the value of the
parameter only before it writes to any var parameters and/or global
variables and/or calls any procedures/functions that do), and wants the
compiler to choose the most efficient way of passing and to verify that the
programmer doesn't accidentally alter the parameter.
'protected' parameters would be used if there is a danger of side-effects,
and the programmer only wants to verify the parameter isn't altered, putting
up with a possible inefficiency. (I think it's rare that side-effects become
a problem, especially with big structures where the inefficiency would
matter.)
'protected var' parameters would be used in the (very rare, IMHO) case that
there could be side-effects, and the programmer *wants* these side-effects to
influence the parameter. E.g., I could imagine a procedure that watches some
variable for changes, but must not change the variable by itself - perhaps
in a multi-threaded program where another thread could modify the variable -
just fantasizing...
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm
[View Less]
According to Berend de Boer:
> There is a few cases where it might be a little bit less hard. I think the case
> when there are no var parameters (so there is no aliasing) protected should be
> protected var.
No chance:
Var
x: Integer;
Procedure Bar ( protected y: Integer );
begin (* Bar *)
x:= 3;
end (* Bar *);
...
Bar ( x );
It needn't be an explicit assignment; it might be a call to a function
which makes the value of `x' change. To pass …
[View More]everything by value *is*
the only possibility.
But I will modify `Const' parameters to pass small things by value and
to work with implicit temporary variables when a constant is passed as
a `Const' parameter. Then it's up to the programmer to take care that
the `Const' parameter doesn't change its value due to side effects.
Hmmm ... how to tread `protected Var' parameters???
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 - http://home.pages.de/~gnu-pascal/ [970125]
[View Less]
Oops, sended the msg already. Here again:
>> Does that mean that protected (not protected var) parameters
>> are passed by value? Especially in the case of large
>> structures, can this be inefficient, taking up stack space
>> and consuming time to copy the arguments?
> Yes. :-(
>> Or does the standard prescribe something different?
> Yes. It requires that the value of the protected formal
> parameter cannot change during the execution of the …
[View More]function,
The standard doesn't define it this way. I too think that protected should be
treated exactly like var parameters, or whatever is as efficient or more
efficient (that's why I use const parameters for in Borland Delphi).
The standard says this about protected parameters:
peter is essentially correct.
(and my initial sentence was incorrect)
After a 2nd reading and some trying I don't see a better way to implement it.
The compiler would have a really hard job to change protected to protected var
when that is allowed.
There is a few cases where it might be a little bit less hard. I think the case
when there are no var parameters (so there is no aliasing) protected should be
protected var.
Groetjes,
Berend.
[View Less]