On Fri, 24 Dec 2021 14:07:17 +0100, Andreas Eder <a_eder_muc@web.de>
wrote:

>On Do 23 Dez 2021 at 16:10, MitchAlsup <MitchAlsup@aol.com> wrote:
>
>> Adding it syntactically into the language would allow the offset and width
>> to be anything in the range of an integer--imagine a bit field 11,357 bits long
>> at offset 1,496 into a 29,000-bit container--and the compiler knows what code
>> to produce. That is: real bit fields.
>> <
>> Perhaps this is a job for C++
>
>Just gave a look into Common Lisp!
>
>'Andreas

+1

Or a modern Scheme.

George

On Saturday, December 25, 2021 at 6:17:05 AM UTC+2, Ivan Godard wrote:
> On 12/24/2021 3:52 PM, Bakul Shah wrote:
> > On 12/24/21 1:29 PM, JimBrakefield wrote:
> >> At my current level of understanding:
> >> An interesting feature of Zig is that instead of a macro or
> >> preprocessor the compiler
> >> will execute at compile time anything the can be computed at compile time
> >> (including type expressions). Thus the language itself is it's own
> >> preprocessor.
> >> And like the RTL languages, simplification and reduction is carried as
> >> far as possible.
> >
> > The "V" language also does this. But this is not the same as decent
> > macro processing. Scheme/CL macros allow you to abstract away details
> > very nicely but for that to work, there needs to a language syntax model
> > the macros can access. This is much simpler in S-expr languages since
> > the AST *is* the concrete syntax (more or less)!
> SmallTalk had the execution context accessible and mutable by the
> running program, including during translation. Rarely used but immensely
> powerful. I once did a co-routine system where "visit" severed the call
> stack in the middle and rehooked it to the top of the call stack of the
> visitee.
>
> But second order usage is hard to grok. Unfortunately, reality is second
> order. Probably has to be, or it wouldn't be real. That's an example.

Probably, I have to think about it.
Even more probably, I wouldn't.

According to Thomas Koenig <tkoenig@netcologne.de>:
># The PL/C compiler had the unusual capability of never failing
># to compile any program, through the use of extensive automatic
># correction of many syntax errors and by converting any remaining
># syntax errors to output statements.
>
>That sounds dubious to me, errors should be reported (in a useful
>and friendly manner), but auto-correction... DWIM never really
>worked.

Students punched their programs on cards, fed them through the card reader,
and waited, often quite a while, for the printed results. In that environment,
making a guess about what the user intended was better than nothing and could
help reduce the number of runs until the program worked.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> schrieb:
> According to Thomas Koenig <tkoenig@netcologne.de>:
>># The PL/C compiler had the unusual capability of never failing
>># to compile any program, through the use of extensive automatic
>># correction of many syntax errors and by converting any remaining
>># syntax errors to output statements.
>>
>>That sounds dubious to me, errors should be reported (in a useful
>>and friendly manner), but auto-correction... DWIM never really
>>worked.
>
> Students punched their programs on cards, fed them through the card reader,
> and waited, often quite a while, for the printed results. In that environment,
> making a guess about what the user intended was better than nothing and could
> help reduce the number of runs until the program worked.

That sounds reasonable.

These days, it is often more useful to stop after the first error, or
first few errors, to avoid the confusing cascade of subsequent errors.

Second-order programming was needed (or at least very useful!) for day
24 of this year's Advent of Code (https://adventofcode.com/2021/day/24)

(From that page:)
The ALU is a four-dimensional processing unit: it has integer variables
w, x, y, and z. These variables all start with the value 0. The ALU also
supports six instructions:

inp a - Read an input value and write it to variable a.
add a b - Add the value of a to the value of b, then store the result in
variable a.
mul a b - Multiply the value of a by the value of b, then store the
result in variable a.
div a b - Divide the value of a by the value of b, truncate the result
to an integer, then store the result in variable a. (Here, "truncate"
means to round the value toward zero.)
mod a b - Divide the value of a by the value of b, then store the
remainder in variable a. (This is also called the modulo operation.)
eql a b - If the value of a and b are equal, then store the value 1 in
variable a. Otherwise, store the value 0 in variable a.
In all of these instructions, a and b are placeholders; a will always be
the variable where the result of the operation is stored (one of w, x,
y, or z), while b can be either a variable or a number. Numbers can be
positive or negative, but will always be integers.

The ALU has no jump instructions; in an ALU program, every instruction
is run exactly once in order from top to bottom. The program halts after
the last instruction has finished executing.
(end quote)

The puzzle was that we were given an (obviously branchless!) program
written for this ALU, it consisted of 14 sections all starting with an
inp() instruction, each of which would consume a single non-zero digit,
and we had to figure out which maximally large 14-digit number would
cause the Z register to end up as Zero.

