write ('There are ', items:1, ' items')
Or does this "clipping" only apply to strings?
Clipping only applies to strings.
I see, fine.
But then again, how would you do "You name is Phil."? Do you have to "write(s:Length(s))" or such?
write ('You name is Phil.') :)
Err... well, I meant 'Phil' was the value of a string variable. I thought this would be clear.
In standard Pascal there are no string schema types like extended Pascal, but in extended Pascal "write(s)" is identical to "write(s:length(s))".
Ok, then, if I got this right, you have to do write(num_var:1) and write(string_var) for output without spaces, whereas write(num_var) and write(string_var:1) both don't work this way.
This seems a bit inconsistent and confusing to me. I see that your programs rely on this way, but my programs rely on BP's way, and I don't think there's anything worse with BP's way than the standard's way. So, obviously, gpc needs to support both ways.
"Strings" in standard Pascal are typically an "array [1 .. n] of char". The programmer then needs to keep track of how many of the n characters are valid. Then the write statement would look like "write (s:sizeofs)".
This explains to me why this clipping is needed in standard Pascal. However, I really don't want to use hand-made strings in my programs, I really could stand a little more comfort... :-)
So, obviously, gpc needs to support both ways.
Yes, I agree. When the --borland_pascal switch is set, it should look like Borland Pascal!
However, I really don't want to use hand-made strings in my programs, I really could stand a little more comfort... :-)
Yup! And others (including me) agree. Hense Extended Pascal! :)
Phil Nelson wrote:
So, obviously, gpc needs to support both ways.
Yes, I agree. When the --borland_pascal switch is set, it should look like Borland Pascal!
Hi Phil and the Rest of the world ...
Although gpc ain't a commercial product it should be build on wide acceptance. (Where else shall all the really good gpc-programs come from?) In past nobody was interested in any pascal-standards but Borland. Borland-Pascal IMHO is the standard-pascal anyway. The probably are hundreds of Borland-Pascal-Users on one or two other-semi-standard-pascal-with-some-extensions-users.
Until raising version 2.0 (the star) gpc wasn't alive. It really seemed to be a rather dead language. For now it will not live from the euphorie of the 'main' developers but more from many contributions from many programmers all over the world.
Sure, the only one concurrent platform is gnu C, but gnu C lives from that contributions too. Why is linux that much popular.
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. However, this may be a little bit visionary. But we should NOT artificially complicate changes to gnu pascal. (Vice versa case is an interesting question to discuss too.)
However, I really don't want to use hand-made strings in my programs, I really could stand a little more comfort... :-)
Yup! And others (including me) agree. Hense Extended Pascal! :)
I agree too, but why should {-------------snip-------------} i:=7; writeln("i=",i); {-------------snip-------------} give somthing like
"i= 7 ?"
(Please don't ask (me) why not.)
nb. The Borland Pascal behaviour conforms to ISO 10206 too. How about implementing sysvars IntegerTotalWidth and the like with values defaulting to the Turbo Pascal settings (i.e. 0, with special behaviour: no cutting of strings.), then you will have a powerful facility to print tables from scratch. Formatted as you wan't from clear, readable and confusenessless code like write('i=',i:whatever^.thisconfusingwidthofintegers.be);
-- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html
regards,
sven
================================================================== Sven Engelhardt http://www.sax.net/ mailto:se@sik.de
Although gpc ain't a commercial product it should be build on wide acceptance.
I agree.
In past nobody was interested in any pascal-standards but Borland.
I disagree. Borland did not write ISO 7185 and 10206. If they did, those standards would look a lot different. Units would be part of the standard, which they are not.
Borland-Pascal IMHO is the standard-pascal anyway.
I disagree.
gpc really shall default to borland/turbo-pascal behaviour. You could
I disagree.
I did like the suggestion that gpc could be started from several links, gpc (ie. ISO standard Pascal/ISO Extended Pascal) and bpc (Borland Pascal). I do believe that gpc should support(emulate) Borland Pascal to support Borland Pascal users. But gpc should not standardly be Borland.
I agree too, but why should {-------------snip-------------} i:=7; writeln("i=",i); {-------------snip-------------} give somthing like
"i= 7 ?"
Because that is how a majority of Pascal compilers do it. And to ask a furthur question, why should {-------------snip--------------} for i := 1 to 5 do write(a[i]); writeln; {-------------snip--------------} produce output for which you can not distinguish the elements of a?
nb. The Borland Pascal behaviour conforms to ISO 10206 too. How about
Are your sure about this? Full Extended Pascal? From my exprience, it violates 6.10.3.6. (and 6.9.3.6 in ISO 7185.) If there is a way to make it not violate the above quoted paragraphs, I'd really like to know how.
Phil Nelson wrote:
Although gpc ain't a commercial product it should be build on wide acceptance.
I agree.
In past nobody was interested in any pascal-standards but Borland.
I disagree. Borland did not write ISO 7185 and 10206. If they did, those standards would look a lot different. Units would be part of the standard, which they are not.
Borland-Pascal IMHO is the standard-pascal anyway.
I disagree.
I didn't mean Borland wrote that standards - sorry for the inexactitude - but Heimsoeth made the first real working and usable compiler for dos platfrom (which had an overwhelming piece of market of about 85% of personal computers that day). Computers and therefore they established a "quasi"-pascal-standard. That IS and WILL BE my opinion and reason because doesn't release Quick-Pascal any- or Visiual-Pascal furthermore. (Congratulations Borland)
gpc really shall default to borland/turbo-pascal behaviour. You could
I disagree.
Clearly from context: not for standardization reasons; but for reasons of portability.
I did like the suggestion that gpc could be started from several links, gpc (ie. ISO standard Pascal/ISO Extended Pascal) and bpc (Borland Pascal). I do believe that gpc should support(emulate) Borland Pascal to support Borland Pascal users. But gpc should not standardly be Borland.
gpc ain't borland pascal guy, but remember: people use borland, borland is habitual, schools teach borland.
give somthing like
"i= 7 ?"
Because that is how a majority of Pascal compilers do it.
But the majority is using borland and therefore this behaviour IS NOT USUAL for the majority of programmers, source-code-programs etc.pp. Maybe it is for YOU and YOUR compiler.
And to ask a furthur question, why should {-------------snip--------------} for i := 1 to 5 do write(a[i]); writeln; {-------------snip--------------} produce output for which you can not distinguish the elements of a?
nb. The Borland Pascal behaviour conforms to ISO 10206 too. How about
Are your sure about this? Full Extended Pascal? From my exprience,
We are talking about the default behaviour. i.e. the parameter next to double-dot is missing. And we are talking abount write(integer), aren't we?
Cutting strings is a completely different case, because 'write(s:x)' with length(s)>x does really make sense only if the string is cutted.
it violates 6.10.3.6. (and 6.9.3.6 in ISO 7185.) If there is a way to make it not violate the above quoted paragraphs, I'd really like to know how.
You are right, but declaring Default-TotalWidth(integer)=0 (or 1) conforms to 6.10.3.3, the output will be a left aligned number, so we can beat "quasi" borland-compatibility and your need of standard-conformance. Once again: WHY NOT, why should it be defined to 5, 8, 10 or whatever value you want? from 6.10.3.1 "the default values shall be implementation- defined", perhaps gpc will be an implementation on it's own. Not conforming to Borland, USCD, IBM-Pascal or whatsoever.
-- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html
================================================================= Sven Engelhardt http://www.sax.net/ mailto:se@sik.de
And to ask a furthur question, why should {-------------snip--------------} for i := 1 to 5 do write(a[i]); writeln; {-------------snip--------------} produce output for which you can not distinguish the elements of a?
...
We are talking about the default behaviour. i.e. the parameter next to double-dot is missing. And we are talking abount write(integer), aren't we?
Sorry, I was not clear. a would be an integer array. So yes, I was talking about write(integer). Which would default to write (integer:1) for Borland and write(integer:10) (or some other number) for "traditional" Pascals.
So in the above example if a had the values 15, 23, 3, 42, 5, under Borland your output would be "15233425" and you would have no clue as to what the actual values in the array a really were.
You are right, but declaring Default-TotalWidth(integer)=0 (or 1) conforms to 6.10.3.3, the output will be a left aligned number, so we can beat "quasi" borland-compatibility and your need of standard-conformance.
True. The default of 1 does follow the standard here as written. This one place where I feel the standard was not specific enough. I believe that the above code should produce output where you can distinguish the elements of array a when a contains either integers or reals. To do this, the standard field width MUST be implementation dependent due to the number of digits in the maximum integer.
Once again: WHY NOT, why should it be defined to 5, 8, 10 or whatever value you want? from 6.10.3.1 "the default values shall be
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.
Phil Nelson wrote:
So, obviously, gpc needs to support both ways.
Yes, I agree. When the --borland_pascal switch is set, it should look like Borland Pascal!
Hi Phil and the Rest of the world ...
Although gpc ain't a commercial product it should be build on wide acceptance. (Where else shall all the really good gpc-programs come from?) In past nobody was interested in any pascal-standards but Borland. Borland-Pascal IMHO is the standard-pascal anyway. The probably are hundreds of Borland-Pascal-Users on one or two other-semi-standard-pascal-with-some-extensions-users.
I agree.
[...]
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. However, this may be a little bit visionary. But we should NOT artificially complicate changes to gnu pascal. (Vice versa case is an interesting question to discuss too.)
Hi!
I don't like the idea of a local (user) configuration file as GPC.CFG or .gpcrc. There is a way of doing it in a makefile. If someone _needs_ a compiler which is a borland like compiler for standard, might there be a compile-time switch? Let's consider something like ./configure --try-to-be-a-borland-compiler or ./configure --use-standard-pascal.
Tsch"u"s, Nils
On Fri, 4 Apr 1997, Nils Bokermann wrote:
Hi!
I don't like the idea of a local (user) configuration file as GPC.CFG or ..gpcrc. There is a way of doing it in a makefile. If someone _needs_ a compiler which is a borland like compiler for standard, might there be a compile-time switch? Let's consider something like ../configure --try-to-be-a-borland-compiler or ../configure --use-standard-pascal.
Oh no! This is a support nightmare. Imagine people complaining "my gpc does XYZ when I feed it this ABC source!". Then we would have to find out _what_ GPC they have in first place. The confusion caused by rapidly changing GPC revsions and a number of different platform specific problems is enough, IMHO. Unless yet another option were added which would dump all options passed at build time, and _everybody_ would faithfully mention this in bugreports....
Greetings, JanJaap
--- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming]
-
Frank Heckenbach -
Jan-Jaap van der Heijden -
Nils Bokermann -
Phil Nelson -
Sven Engelhardt