Tom Schneider wrote:
Peter:
No. We use one of the mechanisms to specify the file name at run-time from a string.
UCSD Pascal:
reset ( MyFile, 'myfile.dat' );Borland Pascal:
assign ( MyFile, 'myfile.dat' ); reset ( MyFile );ISO Extended Pascal:
Var MyFile: File of whatever; B: BindingType; unbind ( MyFile ); B:= binding ( MyFile ); B.Name:= 'myfile.dat'; bind ( MyFile, B ); reset ( MyFile );All this works in GPC.
Right, and I consider that to be "machine dependent"
Not machine dependent, but compiler dependent, that's a big difference! It will work on any machine, as long as it's compiled with GPC.
since such things are not available on all Pascal compilers. So I avoid them.
Well, at least the 3rd mechanism is specified in the Extended Pascal standard (ISO 10206), while your way (derving the file name from the variable name) is not standardized and therefore also compiler dependent...
Frank
Frank:
Right, and I consider that to be "machine dependent"
Not machine dependent, but compiler dependent, that's a big difference! It will work on any machine, as long as it's compiled with GPC.
Of course, I should have said that.
since such things are not available on all Pascal compilers. So I avoid them.
Well, at least the 3rd mechanism is specified in the Extended Pascal standard (ISO 10206), while your way (derving the file name from the variable name) is not standardized and therefore also compiler dependent...
Hmm. Deriving the name from the variable with no changes would seem to me to be pretty simple, whether or not it is standard.
Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms@ncifcrf.gov permanent email: toms@alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/
Tom Schneider wrote:
Well, at least the 3rd mechanism is specified in the Extended Pascal standard (ISO 10206), while your way (derving the file name from the variable name) is not standardized and therefore also compiler dependent...
Hmm. Deriving the name from the variable with no changes would seem to me to be pretty simple, whether or not it is standard.
Especially the 2nd mechanism is also pretty simple - such that multiple compiler vendors had the same idea of introducing this extension. However it's an extension.
Deriving the name from the variable makes Pascal case-sensitive and does not allow for arbitrary file names so I really wonder that there is more than one compiler doing this. And of course, it's also an extension.
Anyway: Let's introduce this as a compatibility option (with lowercase file names), so we'll all be happy. ;-)
Peter
Peter:
Especially the 2nd mechanism is also pretty simple - such that multiple compiler vendors had the same idea of introducing this extension. However it's an extension.
Interesting point.
Anyway: Let's introduce this as a compatibility option (with lowercase file names), so we'll all be happy. ;-)
That would be great!! Thanks!
Tom
Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms@ncifcrf.gov permanent email: toms@alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/
Tom Schneider wrote:
Peter:
Anyway: Let's introduce this as a compatibility option (with lowercase file names), so we'll all be happy. ;-)
That would be great!! Thanks!
Okay. How shall we name this option? `--automatic-file-names'?
Peter
Peter:
Tom Schneider wrote:
Peter:
Anyway: Let's introduce this as a compatibility option (with lowercase file names), so we'll all be happy. ;-)
That would be great!! Thanks!
Okay. How shall we name this option? `--automatic-file-names'?
I suppose it is important that the name fit into your other name conventions. Given that caveat, maybe '--transparent-file-names' would be more descriptive of what happens, since the name given at the top of the program (and defined as a variable of type text) directly maps to the file name on the computer system.
Thanks!!
Tom
Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms@ncifcrf.gov permanent email: toms@alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/
-
Frank Heckenbach -
Peter Gerwinski -
Tom Schneider