Le 26/03/2022 à 12:34, antispam@math.uni.wroc.pl a écrit :
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Guillaume <message@bottle.org> writes:
>>> Le 24/03/2022 ? 16:45, Scott Lurndal a ?crit?:
>>>> Richard Harnden <richard.nospam@gmail.com> writes:
>>>>> "C: Everyone's favourite programming language isn't a programming language"
>>>>>
>>>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>>>> The article doesn't make a whole lot of sense - it's basically just
>>>> bitching because swift and rust can't do everything that C can.
>>>
>>> And you're putting it lightly.
>>> Of course, first thing, without even reading it, is questioning the
>>> relevance of such articles written by heavy proponents of
>>> "alternative" languages. How much more biased can one be?
>>>
>>> Digging a bit deeper, there is nothing much to even take from this
>>> short article. It's pretty shallow.
>>>
>>> - C is difficult to parse? C declarations are, for instance, not
>>> exactly easy, but it's only very moderately difficult. You can have
>>> fun with this to get an idea: https://cdecl.org/ . I has never made
>>> it a problem to write a C compiler. There are more of them out there
>>> than for any other language, I think. OTOH, there is, AFAIK, only one
>>> implementation of Rust. Which to me is in itself a problem. I'm
>>> curious to see if it ever even gets to the point of having other
>>> competing implementations.
>>
>> It's probably referring to the typedef issue.
>>
>> In the absence of typedefs, type names consist of keywords and
>> punctuation. A typedef (a feature that was added to the language
>> after the syntax had been established) creates a type name that's an
>> identifier. It's impossible to parse something that uses a typedef name
>> without knowing that it's a typedef name. In effect a typedef adds a
>> context-sensitive keyword to the grammar. The parser needs to query the
>> symbol table.
>
> Using symbol table is just one of possible solutions. Another
> one is to note that true ambiguities are really semantic, so
> parser can return tree faithful to all possible meaning. For
> example, cast versus function call is semantic problem so
> parser can return 'call_or_cast' and let semantic phase
> to decide.

Sure. Then it's down to wanking about what exactly is the parsing part
in your analyzer and what you want done with it. If you're happy with
the output of your "parser" to lack fundamental syntactic information
(yes, I consider determining whether a given token is a type, a
variable, a qualifier, etc, is a syntactic information), why not. That
can always be analyzed later. That doesn't change squat about the final
output of your analysis. And since the output of said "parser" would be
pretty useless by itself, this structure is just an implementation
choice. Possibly making it look more "academically" correct. (Yeah I've
read endless discussions about what parsing exactly was supposed to be.)

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> On Sat, 26 Mar 2022 13:58:04 +0100, Bonita Montero wrote:
>
>>> I am in conflict with people who claim that HTML is not a
>>> programming language, so I have written a German-language
>>> text explaining why HTML is indeed a programming language.
>>> But for C, I'm at a loss, I have no such text prepared for C!
>>
>> A program has a control flow.
>> HTML is a static data-structure without a control flow.
>> So you can't program in HTML.
>
> I disagree. In general, a "program" provides instructions to
> automation (usually computer automation) and need not contain
> control flow. HTML instructs a "web browser" (automated tool) on
> how to display data.

Since HTML makes sense in a context with no concept of "display (spoken,
Braille machine, etc) I think it's odd to say that HTML "instructs" the
display software. I don't think it's clear cut, mind, but I would want
a stronger case to made before changing my mind.

I'd ask you the same question I asked Stefan Ram: what's the minimum
markup you would accept? None? Is plain ASCII text instructing the
display software?

(This is not a trick question. I like to understand positions that are
at odds with my intuition, and investigating the corner cases is useful
here.)

> In that respect, you can write HTML, and the
> resulting text will act as a "program" for a web browser. A
> similar argument can be made for GCODE (the way 3D printers and
> automated mills are "programmed") or even the punch cards used
> to control a Jacquard loom.
>
> However, most here (of which I am one) would probably first think
> of code written in a Turing-complete language as a "program". A
> Turing-complete language /does/ have control flow. If we restrict
> "programming" to "writing in Turing-complete languages", then we
> exclude HTML, GCODE, and a large number of other human-planned
> automated process controls from "programming".

I don't think most people would really insist on a notation that's
Turing complete. For example, one designed so algorithms always
terminate will look for all the world like a programming language. And
you can have almost as many bugs and difficulties in programming using
it.

--
Ben.

Bart <bc@freeuk.com> writes:

