5 ms·

A simple string handling library for Microsoft Fortran-80

53 points by CTOSian 5y ago

Bostonian 5y ago
Fortran 77 and later versions (most recently Fortran 2018) have strings. There is the limitation that the elements of an array of strings must have equal length, so that ["boy","girl"] is an invalid character array constructor but ["boy ","girl"] is valid. Libraries for manipulating strings in Fortran are listed at https://github.com/Beliavsky/Fortran-code-on-GitHub#strings https://github.com/Beliavsky/Fortran-code-on-GitHub#strings .
- mumblemumble 5y ago
  I thought that the specific issue was that arrays could only directly contain strings of equal length. Which, yeah, that's necessary in order for array access to be O(1) and for any sorts of vector intrinsics or striding operations to work properly. The way to get around that is by sticking the actual string on the heap somewhere and only storing a pointer to it in the array. This isn't a unique problem to Fortran; it's how basically every programming language does it. The difference is that Fortan doesn't automatically heap allocate them for you - you've got to manually box them with a derived type - and that most other languages don't even give you the option of strings without pointer chasing. I would argue that, while this characteristic is certainly going to seem weird to anyone who's used to a higher-level language, in a language like Fortran where the primary use case is high performance computing, putting the programmer in charge of these sorts of decisions is neither a bug nor a wart; it's a huge feature.
  - terminalcommand 5y ago
    I agree, this makes sense, having O(1) access to all items in a string array seems logical to me, you would also avoid problems with forgetting \n termination like in C.
    - mumblemumble 5y ago
      Though it does create its own separate class of potential bugs. When you assign some text to a fixed-length string, Fortran will silently truncate or space-pad it to make it the correct length.
- ok123456 5y ago
  In Fortran-90 and beyond you could just have an array of pointers to strings, which would be analogous to the normal behavior in most languages.
mumblemumble 5y ago
Very nice; I haven't used it, but I gather that Fortran-80 was severely lacking in string handling. That said, I feel compelled to point out that one shouldn't judge Fortran as a whole by the need for a library like this in a 40 year old version of the language. I'm still learning the language, so I can't speak with a lot of authority, but it seems to me that, while Fortran is never going to be my favorite language for text munging, its string handling has come a long, long way between then and the Fortran 2018 standard.
- Bostonian 5y ago
  There was no Fortran 80 standard. There was Fortran IV aka Fortran 66, Fortran 77, Fortran 90, and following, most recently Fortran 2018.
  - mumblemumble 5y ago
    There wasn't a Fortran-80 standard, but there was a Fortran-80. Kind of like how there isn't a C# 2005 standard. That's a specific dialect of C# associated with a commercial compiler. The closest standard is the C# 4th edition ISO standard, which covers a subset of C# 2005's features. But it's still OK to refer to C# 2005 as a thing. I think that this is a useful distinction to make in Fortran-land. I haven't used any of these old Fortran compilers, but my understanding is that they were all significantly different and more-or-less mutually incompatible. The Fortran standard had a minimal standard library, so things like what functions you had available for string manipulation depended more on the compiler you used.
    - adrian_b 5y ago
      Yes, FORTRAN-80 was a Microsoft product, belonging to a suite of compilers and interpreters (e.g. COBOL-80, BASIC-80, etc.) for the operating system CP/M and for CPUs compatible with Intel 8080, e.g. Zilog Z80. These were the main Microsoft products before its involvement with MS-DOS. I have used FORTRAN-80 quite a lot, before being able to use an IBM PC compatible computer. An 8080 or Z80 was able to do only about 100 (@ 2 MHz) to 200 (@ 4 MHz) double-precision floating-point operations per second. When I was able to use for the first-time a PC/AT with an 80386DX @ 25 MHz with coprocessor, which could do 100 thousand such operations per second, I recompiled an older FORTRAN-80 program and its run time dropped from 1 hour on CP/M to a few seconds on the PC/AT. Obviously I was very impressed.
Koshkin 5y ago
I think the reason for the absence of good string handling in Fortran was that strings are rarely (if ever) used in mathematical formulas.
- jhallenworld 5y ago
  True, but there was a time when FORTRAN was the most portable language, which meant that it certainly did get use beyond math. I've seen compilers and assemblers distributed as FORTRAN source.
- sekia 5y ago
  And writing encoding-agnostic string library is harder than we think, I guess. Notice that the first release of FORTRAN I is earlier than standardization of ASCII. FORTRAN was initially born for IBM 704 then ported to huge variety of machine architectures. So there's no guarantee on internal string representation; It might be EBCDIC, ASCII, or other ancient, machine specific encodings.

