BITS type in F202Y

[Beliavsky]

@FortranFan

What this vote shows is the standard development process is not working for the practitioners of Fortran.

1. too many things are not getting done because too many aspects are seen as insufficiently useful or not useful by a few people - six in this instance, but often by just one most influential non-voting member. More often than not, it is due to non-technical factors - fewer resources at compiler vendors like NAG who are spread too thin, burnt out, jaded, uninterested, inadequate budget, more interested in managed decline of Fortran, I-don’t-like-your-design-so-let-it-die, etc. are aspects among these non-technical factors that cannot be ruled out; if anything, they may be at play strongly.

Malcolm Cohen of NAG implemented the first Fortran 90 compiler and is the coauthor of the most authoritative book on Fortran, Modern Fortran Explained. The NAG compiler has been known for keeping up with the Fortran standards. One should not impugn the motives of others without evidence.

[rwmsu]

BITS is one of those things that have been proposed that I haven’t paid much attention to. I’m curious. can someone please explain the
following.

1. Just what are the technical issues related to implementing BITS in modern compilers

2. Are the major objections to BITS that you are creating a new data type and how that type would interact with the current 2s complement integers

3. I presume that BITS are proposed as an alternative to unsigned integers (true ?). If true why not just make the sign status (signed - 2s complement or unsigned) an attribute of an existing integer type.
   ie. integer(INT8), unsigned :: bits. To me that looks like the path of least resistance.

Again, just curious.

[everythingfunctional]

My understanding is that:

1. There aren’t really much difficulties in implementing the type in a compiler
2. This is where the main objection comes. The use cases presented thus far either:
   a. are achievable with the current feature set (i.e. integer variables and BOZ constants and the bit intrinsics)
   b. would require the standard to dictate the underlying representation of integers (i.e. signed magnitude vs 2’s complement and big vs little-endian)
3. There are other reasons to desire unsigned integers, and unsigned integers only solve half of the 2b problem.

So basically, given 2a, the committee doesn’t see it as a high priority worth adding the complexity of a new intrinsic type to the standard, and 2b is a non-starter.

I’m not opposed to the idea, but you have to present to the committee a realistic, real-world problem that cannot be solved without the addition of the feature. It also helps if you’re willing to be the person to develop the requirements, specifications, syntax and exact edits to the standard.

[RonShepard]

@everythingfunctional

I’m not opposed to the idea, but you have to present to the committee a realistic, real-world problem that cannot be solved without the addition of the feature.

That is setting a pretty high bar for a new feature to the language. I doubt if there are many features of modern fortran, compared to f77 and earlier, that actually meet that requirement. Instead, I think it should be sufficient to show that it is an improvement to the language in some way, that it removes some ambiguity, that it improves efficiency or performance, that it allows clear and simple code to accomplish some task, that it is less error prone, or that it enhances portability.

A proposed feature might do more than one of those things, and if it does do more than one of those things, then that should not disqualify it from consideration. I would say that a feature that does more than one of those things should be more attractive, not less.

Regarding the BITS data type and unsigned integers, I think they would both be useful. There are some problems that might benefit from either addition to the language, but that is not a reason to exclude either or both features from consideration. In a full-featured language, there will always be multiple ways to solve some given problem.

I think of the BITS data type as being useful for treating bit strings of arbitrary length, including lengths longer than the longest integer. There is no need to support arithmetic with BITS objects, but the useful bitwise operations (.and., .or., .xor., .not., and so on) should be supported. An unsigned integer type/kind however should support arithmetic operations, addition, subtraction, multiplication, division, along with bitwise operators, but only on the supported integer lengths, not necessarily arbitrary length bit strings. There are certainly specific problems that could be solved with either approach (or that can be done now with the current language features), but that should not disqualify either feature from being added to the language.

[everythingfunctional]

@RonShepard

That is setting a pretty high bar for a new feature to the language.

It is, but that is how the committee prioritises its time. We don’t have enough people working on the standard to add everything everybody wants all at once, so they put new capabilities slightly ahead of making some things easier.

@RonShepard

I think it should be sufficient to show that it is an improvement to the language in some way, that it removes some ambiguity, that it improves efficiency or performance, that it allows clear and simple code to accomplish some task, that it is less error prone, or that it enhances portability.

These aspects do come into play, and you’re right, there are some features that don’t meet the “new capability” threshold because they are sufficiently compelling in multiple of those other aspects. To this point, BITS hasn’t seemed compelling enough to enough of the members in those other categories. That said, if somebody felt sufficiently passionate about it to volunteer

@everythingfunctional

to be the person to develop the requirements, specifications, syntax and exact edits to the standard.

it would have a better chance.

[sblionel]

BITS is unusual in that it does have full specification, syntax and even edits, though against an older standard. Adding a completely new form of data type to a compiler, especially one that’s been around a while, is not easy - but could be done if the feature had significant benefit. As I’ve written upthread, the major case against BITS is that there are few realistic use cases where the existing facilities cannot be used or are too cumbersome. It was different in 2008. The committee has rejected BITS three times now.

[FortranFan]

@Beliavsky

… One should not impugn the motives of others without evidence.

You should take your advice instead to the J3 and WG5 committees and ask them to not impugn the needs of Fortran practitioners.

[certik]

@FortranFan your objections against the committee are well-known, and you are welcome to express them here. At the same time, it is not productive to be repeating them in almost every thread; for example this thread is about BITS. It’s not about how the committee could be improved, so your comments are off-topic.

So I have an idea: why don’t you pick a thread where you summarize your objections against the committee, and then if it is relevant to other threads, just post a link to the relevant post. That way we can keep the threads like this BITS one technical, and your objections are kept elsewhere and people who are interested in discussing it can do so there (and others who are not interested can just ignore that thread); and here we can discuss the BITS proposal, and not worry about unrelated issues.