So I obviously started by writing an interpreter for this very simple
ALU, then for the next stage I added a "cross-compiler", i.e. the
interpreter would output a single statement in my favorite language,
doing the same thing, and I then imported this as a new "fastALU()"
function, totally removing the interpreter overhead.

I still had to spend quite a while figuring out the actual logic
implemented by each of these 14 sections (here's one of them):

inp w
mul x 0
add x z
mod x 26
div z 26
add x -6
eql x w
eql x 0
mul y 0
add y 25
mul y x
add y 1
mul z y
mul y 0
add y w
add y 12
mul y x
add z y

This can (with some effort) be translated into:

w = input_digit();
x = z % 26 - 6;
z /= 26;
if (x != w) {
z = z * 26 + w + 12;
}

Similar but slightly different logic for ech of the sections, crucially
half of them would add 10 or more to x (instead of adding/subtracting a
small value like the -6 above), guaranteeing (x != w), and therefore
always multiplying z by 26!

Closer to the end I realized that I could start with the last section
and work out which combinations of starting w,x,y,z would cause z to be
zero, then use that (quite short list!) as the possible end points for
section 13 etc.

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 12/25/21 5:40 AM, Andreas Eder wrote:
> On Sa 25 Dez 2021 at 01:42, Bakul Shah <bakul@iitbombay.org> wrote:
>
>> On 12/25/21 12:11 AM, Andreas Eder wrote:
>>> On Fr 24 Dez 2021 at 15:48, Bakul Shah <bakul@iitbombay.org> wrote:
>>>
>>>> The macro languages of Scheme and Common Lisp are quite powerful.
>>> This is true.
>>>
>>>> CL's much more so than Scheme's.
>>> That is not so. Theoretically (and practically) thet are on the same
>>> level, but Scheme has several different macro systems - even a hygienic
>>> one.
>>
>> Note that I am not an expert in this area but everything I
>> have read so far says CL macros are more powerful than
>> Scheme's. Scheme's are *safer* but less powerful. See for
>> instance
>> https://letoverlambda.com/index.cl/guest/chap3.html#sec_4
>> where the author says:
>> Hygienic macros are, in the best of situations, a beginner's
>> safety guard-rail; in the worst of situations they form an
>> electric fence, trapping their victims in a sanitised,
>> capture-safe prison. Furthermore, recent research has shown
>> that hygienic macro systems like those specified by various
>> Scheme revisions can still be vulnerable to many interesting
>> capture problems
>
> The problem with Scheme is, that there are different standards (RxRS for
> x from 5 to 7) but in a scheme that supports syntax-case zou can define
> CL's defmacro and some implementations already have it (maybe under yhe
> name of define-macro).
>
> For more about that topic you should read
> https://stackoverflow.com/questions/19664993/is-it-possible-to-implement-common-lisps-macro-system-in-scheme
>
> That should clarify the point better than I could here.

Can any of the RnRS Schemes do reader macros?

On Sa 25 Dez 2021 at 15:17, Bakul Shah <bakul@iitbombay.org> wrote:

> Can any of the RnRS Schemes do reader macros?

No, I don't think so.
But reader macros are a different kettle of fish.

'Andreas

Guillaume <message@bottle.org> writes:

>> [suggestion to add a simple feature to the C standard]

> [...] as far as I've seen, the process of adding a new feature in
> the C standard usually implies that it can't be done portably
> otherwise.

Certainly that has been the case up to now.

Ivan Godard <ivan@millcomputing.com> writes:

> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
> <snip>
>
>> Not necessarily an answer but an observation: in C no new language
>> feature is needed, because C has the C preprocessor. It isn't hard
>> to write a macro that does the necessary shifting and masking (and
>> these days compilers are mostly smart enough to recognize the common
>> patterns and translate them efficiently and in machine-specific
>> ways).
>
> The C preprocessor is an invention of the Devil.

Note that I was neither touting nor defending the C preprocessor.
Just making an observation.

> It lacks the power of a real macro language like m4, yet has all
> the drawbacks of scopeless text substitution.

In the particular case of handling bit subfields, scopeless text
substitution is well up to the job.

> About 25 or so years ago I wrote an LALR(1) table generator and parser
> with autocorrect. Autocorrect worked quite well.

I'm still wondering why these kinds of parsers aren't more common.
I find them great for users in that they not only pin point syntax
errors but they even come with a clear description of how it can be
fixed. It's hard to generate error message of comparable value by hand.