53 points by CTOSian 5y ago

Fortran 77 and later versions (most recently Fortran 2018) have strings. There is the limitation that the elements of an array of strings must have equal length, so that ["boy","girl"] is an invalid character array constructor but ["boy ","girl"] is valid. Libraries for manipulating strings in Fortran are listed at https://github.com/Beliavsky/Fortran-code-on-GitHub#strings https://github.com/Beliavsky/Fortran-code-on-GitHub#strings .

mumblemumble 5y ago
I thought that the specific issue was that arrays could only directly contain strings of equal length. Which, yeah, that's necessary in order for array access to be O(1) and for any sorts of vector intrinsics or striding operations to work properly. The way to get around that is by sticking the actual string on the heap somewhere and only storing a pointer to it in the array. This isn't a unique problem to Fortran; it's how basically every programming language does it. The difference is that Fortan doesn't automatically heap allocate them for you - you've got to manually box them with a derived type - and that most other languages don't even give you the option of strings without pointer chasing. I would argue that, while this characteristic is certainly going to seem weird to anyone who's used to a higher-level language, in a language like Fortran where the primary use case is high performance computing, putting the programmer in charge of these sorts of decisions is neither a bug nor a wart; it's a huge feature.
- terminalcommand 5y ago
  I agree, this makes sense, having O(1) access to all items in a string array seems logical to me, you would also avoid problems with forgetting \n termination like in C.
  - mumblemumble 5y ago
    Though it does create its own separate class of potential bugs. When you assign some text to a fixed-length string, Fortran will silently truncate or space-pad it to make it the correct length.
ok123456 5y ago
In Fortran-90 and beyond you could just have an array of pointers to strings, which would be analogous to the normal behavior in most languages.

mumblemumble 5y ago

Very nice; I haven't used it, but I gather that Fortran-80 was severely lacking in string handling. That said, I feel compelled to point out that one shouldn't judge Fortran as a whole by the need for a library like this in a 40 year old version of the language. I'm still learning the language, so I can't speak with a lot of authority, but it seems to me that, while Fortran is never going to be my favorite language for text munging, its string handling has come a long, long way between then and the Fortran 2018 standard.

Bostonian 5y ago
There was no Fortran 80 standard. There was Fortran IV aka Fortran 66, Fortran 77, Fortran 90, and following, most recently Fortran 2018.
- mumblemumble 5y ago
  There wasn't a Fortran-80 standard, but there was a Fortran-80. Kind of like how there isn't a C# 2005 standard. That's a specific dialect of C# associated with a commercial compiler. The closest standard is the C# 4th edition ISO standard, which covers a subset of C# 2005's features. But it's still OK to refer to C# 2005 as a thing. I think that this is a useful distinction to make in Fortran-land. I haven't used any of these old Fortran compilers, but my understanding is that they were all significantly different and more-or-less mutually incompatible. The Fortran standard had a minimal standard library, so things like what functions you had available for string manipulation depended more on the compiler you used.
  - adrian_b 5y ago
    Yes, FORTRAN-80 was a Microsoft product, belonging to a suite of compilers and interpreters (e.g. COBOL-80, BASIC-80, etc.) for the operating system CP/M and for CPUs compatible with Intel 8080, e.g. Zilog Z80. These were the main Microsoft products before its involvement with MS-DOS. I have used FORTRAN-80 quite a lot, before being able to use an IBM PC compatible computer. An 8080 or Z80 was able to do only about 100 (@ 2 MHz) to 200 (@ 4 MHz) double-precision floating-point operations per second. When I was able to use for the first-time a PC/AT with an 80386DX @ 25 MHz with coprocessor, which could do 100 thousand such operations per second, I recompiled an older FORTRAN-80 program and its run time dropped from 1 hour on CP/M to a few seconds on the PC/AT. Obviously I was very impressed.

Koshkin 5y ago

I think the reason for the absence of good string handling in Fortran was that strings are rarely (if ever) used in mathematical formulas.

jhallenworld 5y ago
True, but there was a time when FORTRAN was the most portable language, which meant that it certainly did get use beyond math. I've seen compilers and assemblers distributed as FORTRAN source.
sekia 5y ago
And writing encoding-agnostic string library is harder than we think, I guess. Notice that the first release of FORTRAN I is earlier than standardization of ASCII. FORTRAN was initially born for IBM 704 then ported to huge variety of machine architectures. So there's no guarantee on internal string representation; It might be EBCDIC, ASCII, or other ancient, machine specific encodings.