> This is the kind of thing I'm talking about:
>
> void (*)(void)
> void (**)(void)
> void (***)(void)
> void *(*)(void)
> void **(*)(void)
>
> I wouldn't even know where to start with using typedefs to express
> these more clearly; perhaps:
>
> typedef void F(void);
> typedef void* G(void);
> typedef void** H(void);

I wouldn't do that. I would (a) use a good name, and (b) not worry
about the "inner" pointers at all:

// A simple action is a parameterless function that returns nothing:
typedef void simple_action(void);

simple_action *action_ptr;
simple_action **indirect_action_ptr;

// and I won't try to invent a name for a pointer to a pointer to a
// pointer to an action. It's most likely to be result parameter.

// The data are accessed with parameterless functions that return
// universal pointers:
typedef void *data_access_function(void);

data_access_function *accessor_ptr;
data_access_function **indirect_accessor_ptr;

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>
>> On Sat, 26 Mar 2022 13:58:04 +0100, Bonita Montero wrote:
>>
>>>> I am in conflict with people who claim that HTML is not a
>>>> programming language, so I have written a German-language
>>>> text explaining why HTML is indeed a programming language.
>>>> But for C, I'm at a loss, I have no such text prepared for C!
>>>
>>> A program has a control flow.
>>> HTML is a static data-structure without a control flow.
>>> So you can't program in HTML.
>>
>> I disagree. In general, a "program" provides instructions to
>> automation (usually computer automation) and need not contain
>> control flow. HTML instructs a "web browser" (automated tool) on
>> how to display data.
>
>Since HTML makes sense in a context with no concept of "display (spoken,
>Braille machine, etc) I think it's odd to say that HTML "instructs" the
>display software. I don't think it's clear cut, mind, but I would want
>a stronger case to made before changing my mind.

HTML is really just a non-canonical XML document. It is a descriptive
layout language, more verbose than, but little different from RUNOFF.

Now you can build a flow around XML; I once worked on a B2B solution
(written in Java) that accepted XML documents as input, applied one or
more XSL style sheets to the document to transform it into database queries,
updates, or HTML display instructions using data flow technology.

One would drag-n-drop components from a toolbox, link them together
and customize the queries, provides transformations (style-sheets)
to produce output HTML, or output XML or output text. This was basically
a visual programming language.

Guillaume <message@bottle.org> wrote:
> Le 26/03/2022 ? 12:34, antispam@math.uni.wroc.pl a ?crit?:
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >> Guillaume <message@bottle.org> writes:
> >>> Le 24/03/2022 ? 16:45, Scott Lurndal a ?crit?:
> >>>> Richard Harnden <richard.nospam@gmail.com> writes:
> >>>>> "C: Everyone's favourite programming language isn't a programming language"
> >>>>>
> >>>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
> >>>> The article doesn't make a whole lot of sense - it's basically just
> >>>> bitching because swift and rust can't do everything that C can.
> >>>
> >>> And you're putting it lightly.
> >>> Of course, first thing, without even reading it, is questioning the
> >>> relevance of such articles written by heavy proponents of
> >>> "alternative" languages. How much more biased can one be?
> >>>
> >>> Digging a bit deeper, there is nothing much to even take from this
> >>> short article. It's pretty shallow.
> >>>
> >>> - C is difficult to parse? C declarations are, for instance, not
> >>> exactly easy, but it's only very moderately difficult. You can have
> >>> fun with this to get an idea: https://cdecl.org/ . I has never made
> >>> it a problem to write a C compiler. There are more of them out there
> >>> than for any other language, I think. OTOH, there is, AFAIK, only one
> >>> implementation of Rust. Which to me is in itself a problem. I'm
> >>> curious to see if it ever even gets to the point of having other
> >>> competing implementations.
> >>
> >> It's probably referring to the typedef issue.
> >>
> >> In the absence of typedefs, type names consist of keywords and
> >> punctuation. A typedef (a feature that was added to the language
> >> after the syntax had been established) creates a type name that's an
> >> identifier. It's impossible to parse something that uses a typedef name
> >> without knowing that it's a typedef name. In effect a typedef adds a
> >> context-sensitive keyword to the grammar. The parser needs to query the
> >> symbol table.
> >
> > Using symbol table is just one of possible solutions. Another
> > one is to note that true ambiguities are really semantic, so
> > parser can return tree faithful to all possible meaning. For
> > example, cast versus function call is semantic problem so
> > parser can return 'call_or_cast' and let semantic phase
> > to decide.
>
> Sure. Then it's down to wanking about what exactly is the parsing part
> in your analyzer and what you want done with it. If you're happy with
> the output of your "parser" to lack fundamental syntactic information
> (yes, I consider determining whether a given token is a type, a
> variable, a qualifier, etc, is a syntactic information), why not.