Stefan

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
>
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>
>>> On 12/20/2021 10:21 AM, James Van Buskirk wrote:
>>>
>>>> "Stephen Fuld" wrote in message news:spqc1d$oio$1@dont-email.me...
>>>>
>>>>> A compiler I used to use (it was for Fortran, but this
>>>>> functionality is not Fortran specific) had a pseudo function named
>>>>> "Bits". It looked like a function that accepted three arguments,
>>>>> a variable name and a starting bit number and number of bits, both
>>>>> of which could be a constant or an integer variable. One of its
>>>>> unique properties is that it could also be used on the left hand
>>>>> side of an assignment statement.
>>>>>
>>>>> This feature led to very clear, concise code, that the compiler
>>>>> didn't have to go through a complex algorithms to recognize, and
>>>>> would generate optimal, inline code. There was sort of a pragma
>>>>> that could optionally generate checking code for out of range
>>>>> combinations of length and starting bit number.
>>>>>
>>>>> So, for example, the source code to move two bits starting at bit
>>>>> 3 of variable B to starting at bit 4 of variable A would be
>>>>>
>>>>> Bits (A, 2, 4) = Bits (B, 2, 3)
>>>>>
>>>>> I always liked this feature, and used it a fair amount.
>>>>
>>>> Compare
>>>> https://gcc.gnu.org/onlinedocs/gfortran/IBITS.html#IBITS
>>>> https://gcc.gnu.org/onlinedocs/gfortran/MVBITS.html#MVBITS
>>>> which are both elemental.
>>>
>>> They seem essentially equivalent. It says that these came in with
>>> Fortran 90. The compiler I was referring to had its roots in a
>>> predecessor with a different name that dated back to at least the
>>> early 1970s. I am glad the idea became standardized.
>>>
>>> I guess I should ask the question that given that C is probably used
>>> for bit manipulation stuff at least as much as Fortran, how come the
>>> C standard didn't pick up some equivalent?
>>
>> Not necessarily an answer but an observation: in C no new language
>> feature is needed, because C has the C preprocessor. It isn't hard
>> to write a macro that does the necessary shifting and masking (and
>> these days compilers are mostly smart enough to recognize the common
>> patterns and translate them efficiently and in machine-specific
>> ways).
>
> While you are right, of course, about the preprocessor, I guess it
> comes down to me having a different philosophy of language design,
> than what Mitch expressed in his (sarcastic) comment.

Sorry, I thought the question was why it hasn't been done, not
why it should or shouldn't be done.

>> Having a straightforward way to succinctly express the requirement
>> is <ahem> Not 'C'.

You are attributing to me something I didn't say. Please don't
do that.

> The problem with the preprocessor approach is that everyone will
> code their own macro, possibly with different syntax, so I have to
> learn what you did, then if I move to a different project, what they
> did etc. That is the beauty of a standard. (Unless you are talking
> about having the preprocessor macro standardized.)
>
> Compare with, for example, integer division. It is part of the
> standard, even though fairly rarely used. If bit field extraction
> and insertion are reasonably well used (and I am guessing they are -
> at least as much as they are used in Fortran, though probably less
> than division), then I feel they should be standardized to ease the
> programmer's job.

Manipulating bit fields can easily be synthesized using other
existing operators. Division does not have that property.

Also there is the question of how often shift/masking bitfield
manipulation comes up. I have looked at a fair bit of C code
over the years and I just don't see this very often. Probably it
does occur routinely in some application areas, but certainly not
most of them.

The idea that feature X should be added to a language standard
just for the sake of commonality leads inexorably to a language
overloaded with features that are used only rarely. Better to
follow the principle expressed by Tony Hoare: a language should
have only those features that are going to be used in every
program.

Ivan Godard <ivan@millcomputing.com> writes:

> On 12/24/2021 3:52 PM, Bakul Shah wrote:
>
>> On 12/24/21 1:29 PM, JimBrakefield wrote:
>>
>>> At my current level of understanding:
>>> An interesting feature of Zig is that instead of a macro or
>>> preprocessor the compiler
>>> will execute at compile time anything the can be computed at compile time
>>> (including type expressions). Thus the language itself is it's own
>>> preprocessor.
>>> And like the RTL languages, simplification and reduction is carried
>>> as far as possible.
>>
>> The "V" language also does this. But this is not the same as decent
>> macro processing. Scheme/CL macros allow you to abstract away details
>> very nicely but for that to work, there needs to a language syntax model
>> the macros can access. This is much simpler in S-expr languages since
>> the AST *is* the concrete syntax (more or less)!
>
> SmallTalk

Let me remind you again: Smalltalk, not SmallTalk.

> had the execution context accessible and mutable by the
> running program, including during translation.

When code is running, yes. When code is being compiled, no.
It's been quite a few years since I used a Smalltalk system,
but most code was written and compiled using a conventional
compilation model, without any way to execute code as part
of the compilation process.

Guillaume <message@bottle.org> writes:

