A simple string handling library for Microsoft Fortran-80 | Hacker News Reader

A simple string handling library for Microsoft Fortran-80

github.com

53 pointsCTOSian13 comments

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 .

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.

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.

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.

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.

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.

There was no Fortran 80 standard. There was Fortran IV aka Fortran 66, Fortran 77, Fortran 90, and following, most recently Fortran 2018.

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.

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.

> Kind of like how there isn't a C# 2005 standard

Er... no. There is: it's just that C# stopped being published as an ISO Standard after version 2.0, and MS stopped publishing C# as an ECMA Standard a few years ago, but the C# language still has specifications and those specifications have version numbers - and those version numbers are used as compiler flags: `csc /langversion:7.3`, for example.

> But it's still OK to refer to C# 2005 as a thing.

"C# 2005" was C# 2.0, the last version with an ISO spec.

Currently we're on C# 9.0 in .NET 6. C# language spec versions and .NET releases are tied together as new language features have dependencies on BCL features (e.g. C# 8.0's `foreach-await` requires `IAsyncEnumerable` which was added in .NET Core 3: https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/...

That said, the C# language does enjoy relatively good evolution and progress that's almost as rapid as Swift's, and unlike, say, Java, which feels to me like it's progressing at half the speed of C#.

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

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.

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.

Reply on news.ycombinator.com