There is nothing syntactic in types. Language may decide to clearly
separate types from rest of syntax, many do so but C is in the camp
that does not make such distintion.

> That
> can always be analyzed later. That doesn't change squat about the final
> output of your analysis. And since the output of said "parser" would be
> pretty useless by itself, this structure is just an implementation
> choice.

Sometimes it is the only choice. I learned about the technique from
description of C compiler that wanted to offer alternative macro
processor working on level of parse trees. Clearly, what is type
is known only after macro processing, so the the symbol table hack
would not work. I used it in Pascal compiler. Compiler was supposed
to accept several syntax extentions which led to fairly complicated
grammar. In turn this needed more powerful parsing technology (GLR)
with unlimited lookahead. Again, lookahead meant that things could
be parsed before semantic info for corresponding tokens where inserted
in symbol table.

> Possibly making it look more "academically" correct. (Yeah I've
> read endless discussions about what parsing exactly was supposed to be.)

Parsing maps stream of tokens to a tree. Semantics is assigning meaning
to the tree. Of course, if you have single pass compiler, then it
is tempting to tightly couple semantic processing with syntax,
in particular use semantic info for parsing.

--
Waldek Hebisch

Le 27/03/2022 à 00:15, antispam@math.uni.wroc.pl a écrit :
> There is nothing syntactic in types. Language may decide to clearly
> separate types from rest of syntax, many do so but C is in the camp
> that does not make such distintion.

Uh. What are you on about? Yes, knowing what part is a type and what
part is a variable identifier (for instance) in an expression *is* a
syntax matter. Just like knowing what is a verb and what is a subject,
etc, is a syntax matter in natural languages. What camp are you talking
about?

As the earlier, simple and telling example showed:

x y;

You absolutely can't make any syntactic sense of this unless you know
what x and y are.

Without a symbol table, the output of your parser with the above will
just be a list of tokens, so such a parser essentially becomes a
tokenizer only.

On 26/03/2022 17:56, Bart wrote:
> On 26/03/2022 16:11, Manfred wrote:
>> On 3/25/2022 8:16 PM, Bart wrote:
>>> On 25/03/2022 18:17, Manfred wrote:
>> [...]
>>>>
>>>> More in general, it is about indirection. If a language's
>>>> declaration syntax allows for any combination of indirection
>>>> constructs, then things may get convoluted, but it's the type itself
>>>> that is convoluted, not necessarily the syntax's fault.
>>>>
>>>> And, obviously, typedefs make things a /lot/ easier.
>>>
>>> Typedefs should be used when they make sense for the project. If used
>>> to just to mitigate the awfulness of the type syntax, then something
>>> is wrong.
>>>
>>
>> Possibly, but.
>>
>> When writing a program, you are effectively modeling a problem domain.
>> Defining the data types of the information items that the problem
>> revolves around is a key step in such process.
>> In this perspective typedefs, together with user defined types, play a
>> very useful role in software design.
>>
>> If you come to a point where you have to handle some complex type only
>> once in your program, or you end up having a plethora of unrelated
>> cryptic types, then that is a good hint for looking at how good your
>> model is.
>
> This is the kind of thing I'm talking about:
>
>     void (*)(void)
>     void (**)(void)
>     void (***)(void)
>     void *(*)(void)
>     void **(*)(void)
>

I see your first problem. Who on earth needs types like these ones?
The first one, yes, but none of the others.

> I wouldn't even know where to start with using typedefs to express these
> more clearly; perhaps:

Problem number two - /you/ don't know how to use typedefs. Other people
do. Learn to use the features of C, rather than deciding in advance
that you don't like them and refusing to even try to use them.

>
>     typedef void F(void);
>     typedef void* G(void);
>     typedef void** H(void);
>

Problem number three - giving names like F, G, H does not help clarity.

When they have names like "FSort" or "comparison_func" or
"fp_redraw_callback", you've got something that adds to the program.

>     F*
>     F**
>     F***
>     G*
>     H**
>
> You start by first removing all the "*" inside the first set of
> parentheses. Then creating named types for distinct combinations of
> functions that follow. Then reinstating those "*" to each instance of
> that new type.
>
> However, this is rather going around the houses. It's also necessary to
> locate all instances of 'void(*)(void)' in a program, to ensure they all
> use the same typedef, even though they may be used for diverse purposes.
>

Typedef does not introduce a new type. A typedef is entirely compatible
with the underlying type, or other identical typedefs with different
names. (It is not a new type, and not strong typing - you need "struct"
or "union" for that.) So using a typedef doesn't affect compatibility
with existing code, and you don't have to change anything.