> Le 23/12/2021 at 20:37, MitchAlsup a ecrit:
>
>> The only benefit to developers would be some kind of syntactic
>> sugar to make bit fields easier to specify::
>> a<3:17> = b<9:23>;
>
> Oh, I perfectly get that, and I agree this notation would be quite
> nice.
>
>> Macros seem to fail in that they cannot do syntactic sugar things.
>
> Not this kind, indeed. But the whole question regarding the
> standard is, is it really worth it to make additions to it just
> for some syntactic sugar? This is not the spirit of C.
>
> But in that same vein, I would have a number of other notations I
> would like to have in C. A lot more than just this. Thing is,
> who knows where that would lead the language.

If you got some other people to join you and add their notations
to yours, it would lead C further down the path of turning C into
the clusterfuck that C++ has become. (And I should add, with no
disrespect intended for the features you are considering.)

I predict it won't be too long before someone suggests adding
templates to C. There is already a proposal to add constexpr.
Ick.

On 12/27/2021 12:46 AM, Tim Rentsch wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>
>> On 12/24/2021 3:52 PM, Bakul Shah wrote:
>>
>>> On 12/24/21 1:29 PM, JimBrakefield wrote:
>>>
>>>> At my current level of understanding:
>>>> An interesting feature of Zig is that instead of a macro or
>>>> preprocessor the compiler
>>>> will execute at compile time anything the can be computed at compile time
>>>> (including type expressions). Thus the language itself is it's own
>>>> preprocessor.
>>>> And like the RTL languages, simplification and reduction is carried
>>>> as far as possible.
>>>
>>> The "V" language also does this. But this is not the same as decent
>>> macro processing. Scheme/CL macros allow you to abstract away details
>>> very nicely but for that to work, there needs to a language syntax model
>>> the macros can access. This is much simpler in S-expr languages since
>>> the AST *is* the concrete syntax (more or less)!
>>
>> SmallTalk
>
> Let me remind you again: Smalltalk, not SmallTalk.
>
>> had the execution context accessible and mutable by the
>> running program, including during translation.
>
> When code is running, yes. When code is being compiled, no.
> It's been quite a few years since I used a Smalltalk system,
> but most code was written and compiled using a conventional
> compilation model, without any way to execute code as part
> of the compilation process.

Yes: most people use only the first order aspects of second order systems.

On 12/27/2021 12:30 AM, Tim Rentsch wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>
>> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
>>
>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>>
>>>> On 12/20/2021 10:21 AM, James Van Buskirk wrote:
>>>>
>>>>> "Stephen Fuld" wrote in message news:spqc1d$oio$1@dont-email.me...
>>>>>
>>>>>> A compiler I used to use (it was for Fortran, but this
>>>>>> functionality is not Fortran specific) had a pseudo function named
>>>>>> "Bits". It looked like a function that accepted three arguments,
>>>>>> a variable name and a starting bit number and number of bits, both
>>>>>> of which could be a constant or an integer variable. One of its
>>>>>> unique properties is that it could also be used on the left hand
>>>>>> side of an assignment statement.
>>>>>>
>>>>>> This feature led to very clear, concise code, that the compiler
>>>>>> didn't have to go through a complex algorithms to recognize, and
>>>>>> would generate optimal, inline code. There was sort of a pragma
>>>>>> that could optionally generate checking code for out of range
>>>>>> combinations of length and starting bit number.
>>>>>>
>>>>>> So, for example, the source code to move two bits starting at bit
>>>>>> 3 of variable B to starting at bit 4 of variable A would be
>>>>>>
>>>>>> Bits (A, 2, 4) = Bits (B, 2, 3)
>>>>>>
>>>>>> I always liked this feature, and used it a fair amount.
>>>>>
>>>>> Compare
>>>>> https://gcc.gnu.org/onlinedocs/gfortran/IBITS.html#IBITS
>>>>> https://gcc.gnu.org/onlinedocs/gfortran/MVBITS.html#MVBITS
>>>>> which are both elemental.
>>>>
>>>> They seem essentially equivalent. It says that these came in with
>>>> Fortran 90. The compiler I was referring to had its roots in a
>>>> predecessor with a different name that dated back to at least the
>>>> early 1970s. I am glad the idea became standardized.
>>>>
>>>> I guess I should ask the question that given that C is probably used
>>>> for bit manipulation stuff at least as much as Fortran, how come the
>>>> C standard didn't pick up some equivalent?
>>>
>>> Not necessarily an answer but an observation: in C no new language
>>> feature is needed, because C has the C preprocessor. It isn't hard
>>> to write a macro that does the necessary shifting and masking (and
>>> these days compilers are mostly smart enough to recognize the common
>>> patterns and translate them efficiently and in machine-specific
>>> ways).
>>
>> While you are right, of course, about the preprocessor, I guess it
>> comes down to me having a different philosophy of language design,
>> than what Mitch expressed in his (sarcastic) comment.
>
> Sorry, I thought the question was why it hasn't been done, not
> why it should or shouldn't be done.
>
>>> Having a straightforward way to succinctly express the requirement
>>> is <ahem> Not 'C'.
>
> You are attributing to me something I didn't say. Please don't
> do that.

