[HN Gopher] A simple string handling library for Microsoft Fortr...
___________________________________________________________________
A simple string handling library for Microsoft Fortran-80
Author : CTOSian
Score : 51 points
Date : 2021-08-26 08:20 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mumblemumble wrote:
| 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 wrote:
| There was no Fortran 80 standard. There was Fortran IV aka
| Fortran 66, Fortran 77, Fortran 90, and following, most
| recently Fortran 2018.
| mumblemumble wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Bostonian wrote:
| 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 .
| ok123456 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2021-08-26 23:02 UTC)