> IMV this does not improve matters, since you are now hunting global
> typedefs looking for what F or G might mean. It also doesn't help when
> `void(*)(void)` is used in an imported header than you aren't allowed to
> modify, or which employs its own typedef.

Guillaume <message@bottle.org> writes:
>As the earlier, simple and telling example showed:
>x y;
>You absolutely can't make any syntactic sense of this unless you know
>what x and y are.

"Syntactic sense" is a bit vague, but what else could it be
than a <declaration> wherein "x" is the <declaration-specifiers>
and "y" is the <init-declarator-list>?

(Assuming it is a complete symbol; otherwise, it could be
the /ending/ of a declaration as in "static x y;" or as in
"struct x y;".)

On 3/26/2022 9:43 PM, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> This is the kind of thing I'm talking about:
>>
>> void (*)(void)
>> void (**)(void)
>> void (***)(void)
>> void *(*)(void)
>> void **(*)(void)
>>

Out of context, changing the notation for these types has no meaning.

>> I wouldn't even know where to start with using typedefs to express
>> these more clearly; perhaps:
>>
>> typedef void F(void);
>> typedef void* G(void);
>> typedef void** H(void);
>
> I wouldn't do that. I would (a) use a good name, and (b) not worry
> about the "inner" pointers at all:
>
> // A simple action is a parameterless function that returns nothing:
> typedef void simple_action(void);
>
> simple_action *action_ptr;
> simple_action **indirect_action_ptr;
>
> // and I won't try to invent a name for a pointer to a pointer to a
> // pointer to an action. It's most likely to be result parameter.
>
> // The data are accessed with parameterless functions that return
> // universal pointers:
> typedef void *data_access_function(void);
>
> data_access_function *accessor_ptr;
> data_access_function **indirect_accessor_ptr;
>

(a) a "good name" makes sense only in some context, i.e. when you are
mapping concepts from a problem domain to C types - actions and
accessors in your example.

(b) might well be often good advice. I think it still depends on
context, though. Sometimes the following might make sense too:

typedef simple_action **simple_action_ref;

Manfred <noname@add.invalid> writes:

> On 3/26/2022 9:43 PM, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> This is the kind of thing I'm talking about:
>>>
>>> void (*)(void)
>>> void (**)(void)
>>> void (***)(void)
>>> void *(*)(void)
>>> void **(*)(void)
>>>
>
> Out of context, changing the notation for these types has no meaning.
>
>>> I wouldn't even know where to start with using typedefs to express
>>> these more clearly; perhaps:
>>>
>>> typedef void F(void);
>>> typedef void* G(void);
>>> typedef void** H(void);
>> I wouldn't do that. I would (a) use a good name, and (b) not worry
>> about the "inner" pointers at all:
>> // A simple action is a parameterless function that returns nothing:
>> typedef void simple_action(void);
>> simple_action *action_ptr;
>> simple_action **indirect_action_ptr;
>> // and I won't try to invent a name for a pointer to a pointer to a
>> // pointer to an action. It's most likely to be result parameter.
>> // The data are accessed with parameterless functions that return
>> // universal pointers:
>> typedef void *data_access_function(void);
>> data_access_function *accessor_ptr;
>> data_access_function **indirect_accessor_ptr;
>>
>
> (a) a "good name" makes sense only in some context, i.e. when you are
> mapping concepts from a problem domain to C types - actions and
> accessors in your example.

Agreed. I was forced to choose are a vague "good name" because there
was no context.

> (b) might well be often good advice. I think it still depends on
> context, though. Sometimes the following might make sense too:
>
> typedef simple_action **simple_action_ref;