Sorry, I thought that it was clear that I was quoting Mitch, not you.

>> The problem with the preprocessor approach is that everyone will
>> code their own macro, possibly with different syntax, so I have to
>> learn what you did, then if I move to a different project, what they
>> did etc. That is the beauty of a standard. (Unless you are talking
>> about having the preprocessor macro standardized.)
>>
>> Compare with, for example, integer division. It is part of the
>> standard, even though fairly rarely used. If bit field extraction
>> and insertion are reasonably well used (and I am guessing they are -
>> at least as much as they are used in Fortran, though probably less
>> than division), then I feel they should be standardized to ease the
>> programmer's job.
>
> Manipulating bit fields can easily be synthesized using other
> existing operators. Division does not have that property.

I agree that division was a poorly chosen example. But synthesizing bit
fields can get fairly complex (variables for starting bit number and
length, potentially on both the source and the target, with checking to
insure the combinations of length and starting bit number are files are
legal). While you certainly can synthesize this, I would question
whether it is "easy", and, perhaps more importantly, easy for someone
else to comprehend and for you to debug, especially years later. Of
course, YMMV.

> Also there is the question of how often shift/masking bitfield
> manipulation comes up. I have looked at a fair bit of C code
> over the years and I just don't see this very often. Probably it
> does occur routinely in some application areas, but certainly not
> most of them.

I may be wrong, but I expect it occurs in many "close to the metal"
applications, such as embedded code and microcontrollers, OS code,
graphics, etc. ISTM that these are the areas (especially OS) that C was
designed for.

> The idea that feature X should be added to a language standard
> just for the sake of commonality leads inexorably to a language
> overloaded with features that are used only rarely.

Sure. Such decisions are always a tradeoff. But the standardizers of
Fortran apparently thought it occurs often enough to include it in that
language. As I said, however often you think it occurs, I expect that
it would occur more often in C than Fortran.

> Better to
> follow the principle expressed by Tony Hoare: a language should
> have only those features that are going to be used in every
> program.

While I am sure that comment was tongue in cheek, it clearly isn't
practical. The typical "Hello World" program uses no dynamic
allocation, arrays, indeed arithmetic, etc. I am sure that there are
very many C programs that include no floating point, yet I doubt you
oppose its inclusion.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> Better to
> follow the principle expressed by Tony Hoare: a language should
> have only those features that are going to be used in every
> program.

Taken literally, that is rather extreme.

Would you ban file I/O because there are lots of useful programs
which only use standard input and standart output?

Le 27/12/2021 à 09:30, Tim Rentsch a écrit :
> The idea that feature X should be added to a language standard
> just for the sake of commonality leads inexorably to a language
> overloaded with features that are used only rarely.

Yes. And isn't that what C++ exactly is? =)
(Yes, it's a mess, but it might not be politically correct to say this.)

> Better to follow the principle expressed by Tony Hoare: a language should
> have only those features that are going to be used in every
> program.

Oh well. That statement is a bit extreme. But Hoare liked punch lines,
and the point is still made. =)

(Yes, of course extreme. Let's take a trivial example. One can write
entire programs that do not use a single division operator. Does that
mean one should remove it from the language, because not every program
uses it?)

I prefer Wirth's "Make it as simple as possible, but not simpler" quote
that can be found in the Oberon language specs. (And often attributed to
Einstein.) Seemingly conveys the same idea, but in a more realistic, if
slightly more abstract, form.

