Well, it's nice to see we are now in agreement in most areas. BTW, in case there is any remaining doubt, let me make it clear that I have never myself regarded a program without a parameter list as "pointless".
I'm glad you liked those ISO-10206 citations, too. Even if you want to limit yourself to ISO-7185, the EP standard is still a useful guide to the interpretation of ISO-7185, since it builds directly upon this, but takes a broader view of the application of Pascal in the real world.
You are correct that ISO-7185 only defines ONE mechanism by which program variables can be bound to external entities - via the program parameter list! Any other mechanism, which may be employed by a particular implementation, is a non-standard extension (well, by definition, all extensions are non-standard;-)!
Joe.
-----Original Message----- From: J. David Bryan [SMTP:dbryan@bcpl.net] Sent: Thursday, October 25, 2001 2:01 AM To: GNU Pascal List Subject: Re: Errors and Standards (was: compiler bug)
On 23 Oct 2001, at 11:44, da Silva, Joe wrote:
Sorry if I wasn't clear ... when I said "my understanding is ...", what this meant (and BTW, I thought this would be clear from the subject
being
discussed) was "my understanding of the standard(s) is ...".
I understood what your understanding was. ;-) My assertion is that understandings of the standard don't count, only statements from the standard do.
So, if you have specific areas where you believe that I have
contradicted
the standard(s), please indicate the particulars, so we can both double-check it.
I can't, because I believe that you have asserted a restriction that is not in the standard (but see my comment about "the standard" below). I can't cite a passage from the standard that specifically allows linking of non- program-parameter, main-block variables to external entities, because the standard says nothing about such linking (allowed or disallowed). Can you
cite a passage that disallows such use?
BTW, you should note that we are in agreement that a program without a parameter list is perfectly legal.
Duly noted! ;-)
As to whether such a program is "pointless", please note that any such inference (which arose when I semi-quoted Peter Grogono), was nothing more than a bit of humour.
The issue for me is not whether certain programs are or are not pointless.
My contention is broader, specifically, that any such assertion must be supported by the standard and not simply by "common sense." The Pascal standards are written in horribly arcane language to ensure that they are not open to such interpretations, i.e., that everything stated is unambiguous. We shouldn't have to argue about whether a given program is or is not legal (or pointless), because the standard should either prohibit it or not.
Given the choice, I would much rather decide things on the basis of opinions and common sense, as reading the standards always gives me a severe headache. But I believe that we cannot do that, if GPC is to claim
adherence to those standards. If there is disagreement over positions that GPC should take, then the choice of position must be the one that is supported by citations from the standards.
Now, specific to your situation, a very quick check of the ISO-10206 standard revealed the following...
Ah, but the assertion regarding "pointlessness" (i.e., that a program without program parameters could have no side effects) was made in the context of ISO 7185. Frank allowed that ISO 10206 programs could have side effects without program parameters (and is supported by the passages you cite).
I concur completely with your citations in the context of ISO 10206.
However, ISO 7185 mentions binding to external entities only with reference to program parameters (section 6.10). I contend that 6.10 applies only to
main block variables that are also program parameters and therefore is not
applicable to (and therefore does not restrict) other main block variables
being bound by some other mechanism external to the language.
-- Dave
"da Silva, Joe" wrote:
I'm glad you liked those ISO-10206 citations, too. Even if you want to limit yourself to ISO-7185, the EP standard is still a useful guide to the interpretation of ISO-7185, since it builds directly upon this, but takes a broader view of the application of Pascal in the real world.
You are correct that ISO-7185 only defines ONE mechanism by which program variables can be bound to external entities - via the program parameter list! Any other mechanism, which may be employed by a particular implementation, is a non-standard extension (well, by definition, all extensions are non-standard;-)!
At least in the embedded world, I found that I could describe everything I wanted in terms of the file system. The run-time had drivers for various specialized files, which included such things as a LAN and an interactive screen. The programs altered the file buffer variables (f^) appropriately (or interrogated them) and did the appropriate get or put. The drivers were table driven, and needed 5 routines per file (read, write, open, close, control/status). A sixth table field specified the file name.
In the case of the screen, the screen itself was an array 24*80 of char (or whatever). The run-time allowed the operator to move to appropriate fields and type in whatever he desired. The file object was a record, that included the screen and a few booleans (such as changed).
In other cases the file buffer was the output of an a/d converter.
For debugging, I could create actual disk files of these things, recorded from the actual machinery, and have a repeatable input set.
This did rely upon an extension, where either the reset (or rewrite) had an added parameter for file-name, or else the device name was the actual Pascal name.
However, once attached, the files obeyed the rules for Pascal files.
=============
Aside - I prepared a text version of ISO10206 and sent it to Frank a few days ago. I have not heard anything back from him. It seems like a good thing to have around for instant searches, etc. I wonder if he received it?
=============
I consider the lack of range-checking to be the worst failing of GPC. The point of using Pascal is to have ones hand held and to generate safe code. Without range checks one might as well use C.
CBFalconer wrote:
Aside - I prepared a text version of ISO10206 and sent it to Frank a few days ago. I have not heard anything back from him. It seems like a good thing to have around for instant searches, etc. I wonder if he received it?
Yes, I did. However, are we allowed to distribute it at all? What is the copyright status of the document?
I consider the lack of range-checking to be the worst failing of GPC. The point of using Pascal is to have ones hand held and to generate safe code. Without range checks one might as well use C.
I thought so too when I came to GPC. However, in the years I've found that it was not that bad, at least for me (not meaning to justify GPC's failure, of course).
It is still one of the top-priority bugs. OTOH, there was recently quite some consensus on finishing a 2.1 release soon. Afterwards, range checking should be one of the next features implemented.
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
Aside - I prepared a text version of ISO10206 and sent it to Frank a few days ago. I have not heard anything back from him. It seems like a good thing to have around for instant searches, etc. I wonder if he received it?
Yes, I did. However, are we allowed to distribute it at all? What is the copyright status of the document?
The following was in the original:
=========== This online copy of the Extended Pascal standard is provided only as an aid to standardization. In the case of differences between this online version and the printed version, the printed version takes precedence.
Do not modify this document. Do not include this document in another software product. You may print this document for personal use only. Do not sell this document. ===========
I have not modified it. I take the above as permission to promulgate it. Even if I am wrong, the worst that could happen would be for ISO to ask you to withdraw it.
I consider the lack of range-checking to be the worst failing of GPC. The point of using Pascal is to have ones hand held and to generate safe code. Without range checks one might as well use C.
I thought so too when I came to GPC. However, in the years I've found that it was not that bad, at least for me (not meaning to justify GPC's failure, of course).
It is still one of the top-priority bugs. OTOH, there was recently quite some consensus on finishing a 2.1 release soon. Afterwards, range checking should be one of the next features implemented.
The standard says "It shall be an error ....".
In another newsgroup there was discussion of an algorithm (comp.programming) and I generated the following. I left the "abs" out of the hash procedure, and things failed. The system was returning negative values used as indices, and I consider it a minor miracle that there were no spectacular crashes. This should never have happened.
(Below is some further discussion about a rhide bug detected with this)
PROGRAM On(input, output); (* ISO standard Pascal *)
LABEL 9;
CONST tblsize = 17; (* a suitable prime, larger than the maximum *) (* count of discrete entries to be read *)
criterion = 5; (* count of items needed to keep *)
TYPE natural = 1 .. tblsize;
VAR item : integer; i, h, h2, h0 : natural; hashtbl : ARRAY[1..tblsize] OF RECORD value : integer; count : 0..criterion; END;
FUNCTION hash(n : integer) : natural; (* create these. This is too simple for efficiency *)
BEGIN (* hash *) hash := (abs(n) MOD tblsize) + 1; END; (* hash *)
FUNCTION rehash(n : integer) : natural; (* This is also overly simple for efficiency *)
BEGIN (* rehash *) rehash := 1; END; (* rehash *)
BEGIN (* On *) FOR i := 1 TO tblsize DO hashtbl[i].count := 0; (* init *)
REPEAT readln(item); h := hash(item); IF hashtbl[h].count = 0 THEN BEGIN (* new *) hashtbl[h].count := 1; hashtbl[h].value := item; END ELSE IF hashtbl[h].value = item THEN BEGIN (* found *) IF hashtbl[h].count < criterion THEN hashtbl[h].count := hashtbl[h].count + 1; END ELSE BEGIN (* collision occured *) h0 := h; h2 := rehash(item); (* nonzero MOD tblsize *) REPEAT h := ((h + h2) MOD tblsize) + 1; IF h = h0 THEN BEGIN writeln('Full'); goto 9; END; IF hashtbl[h].count = 0 THEN BEGIN (* new *) hashtbl[h].count := 1; hashtbl[h].value := item; END ELSE IF hashtbl[h].value = item THEN BEGIN (* found *) IF hashtbl[h].count < criterion THEN hashtbl[h].count := hashtbl[h].count + 1; END UNTIL hashtbl[h].value = item; END; UNTIL eof;
9: (* dump results *) FOR i := 1 TO tblsize DO WITH hashtbl[i] DO IF count >= criterion THEN writeln(value, ' hash = ', i : 1, ' KEPT') ELSE IF count > 0 THEN writeln(value, ' count = ', count : 3, ' hash = ', i : 1); END. (* On *)
========= RHIDE bug under DJGPP - reason for cross post ========
The input is terminated by an EOF. Under rhide, having once terminated a run, input was found to be permanently at EOF. Doing a program reset did not clear it. The only way to loosen up the system was to exit RHIDE completely, and restart it. I have no objection to the EOF sticking (in fact I approve), but a reset should reset!
It was just as well in this case, because I am set up to create further checking under command line use, which showed up the use of extensions (i.e. halt and inc).
(To generate EOF enter a CTL-Z under DJGPP)
CBFalconer wrote:
Frank Heckenbach wrote:
Yes, I did. However, are we allowed to distribute it at all? What is the copyright status of the document?
The following was in the original:
=========== This online copy of the Extended Pascal standard is provided only as an aid to standardization. In the case of differences between this online version and the printed version, the printed version takes precedence.
Do not modify this document. Do not include this document in another software product. You may print this document for personal use only. Do not sell this document. ===========
I have not modified it. I take the above as permission to promulgate it.
I'm not sure. I think the default in copyright is that most things are not allowed unless stated otherwise.
I'll wait for a statement from Peter who owns the server. If he says it's ok, I'll put it up ...
The standard says "It shall be an error ....".
: 3.2 Error : : A violation by a program of the requirements of this International Standard : that a processor is permitted to leave undetected.
;-)
In another newsgroup there was discussion of an algorithm (comp.programming) and I generated the following. I left the "abs" out of the hash procedure, and things failed. The system was returning negative values used as indices, and I consider it a minor miracle that there were no spectacular crashes.
Well, it segfaults for me when entering negative values without the abs, if that relieves you. As for spectacular, you won't hang the system so easily in a protected environment than under plain Dos (though perhaps it's still possible under DJGPP more easily than on other systems).
This should never have happened.
I agree. The problem is just that there are a number of urgent bugs (even though we've fixed many of them by now), and our time is finite, and people want to see a new release. We can't do all at once ...
Frank
-
CBFalconer -
da Silva, Joe -
Frank Heckenbach