Yes, that might make sense but I am not a fan of hiding a top-level
pointer in a typedef. The notation (a simple *) needs no contraction
and C's pointers are so low-level and lead to what would be mysterious
semantics for any other type (I'm thinking aliasing) that I tend to
avoid it.

--
Ben.

On 3/27/2022 10:12 PM, Ben Bacarisse wrote:
> Manfred <noname@add.invalid> writes:
>
[...]
>
>> (b) might well be often good advice. I think it still depends on
>> context, though. Sometimes the following might make sense too:
>>
>> typedef simple_action **simple_action_ref;
>
> Yes, that might make sense but I am not a fan of hiding a top-level
> pointer in a typedef. The notation (a simple *) needs no contraction
> and C's pointers are so low-level and lead to what would be mysterious
> semantics for any other type (I'm thinking aliasing) that I tend to
> avoid it.
>

Good point.

On 2022-03-27, David Brown <david.brown@hesbynett.no> wrote:
> On 26/03/2022 17:56, Bart wrote:
>> This is the kind of thing I'm talking about:
>>
>>     void (*)(void)
>>     void (**)(void)
>>     void (***)(void)
>>     void *(*)(void)
>>     void **(*)(void)
>>
>
> I see your first problem. Who on earth needs types like these ones?
> The first one, yes, but none of the others.

The second one could be the pointer to the element of an array,
which is of function pointers. This is reasonably common.

for (void (**iter)(void) = initfun_table; *iter; iter++)
(**iter)();

// (*iter)() would work, but if we have multiple stars going on
// might as well match decl and use.

On 28/03/2022 10:23, Kaz Kylheku wrote:
> On 2022-03-27, David Brown <david.brown@hesbynett.no> wrote:
>> On 26/03/2022 17:56, Bart wrote:
>>> This is the kind of thing I'm talking about:
>>>
>>>     void (*)(void)
>>>     void (**)(void)
>>>     void (***)(void)
>>>     void *(*)(void)
>>>     void **(*)(void)
>>>
>>
>> I see your first problem. Who on earth needs types like these ones?
>> The first one, yes, but none of the others.
>
> The second one could be the pointer to the element of an array,
> which is of function pointers. This is reasonably common.
>
> for (void (**iter)(void) = initfun_table; *iter; iter++)
> (**iter)();
>
> // (*iter)() would work, but if we have multiple stars going on
> // might as well match decl and use.
>

Of course it is always possible to find use-cases for any of these - and
the less complex, the more common. But nothing (other than knee-jerk
prejudice) hinders a programmer from using typedefs here if it makes the
code simpler and clearer (noting that styles and preferences vary
considerably). So I'd have something like:

enum { len_initfun_table = 10 };
typedef void (*FInitFunc)(void);

FInitFunc initfun_table[len_initfun_table];

void init_all(void)
{ for (int i = 0; i < len_initfun_table; i++) {
initfun_table[i]();
}
}

I prefer array syntax for arrays. I prefer named types to complex ones.
Of course other people may prefer to write code in different ways (and
the "best" way to write it can depend on other parts of the code outside
these snippets, such as how the "init" functions are assigned). But I'm
at a loss to understand how someone (i.e., Bart) can complain that C's
type syntax is difficult, and then claim that typedef makes it worse or
is a bad idea.

David Brown <david.brown@hesbynett.no> writes:

> On 28/03/2022 10:23, Kaz Kylheku wrote:
>> On 2022-03-27, David Brown <david.brown@hesbynett.no> wrote:
>>> On 26/03/2022 17:56, Bart wrote:
>>>> This is the kind of thing I'm talking about:
>>>>
>>>>     void (*)(void)
>>>>     void (**)(void)
>>>>     void (***)(void)
>>>>     void *(*)(void)
>>>>     void **(*)(void)
>>>>
>>>
>>> I see your first problem. Who on earth needs types like these ones?
>>> The first one, yes, but none of the others.
>>
>> The second one could be the pointer to the element of an array,
>> which is of function pointers. This is reasonably common.
>>
>> for (void (**iter)(void) = initfun_table; *iter; iter++)
>> (**iter)();
>>
>> // (*iter)() would work, but if we have multiple stars going on
>> // might as well match decl and use.
>>
>
> Of course it is always possible to find use-cases for any of these - and
> the less complex, the more common. But nothing (other than knee-jerk
> prejudice) hinders a programmer from using typedefs here if it makes the
> code simpler and clearer (noting that styles and preferences vary
> considerably). So I'd have something like:
>
> enum { len_initfun_table = 10 };
> typedef void (*FInitFunc)(void);
>
> FInitFunc initfun_table[len_initfun_table];
>
> void init_all(void)
> {
> for (int i = 0; i < len_initfun_table; i++) {
> initfun_table[i]();
> }
> }
>
> I prefer array syntax for arrays. I prefer named types to complex ones.
> Of course other people may prefer to write code in different ways (and
> the "best" way to write it can depend on other parts of the code outside
> these snippets, such as how the "init" functions are assigned).

Another thing the swings the balance to me in favour not hiding that
pointer in the typedef is that the same typedef can be used to declare
the functions that go in the table:

typedef void InitFunc(void);

InitFunc allocateSpace, createObjects, setupTimers;

InitFunc *initfun_table[len_initfun_table] = {
allocateSpace,
createObjects,
setupTimers
};

The array of pointers syntax (T *array[]) is so common, that * hardly
matters.

--
Ben.

On 28/03/2022 16:37, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 28/03/2022 10:23, Kaz Kylheku wrote:
>>> On 2022-03-27, David Brown <david.brown@hesbynett.no> wrote:
>>>> On 26/03/2022 17:56, Bart wrote:
>>>>> This is the kind of thing I'm talking about:
>>>>>
>>>>>     void (*)(void)
>>>>>     void (**)(void)
>>>>>     void (***)(void)
>>>>>     void *(*)(void)
>>>>>     void **(*)(void)
>>>>>
>>>>
>>>> I see your first problem. Who on earth needs types like these ones?
>>>> The first one, yes, but none of the others.
>>>
>>> The second one could be the pointer to the element of an array,
>>> which is of function pointers. This is reasonably common.
>>>
>>> for (void (**iter)(void) = initfun_table; *iter; iter++)
>>> (**iter)();
>>>
>>> // (*iter)() would work, but if we have multiple stars going on
>>> // might as well match decl and use.
>>>
>>
>> Of course it is always possible to find use-cases for any of these - and
>> the less complex, the more common. But nothing (other than knee-jerk
>> prejudice) hinders a programmer from using typedefs here if it makes the
>> code simpler and clearer (noting that styles and preferences vary
>> considerably). So I'd have something like:
>>
>> enum { len_initfun_table = 10 };
>> typedef void (*FInitFunc)(void);
>>
>> FInitFunc initfun_table[len_initfun_table];
>>
>> void init_all(void)
>> {
>> for (int i = 0; i < len_initfun_table; i++) {
>> initfun_table[i]();
>> }
>> }
>>
>> I prefer array syntax for arrays. I prefer named types to complex ones.
>> Of course other people may prefer to write code in different ways (and
>> the "best" way to write it can depend on other parts of the code outside
>> these snippets, such as how the "init" functions are assigned).
>
> Another thing the swings the balance to me in favour not hiding that
> pointer in the typedef is that the same typedef can be used to declare
> the functions that go in the table:
>
> typedef void InitFunc(void);
>
> InitFunc allocateSpace, createObjects, setupTimers;
>
> InitFunc *initfun_table[len_initfun_table] = {
> allocateSpace,
> createObjects,
> setupTimers
> };
>
> The array of pointers syntax (T *array[]) is so common, that * hardly
> matters.
>

I don't often have pointers in typedefs when they are data pointers, but
I usually find it convenient for function pointers. There is no one
universal best choice here - there are many variables. For one thing,
in the kind of C programming I do most, there are a lot fewer pointers
than in "average" C programming. Usually there is no dynamic memory of
any kind, and function pointers are rare.

On 2022-03-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Another thing the swings the balance to me in favour not hiding that
> pointer in the typedef is that the same typedef can be used to declare
> the functions that go in the table:
>
> typedef void InitFunc(void);
>
> InitFunc allocateSpace, createObjects, setupTimers;

> InitFunc *initfun_table[len_initfun_table] = {
> allocateSpace,
> createObjects,
> setupTimers
> };

If the definitions of these functions were in one file, we could
structure it so no forward declarations are required at all.

If the definitions of the functions are elsewhere, we should
be including a header to get them declared.

If those functions are in a module which is aware of the initfun_table
indirection, it's plausible that the header might have this
declaration:

InitFunc allocateSpace, createObjects, setupTimers;

However, the function definitions cannot use this approach.

Still, it can cut down some of the work if an argument is added
to InitFunc. The definitions have to be edited, but at least the
declarations don't have to be touched if they are in the above form.

There could be a compile-time performance benefit. It's almost
certainly way faster for a compiler to process

InitFunc allocateSpace

than to parse a function declaration that gives arguments, and construct
the type object from all that syntax tree material. Here, all it has to
do is look up InitFunc in a symbol table, and bind the allocateSpace
symbol to that type. There is no new type object to construct. I'd be
surprised if it didn't save compile-time memory.

Say we had a million functions to declare :) which all have the same
return type and signature; this would be the way to go, to reduce
the source file size and processing time.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Monday, 28 March 2022 at 17:29:13 UTC+1, David Brown wrote:
> On 28/03/2022 16:37, Ben Bacarisse wrote:
> > David Brown <david...@hesbynett.no> writes:
> >
> >> On 28/03/2022 10:23, Kaz Kylheku wrote:
> >>> On 2022-03-27, David Brown <david...@hesbynett.no> wrote:
> >>>> On 26/03/2022 17:56, Bart wrote:
> >>>>> This is the kind of thing I'm talking about:
> >>>>>
> >>>>> void (*)(void)
> >>>>> void (**)(void)
> >>>>> void (***)(void)
> >>>>> void *(*)(void)
> >>>>> void **(*)(void)
> >>>>>
> >>>>
> >>>> I see your first problem. Who on earth needs types like these ones?
> >>>> The first one, yes, but none of the others.
> >>>
> >>> The second one could be the pointer to the element of an array,
> >>> which is of function pointers. This is reasonably common.
> >>>
> >>> for (void (**iter)(void) = initfun_table; *iter; iter++)
> >>> (**iter)();
> >>>
> >>> // (*iter)() would work, but if we have multiple stars going on
> >>> // might as well match decl and use.
> >>>
> >>
> >> Of course it is always possible to find use-cases for any of these - and
> >> the less complex, the more common. But nothing (other than knee-jerk
> >> prejudice) hinders a programmer from using typedefs here if it makes the
> >> code simpler and clearer (noting that styles and preferences vary
> >> considerably). So I'd have something like:
> >>
> >> enum { len_initfun_table = 10 };
> >> typedef void (*FInitFunc)(void);
> >>
> >> FInitFunc initfun_table[len_initfun_table];
> >>
> >> void init_all(void)
> >> {
> >> for (int i = 0; i < len_initfun_table; i++) {
> >> initfun_table[i]();
> >> }
> >> }
> >>
> >> I prefer array syntax for arrays. I prefer named types to complex ones.
> >> Of course other people may prefer to write code in different ways (and
> >> the "best" way to write it can depend on other parts of the code outside
> >> these snippets, such as how the "init" functions are assigned).
> >
> > Another thing the swings the balance to me in favour not hiding that
> > pointer in the typedef is that the same typedef can be used to declare
> > the functions that go in the table:
> >
> > typedef void InitFunc(void);
> >
> > InitFunc allocateSpace, createObjects, setupTimers;
> >
> > InitFunc *initfun_table[len_initfun_table] = {
> > allocateSpace,
> > createObjects,
> > setupTimers
> > };
> >
> > The array of pointers syntax (T *array[]) is so common, that * hardly
> > matters.
> >
> I don't often have pointers in typedefs when they are data pointers, but
> I usually find it convenient for function pointers. There is no one
> universal best choice here - there are many variables. For one thing,
> in the kind of C programming I do most, there are a lot fewer pointers
> than in "average" C programming. Usually there is no dynamic memory of
> any kind, and function pointers are rare.
>
I just wrore a JSON parser for Crossword Designer. JSON consists of objects
embeeded in objects, so it's natural to have a hierarcy of sub-parsers.
However the sub-parsers are really just two integers over the JSON tokens,
giving start and end points of the object. However I allocated them dynamically
to keep the interface neat. (It would be faster to fill in an automatic structure).

czwartek, 24 marca 2022 o 16:36:11 UTC+1 Richard Harnden napisał(a):
> "C: Everyone's favourite programming language isn't a programming language"
>
> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>

as i said last time i was here c is not a programming language, c is a language form

(this is becouse a language need a fixed 'words' (word that have fixed meaning...in
c as it is you dont have that fixed meaning words (which here are functions) you have
onlu a form to build them up ..if you will fix them the result will be language)

Guillaume <message@bottle.org> wrote:
> Le 27/03/2022 ? 00:15, antispam@math.uni.wroc.pl a ?crit?:
> > There is nothing syntactic in types. Language may decide to clearly
> > separate types from rest of syntax, many do so but C is in the camp
> > that does not make such distintion.
>
> Uh. What are you on about? Yes, knowing what part is a type and what
> part is a variable identifier (for instance) in an expression *is* a
> syntax matter. Just like knowing what is a verb and what is a subject,
> etc, is a syntax matter in natural languages. What camp are you talking
> about?

One language that I use syntactially allows the following two lines:

a : f(2*x + b)
a := f(2*x + b)

First says that variable 'a' has type 'f(2*x + b)'. Second assigns
to 'a' value 'f(2*x + b)'. Semantically, first line is wrong
if 'f(2*x + b)' does not produce a type. The second one is
subject to normal typechecking rules which usually exlude types
(but you may assign types to variables if variable is declared
to hold types). Difference is semanctic, given only 'f(2*x + b)'
you can not decide if it produces a type or not. You need
declaration of 'f' to know (and object code is quite different).

In GNU Pascal

a[b, c, d]

may mean the following:

access element of array 'a'
build array of type 'a' with elements 'b', 'c' and 'd'
build record of type 'a' with field 'b', 'c' and 'd'
build set of type 'a' with elements 'b', 'c' and 'd'

In the first case 'a' must be a variable (normal expression),
in 3 other cases 'a' must be name of type.

> As the earlier, simple and telling example showed:
>
> x y;
>
> You absolutely can't make any syntactic sense of this unless you know
> what x and y are.

You probably meant different example. AFAICS this one can only
be a declaration.

> Without a symbol table, the output of your parser with the above will
> just be a list of tokens, so such a parser essentially becomes a
> tokenizer only.

As I wrote, parser produces trees. With trivial input like 'x y;'
corresponding tree is indeed trivial. For more interesting input
you will get more interesting tree. Of course, exact tree depends
on design of your system. For example, resonable choice for

x y, z;

is to put comma at top of the tree and 'x y' as left subtree, 'z' as
right leaf.

--
Waldek Hebisch

On 2022-03-28, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote:
> Guillaume <message@bottle.org> wrote:
>> Le 27/03/2022 ? 00:15, antispam@math.uni.wroc.pl a ?crit?:
>> > There is nothing syntactic in types. Language may decide to clearly
>> > separate types from rest of syntax, many do so but C is in the camp
>> > that does not make such distintion.
>>
>> Uh. What are you on about? Yes, knowing what part is a type and what
>> part is a variable identifier (for instance) in an expression *is* a
>> syntax matter. Just like knowing what is a verb and what is a subject,
>> etc, is a syntax matter in natural languages. What camp are you talking
>> about?
>
> One language that I use syntactially allows the following two lines:
>
> a : f(2*x + b)
> a := f(2*x + b)

You can do that in the GNU dialect of C:

typeof (f(2*x + b)) a = f(2*x + b);

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

antispam@math.uni.wroc.pl writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Guillaume <message@bottle.org> writes:
>>
>>> Le 24/03/2022 ? 16:45, Scott Lurndal a ?crit?:
>>>
>>>> Richard Harnden <richard.nospam@gmail.com> writes:
>>>>
>>>>> "C: Everyone's favourite programming language isn't a
>>>>> programming language"
>>>>>
>>>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>>>>
>>>> The article doesn't make a whole lot of sense - it's basically
>>>> just bitching because swift and rust can't do everything that C
>>>> can.
>>>
>>> And you're putting it lightly.

>>> Of course, first thing, without even reading it, is questioning
>>> the relevance of such articles written by heavy proponents of
>>> "alternative" languages. How much more biased can one be?
>>>
>>> Digging a bit deeper, there is nothing much to even take from this
>>> short article. It's pretty shallow.
>>>
>>> - C is difficult to parse? C declarations are, for instance, not
>>> exactly easy, but it's only very moderately difficult. You can
>>> have fun with this to get an idea: https://cdecl.org/ . I has
>>> never made it a problem to write a C compiler. There are more of
>>> them out there than for any other language, I think. OTOH, there
>>> is, AFAIK, only one implementation of Rust. Which to me is in
>>> itself a problem. I'm curious to see if it ever even gets to the
>>> point of having other competing implementations.
>>
>> It's probably referring to the typedef issue.
>>
>> In the absence of typedefs, type names consist of keywords and
>> punctuation. A typedef (a feature that was added to the language
>> after the syntax had been established) creates a type name that's
>> an identifier. It's impossible to parse something that uses a
>> typedef name without knowing that it's a typedef name. In effect a
>> typedef adds a context-sensitive keyword to the grammar. The
>> parser needs to query the symbol table.
>
> Using symbol table is just one of possible solutions. Another
> one is to note that true ambiguities are really semantic, so
> parser can return tree faithful to all possible meaning. For
> example, cast versus function call is semantic problem so
> parser can return 'call_or_cast' and let semantic phase
> to decide.

Right. Context-free-style parsing is not limited to LR(k)
parsers.

Guillaume <message@bottle.org> writes:

> Le 27/03/2022 at 00:15, antispam@math.uni.wroc.pl a ecrit:
>
>> There is nothing syntactic in types. Language may decide to clearly
>> separate types from rest of syntax, many do so but C is in the camp
>> that does not make such distintion.
>
> Uh. What are you on about? Yes, knowing what part is a type and what
> part is a variable identifier (for instance) in an expression *is* a
> syntax matter. Just like knowing what is a verb and what is a subject,
> etc, is a syntax matter in natural languages. What camp are you
> talking about?
>
> As the earlier, simple and telling example showed:
>
> x y;
>
> You absolutely can't make any syntactic sense of this unless you know
> what x and y are.
>
> Without a symbol table, the output of your parser with the above will
> just be a list of tokens, so such a parser essentially becomes a
> tokenizer only.

I think you are making assumptions about how the parser will be
structured to reach this conclusion. It is quite possible to
structure a parser that can accommodate any context free language,
including those that have ambiguities, and which produce a much
richer output structure than just a stream of tokens.