On Monday, December 27, 2021 at 2:31:05 AM UTC-6, Tim Rentsch wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
>
> > On 12/22/2021 12:24 PM, Tim Rentsch wrote:
> >
> >> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >>
> >>> On 12/20/2021 10:21 AM, James Van Buskirk wrote:
> >>>
> >>>> "Stephen Fuld" wrote in message news:spqc1d$oio$1...@dont-email.me...
> >>>>
> >>>>> A compiler I used to use (it was for Fortran, but this
> >>>>> functionality is not Fortran specific) had a pseudo function named
> >>>>> "Bits". It looked like a function that accepted three arguments,
> >>>>> a variable name and a starting bit number and number of bits, both
> >>>>> of which could be a constant or an integer variable. One of its
> >>>>> unique properties is that it could also be used on the left hand
> >>>>> side of an assignment statement.
> >>>>>
> >>>>> This feature led to very clear, concise code, that the compiler
> >>>>> didn't have to go through a complex algorithms to recognize, and
> >>>>> would generate optimal, inline code. There was sort of a pragma
> >>>>> that could optionally generate checking code for out of range
> >>>>> combinations of length and starting bit number.
> >>>>>
> >>>>> So, for example, the source code to move two bits starting at bit
> >>>>> 3 of variable B to starting at bit 4 of variable A would be
> >>>>>
> >>>>> Bits (A, 2, 4) = Bits (B, 2, 3)
> >>>>>
> >>>>> I always liked this feature, and used it a fair amount.
> >>>>
> >>>> Compare
> >>>> https://gcc.gnu.org/onlinedocs/gfortran/IBITS.html#IBITS
> >>>> https://gcc.gnu.org/onlinedocs/gfortran/MVBITS.html#MVBITS
> >>>> which are both elemental.
> >>>
> >>> They seem essentially equivalent. It says that these came in with
> >>> Fortran 90. The compiler I was referring to had its roots in a
> >>> predecessor with a different name that dated back to at least the
> >>> early 1970s. I am glad the idea became standardized.
> >>>
> >>> I guess I should ask the question that given that C is probably used
> >>> for bit manipulation stuff at least as much as Fortran, how come the
> >>> C standard didn't pick up some equivalent?
> >>
> >> Not necessarily an answer but an observation: in C no new language
> >> feature is needed, because C has the C preprocessor. It isn't hard
> >> to write a macro that does the necessary shifting and masking (and
> >> these days compilers are mostly smart enough to recognize the common
> >> patterns and translate them efficiently and in machine-specific
> >> ways).
> >
> > While you are right, of course, about the preprocessor, I guess it
> > comes down to me having a different philosophy of language design,
> > than what Mitch expressed in his (sarcastic) comment.
>
> Sorry, I thought the question was why it hasn't been done, not
> why it should or shouldn't be done.
>
> >> Having a straightforward way to succinctly express the requirement
> >> is <ahem> Not 'C'.
>
> You are attributing to me something I didn't say. Please don't
> do that.
<
The attribution goes all the bay back to a cute girl from HP on the C89
ANSI effort.
>
> > The problem with the preprocessor approach is that everyone will
> > code their own macro, possibly with different syntax, so I have to
> > learn what you did, then if I move to a different project, what they
> > did etc. That is the beauty of a standard. (Unless you are talking
> > about having the preprocessor macro standardized.)
> >
> > Compare with, for example, integer division. It is part of the
> > standard, even though fairly rarely used. If bit field extraction
> > and insertion are reasonably well used (and I am guessing they are -
> > at least as much as they are used in Fortran, though probably less
> > than division), then I feel they should be standardized to ease the
> > programmer's job.
>
> Manipulating bit fields can easily be synthesized using other
> existing operators. Division does not have that property.
>
> Also there is the question of how often shift/masking bitfield
> manipulation comes up. I have looked at a fair bit of C code
> over the years and I just don't see this very often. Probably it
> does occur routinely in some application areas, but certainly not
> most of them.
>
> The idea that feature X should be added to a language standard
> just for the sake of commonality leads inexorably to a language
> overloaded with features that are used only rarely. Better to
> follow the principle expressed by Tony Hoare: a language should
> have only those features that are going to be used in every
> program.
<
So, printf() should not be in the language: check.

On Monday, December 27, 2021 at 7:10:56 PM UTC+2, Stephen Fuld wrote:
> On 12/27/2021 12:30 AM, Tim Rentsch wrote:
> > Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >
> >> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
> >>
> >>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >>>
> >>>> On 12/20/2021 10:21 AM, James Van Buskirk wrote:
> >>>>
> >>>>> "Stephen Fuld" wrote in message news:spqc1d$oio$1...@dont-email.me...
> >>>>>
> >>>>>> A compiler I used to use (it was for Fortran, but this
> >>>>>> functionality is not Fortran specific) had a pseudo function named
> >>>>>> "Bits". It looked like a function that accepted three arguments,
> >>>>>> a variable name and a starting bit number and number of bits, both
> >>>>>> of which could be a constant or an integer variable. One of its
> >>>>>> unique properties is that it could also be used on the left hand
> >>>>>> side of an assignment statement.
> >>>>>>
> >>>>>> This feature led to very clear, concise code, that the compiler
> >>>>>> didn't have to go through a complex algorithms to recognize, and
> >>>>>> would generate optimal, inline code. There was sort of a pragma
> >>>>>> that could optionally generate checking code for out of range
> >>>>>> combinations of length and starting bit number.
> >>>>>>
> >>>>>> So, for example, the source code to move two bits starting at bit
> >>>>>> 3 of variable B to starting at bit 4 of variable A would be
> >>>>>>
> >>>>>> Bits (A, 2, 4) = Bits (B, 2, 3)
> >>>>>>
> >>>>>> I always liked this feature, and used it a fair amount.
> >>>>>
> >>>>> Compare
> >>>>> https://gcc.gnu.org/onlinedocs/gfortran/IBITS.html#IBITS
> >>>>> https://gcc.gnu.org/onlinedocs/gfortran/MVBITS.html#MVBITS
> >>>>> which are both elemental.
> >>>>
> >>>> They seem essentially equivalent. It says that these came in with
> >>>> Fortran 90. The compiler I was referring to had its roots in a
> >>>> predecessor with a different name that dated back to at least the
> >>>> early 1970s. I am glad the idea became standardized.
> >>>>
> >>>> I guess I should ask the question that given that C is probably used
> >>>> for bit manipulation stuff at least as much as Fortran, how come the
> >>>> C standard didn't pick up some equivalent?
> >>>
> >>> Not necessarily an answer but an observation: in C no new language
> >>> feature is needed, because C has the C preprocessor. It isn't hard
> >>> to write a macro that does the necessary shifting and masking (and
> >>> these days compilers are mostly smart enough to recognize the common
> >>> patterns and translate them efficiently and in machine-specific
> >>> ways).
> >>
> >> While you are right, of course, about the preprocessor, I guess it
> >> comes down to me having a different philosophy of language design,
> >> than what Mitch expressed in his (sarcastic) comment.
> >
> > Sorry, I thought the question was why it hasn't been done, not
> > why it should or shouldn't be done.
> >
> >>> Having a straightforward way to succinctly express the requirement
> >>> is <ahem> Not 'C'.
> >
> > You are attributing to me something I didn't say. Please don't
> > do that.
> Sorry, I thought that it was clear that I was quoting Mitch, not you.
> >> The problem with the preprocessor approach is that everyone will
> >> code their own macro, possibly with different syntax, so I have to
> >> learn what you did, then if I move to a different project, what they
> >> did etc. That is the beauty of a standard. (Unless you are talking
> >> about having the preprocessor macro standardized.)
> >>
> >> Compare with, for example, integer division. It is part of the
> >> standard, even though fairly rarely used. If bit field extraction
> >> and insertion are reasonably well used (and I am guessing they are -
> >> at least as much as they are used in Fortran, though probably less
> >> than division), then I feel they should be standardized to ease the
> >> programmer's job.
> >
> > Manipulating bit fields can easily be synthesized using other
> > existing operators. Division does not have that property.
> I agree that division was a poorly chosen example. But synthesizing bit
> fields can get fairly complex (variables for starting bit number and
> length, potentially on both the source and the target, with checking to
> insure the combinations of length and starting bit number are files are
> legal). While you certainly can synthesize this, I would question
> whether it is "easy", and, perhaps more importantly, easy for someone
> else to comprehend and for you to debug, especially years later. Of
> course, YMMV.
> > Also there is the question of how often shift/masking bitfield
> > manipulation comes up. I have looked at a fair bit of C code
> > over the years and I just don't see this very often. Probably it
> > does occur routinely in some application areas, but certainly not
> > most of them.
> I may be wrong, but I expect it occurs in many "close to the metal"
> applications, such as embedded code and microcontrollers, OS code,
> graphics, etc. ISTM that these are the areas (especially OS) that C was
> designed for.

I did and do spend significant portion of my time as sw developer in at least part of the above mentioned areas.
And my experience is that it's not a case.
I mean, both extraction from bit field to scalar and insertion of scalar into bit field are indeed not very rare.
But copying of one bit field into another is extremely rare.

> > The idea that feature X should be added to a language standard
> > just for the sake of commonality leads inexorably to a language
> > overloaded with features that are used only rarely.
> Sure. Such decisions are always a tradeoff. But the standardizers of
> Fortran apparently thought it occurs often enough to include it in that
> language. As I said, however often you think it occurs, I expect that
> it would occur more often in C than Fortran.
> > Better to
> > follow the principle expressed by Tony Hoare: a language should
> > have only those features that are going to be used in every
> > program.
> While I am sure that comment was tongue in cheek, it clearly isn't
> practical. The typical "Hello World" program uses no dynamic
> allocation, arrays, indeed arithmetic, etc. I am sure that there are
> very many C programs that include no floating point, yet I doubt you
> oppose its inclusion.
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 12/27/2021 11:50 AM, Michael S wrote:
> On Monday, December 27, 2021 at 7:10:56 PM UTC+2, Stephen Fuld wrote:
>> On 12/27/2021 12:30 AM, Tim Rentsch wrote:

snip

>>> Also there is the question of how often shift/masking bitfield
>>> manipulation comes up. I have looked at a fair bit of C code
>>> over the years and I just don't see this very often. Probably it
>>> does occur routinely in some application areas, but certainly not
>>> most of them.
>> I may be wrong, but I expect it occurs in many "close to the metal"
>> applications, such as embedded code and microcontrollers, OS code,
>> graphics, etc. ISTM that these are the areas (especially OS) that C was
>> designed for.
>
> I did and do spend significant portion of my time as sw developer in at least part of the above mentioned areas.
> And my experience is that it's not a case.
> I mean, both extraction from bit field to scalar and insertion of scalar into bit field are indeed not very rare.
> But copying of one bit field into another is extremely rare.

Oh, I agree with that. But once you have the "syntactical sugar" of
pseudo functions for extraction and insertion, the copying is just there
for free.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Monday, December 27, 2021 at 10:12:22 PM UTC+2, Stephen Fuld wrote:
> On 12/27/2021 11:50 AM, Michael S wrote:
> > On Monday, December 27, 2021 at 7:10:56 PM UTC+2, Stephen Fuld wrote:
> >> On 12/27/2021 12:30 AM, Tim Rentsch wrote:
> snip
> >>> Also there is the question of how often shift/masking bitfield
> >>> manipulation comes up. I have looked at a fair bit of C code
> >>> over the years and I just don't see this very often. Probably it
> >>> does occur routinely in some application areas, but certainly not
> >>> most of them.
> >> I may be wrong, but I expect it occurs in many "close to the metal"
> >> applications, such as embedded code and microcontrollers, OS code,
> >> graphics, etc. ISTM that these are the areas (especially OS) that C was
> >> designed for.
> >
> > I did and do spend significant portion of my time as sw developer in at least part of the above mentioned areas.
> > And my experience is that it's not a case.
> > I mean, both extraction from bit field to scalar and insertion of scalar into bit field are indeed not very rare.
> > But copying of one bit field into another is extremely rare.
> Oh, I agree with that. But once you have the "syntactical sugar" of
> pseudo functions for extraction and insertion, the copying is just there
> for free.

But both for extraction to scalar and for insertion from scalar what Tim said is true - doing them with shifts and masks is easy and not error-prone.
Pay attention that "extraction to scalar" and "insertion from scalar" implies that the bit field is no wider than widest scalar [integer] data type of a given machine, which is already quite significant simplification.

> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 12/27/2021 12:54 PM, Michael S wrote:
> On Monday, December 27, 2021 at 10:12:22 PM UTC+2, Stephen Fuld wrote:
>> On 12/27/2021 11:50 AM, Michael S wrote:
>>> On Monday, December 27, 2021 at 7:10:56 PM UTC+2, Stephen Fuld wrote:
>>>> On 12/27/2021 12:30 AM, Tim Rentsch wrote:
>> snip
>>>>> Also there is the question of how often shift/masking bitfield
>>>>> manipulation comes up. I have looked at a fair bit of C code
>>>>> over the years and I just don't see this very often. Probably it
>>>>> does occur routinely in some application areas, but certainly not
>>>>> most of them.
>>>> I may be wrong, but I expect it occurs in many "close to the metal"
>>>> applications, such as embedded code and microcontrollers, OS code,
>>>> graphics, etc. ISTM that these are the areas (especially OS) that C was
>>>> designed for.
>>>
>>> I did and do spend significant portion of my time as sw developer in at least part of the above mentioned areas.
>>> And my experience is that it's not a case.
>>> I mean, both extraction from bit field to scalar and insertion of scalar into bit field are indeed not very rare.
>>> But copying of one bit field into another is extremely rare.
>> Oh, I agree with that. But once you have the "syntactical sugar" of
>> pseudo functions for extraction and insertion, the copying is just there
>> for free.
>
> But both for extraction to scalar and for insertion from scalar what Tim said is true - doing them with shifts and masks is easy and not error-prone.
> Pay attention that "extraction to scalar" and "insertion from scalar" implies that the bit field is no wider than widest scalar [integer] data type of a given machine, which is already quite significant simplification.

But if the starting bit number and length are variables, not explicit
constants, you might want to have code that checks for "legality" of the
values.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

> Would you ban file I/O because there are lots of useful programs
> which only use standard input and standart output?

Maybe the argument goes that file I/O should not be part of the
language, but part of the library ;-)

Stefan

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>> Would you ban file I/O because there are lots of useful programs
>> which only use standard input and standart output?
>
> Maybe the argument goes that file I/O should not be part of the
> language, but part of the library ;-)

That is not really the case for C anymore. The library is very
much part of the language now, as you will discover if you try to
use reserved names for anything else.

Example:

#include <stdio.h>

double cos(double x)
{ return 3*x;
}

int main()
{ double a = -0.1;
printf ("%f\n", 1+cos(-a));
}

What will this print, both with gcc and with clang?

Guillaume <message@bottle.org> schrieb:
> Le 27/12/2021 à 09:30, Tim Rentsch a écrit :
>> The idea that feature X should be added to a language standard
>> just for the sake of commonality leads inexorably to a language
>> overloaded with features that are used only rarely.
>
> Yes. And isn't that what C++ exactly is? =)
> (Yes, it's a mess, but it might not be politically correct to say this.)

What C++ suffers from isn't feature creep. It's a feature stampede.