Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #141120 > unrolled thread

[PC] Simple AST

Back to article view | Back to comp.lang.c

Contents

  [PC] Simple AST luser droog <luser.droog@gmail.com> - 2019-02-16 14:23 -0800
    Re: [PC] Simple AST BGB <cr88192@hotmail.com> - 2019-02-19 15:14 -0600
      Re: [PC] Simple AST luser droog <luser.droog@gmail.com> - 2019-02-19 19:51 -0800
        Re: [PC] Simple AST Rosario19 <Ros@invalid.invalid> - 2019-02-20 09:28 +0100
          Re: [PC] Simple AST "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-20 09:39 +0100
            Re: [PC] Simple AST Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 08:34 -0800
              Re: [PC] Simple AST "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-06 09:02 -0800
                Re: [PC] Simple AST "I Set My Girlfriend's Pantyhose on Fire" <cdalten@gmail.com> - 2019-03-06 11:14 -0800
                Re: [PC] Simple AST Ian Collins <ian-news@hotmail.com> - 2019-03-07 14:11 +1300
                  Re: [PC] Simple AST "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-06 17:48 -0800
                    Re: [PC] Simple AST Ian Collins <ian-news@hotmail.com> - 2019-03-07 15:21 +1300
                      Re: [PC] Simple AST luser droog <luser.droog@gmail.com> - 2019-03-06 18:28 -0800
                        Re: [PC] Simple AST luser droog <luser.droog@gmail.com> - 2019-03-06 18:37 -0800
                      Re: [PC] Simple AST "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-06 18:47 -0800
                        Re: [PC] Simple AST luser droog <luser.droog@gmail.com> - 2019-03-06 18:53 -0800
              Re: [PC] Simple AST "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-03-06 18:38 +0100
                Re: [PC] Simple AST Keith Thompson <kst-u@mib.org> - 2019-03-06 09:53 -0800
                  Re: [PC] Simple AST "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-06 09:59 -0800
                  Re: [PC] Simple AST "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-03-06 19:49 +0100
                    Re: [PC] Simple AST Bart <bc@freeuk.com> - 2019-03-06 19:23 +0000
                      Re: [PC] Simple AST David Brown <david.brown@hesbynett.no> - 2019-03-06 23:29 +0100
                      Re: [PC] Simple AST BGB <cr88192@hotmail.com> - 2019-03-06 21:54 -0600
                        Re: [PC] Simple AST James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-08 18:52 -0500
                          Re: [PC] Simple AST "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-03-09 01:56 +0100
                            Re: [PC] Simple AST Keith Thompson <kst-u@mib.org> - 2019-03-08 18:22 -0800
                              Re: [PC] Simple AST David Brown <david.brown@hesbynett.no> - 2019-03-09 14:02 +0100
                                Re: [PC] Simple AST Keith Thompson <kst-u@mib.org> - 2019-03-09 12:20 -0800
                                  Re: [PC] Simple AST David Brown <david.brown@hesbynett.no> - 2019-03-10 00:04 +0100
                            Re: [PC] Simple AST Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-09 02:28 +0000
                          Re: [PC] Simple AST BGB <cr88192@gmail.com> - 2019-03-08 23:06 -0600
                      Re: [PC] Simple AST Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-12 23:06 -0700
                        Re: [PC] Simple AST Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-14 06:48 +0000
                          Re: [PC] Simple AST James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-14 07:14 -0400
                            Re: [PC] Simple AST Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-14 14:58 +0000
                              Re: [PC] Simple AST James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-14 10:13 -0700
                              Re: [PC] Simple AST Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-18 08:34 -0700
                            Re: [PC] Simple AST Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-23 10:57 -0700
                              Re: [PC] Simple AST James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 11:42 -0700
                          Re: [PC] Simple AST Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-18 07:18 -0700
                        Re: [PC] Simple AST Bart <bc@freeuk.com> - 2019-03-14 15:34 +0000
                          Divorcing rabbits with Tim R (Was: [PC] Simple AST) gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-14 16:52 +0000
                    Re: [PC] Simple AST Keith Thompson <kst-u@mib.org> - 2019-03-06 22:12 -0800
                      Re: [PC] Simple AST David Brown <david.brown@hesbynett.no> - 2019-03-07 08:54 +0100
                      Re: [PC] Simple AST "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-07 03:20 -0800
                    Re: [PC] Simple AST Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-12 23:08 -0700
                  Re: [PC] Simple AST luser droog <luser.droog@gmail.com> - 2019-03-06 14:08 -0800
                    Re: [PC] Simple AST Keith Thompson <kst-u@mib.org> - 2019-03-06 22:13 -0800
                Re: [PC] Simple AST Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-06 19:38 +0000
                  Re: [PC] Simple AST "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-06 11:54 -0800
                    Re: [PC] Simple AST Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-03-07 14:43 +0300
                      Re: [PC] Simple AST "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-07 03:58 -0800
                        Re: [PC] Simple AST David Brown <david.brown@hesbynett.no> - 2019-03-07 13:07 +0100
          Re: [PC] Simple AST Rosario19 <Ros@invalid.invalid> - 2019-02-20 10:35 +0100
      Re: [PC] Simple AST Bart <bc@freeuk.com> - 2019-02-20 14:26 +0000
        Re: [PC] Simple AST BGB <cr88192@hotmail.com> - 2019-02-20 14:32 -0600
          Re: [PC] Simple AST "I Set My Girlfriend's Pantyhose on Fire" <cdalten@gmail.com> - 2019-02-21 13:38 -0800
          Re: [PC] Simple AST Thiago Adams <thiago.adams@gmail.com> - 2019-02-22 04:03 -0800

Page 3 of 3 — ← Prev page 1 2 [3]

#141962 — Divorcing rabbits with Tim R (Was: [PC] Simple AST)

In article <6wuiE.372692$Xct1.12406@fx12.am4>, Bart  <bc@freeuk.com> wrote:
>On 13/03/2019 06:06, Tim Rentsch wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> One or two here claim to know the precedences by heart, notably
>>> Tim Rentsch.
>> 
>> I have never made that claim.  I ask that you not make statements
>> that purport to represent my views.  Your batting average trying
>> to do that so far is a lot closer to zero than it is to 1000.
>
>My apologies, I retract that statement.
>
>Apparently, Tim Rentsch doesn't know all C's operator precedences by 
>heart, making him just like the rest of us.

That doesn't follow at all.  As James K points out - in one of the best
written CLC posts in a very long time - you cannot make the usual (and
which would seem entirely sensible and reasonable) inferences from a Tim R
post.

Specifically, here, Tim states that he never made a certain claim.  That
does not mean that the thing being claimed is not true.  It simply means
that Tim maintains that he never claimed it to be true.

By way of analogy, I have never claimed (in comp.lang.c) that I am God's
gift to women.  That does not, of course, mean that it is not true (*); it
simply means that I have never claimed it here.

(*) Nor, of course, does it mean that it is.

-- 
Alice was something of a handful to her father, Theodore Roosevelt.  He was once
asked by a visiting dignitary about parenting his spitfire of a daughter and he
replied, "I can be President of the United States, or I can control Alice. I
cannot possibly do both."

[toc] | [prev] | [next] | [standalone]

#141764

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>> [...]
>>> We are not looking at landscape and scanning for predators here.
>>>
>>> We're looking at code that needs to give the human reader a conceptual
>>> structure isomorphe to what the "semantics" implemented by the language
>>> implementation produces.
>>>
>>>      a = b+c * d; // spaces fail all the time.
>>
>> So don't do that.  How often do you actually see code like that?
>>
>>     a = b + c*d;
>>
>> It would be nice if compilers warned about misleading spaces in
>> expressions (perhaps some do).
>
> Often enough.  But the worst part, is that I never encoutered any C
> programmer able to recite from memory the list of all C opertors sorted
> by their exact priority level.  Therefore not using systematically
> parentheses in any C expressions is a sure way to introduce slimy bugs.
>
> (I'm not able to do it for C either, when I programmed in pascal, I
> could do it for pascal operators).

If you want to argue that it's good to use parentheses to make
precedence explicit when using operators whose precedence a reader might
not reasonably be expected to know, I agree.  We might differ on which
operators those are, but for example I'd certainly parenthesize
    a | (b ^ c)
even though it's equivalent to
    a | b ^ c

If I saw
    a | b^c
I'd assume that the author *thinks* that ^ binds more tightly than | --
but I'd probably check that assumption, and consider adding parentheses
if I were in a position to do so.  If I saw
    a|b ^ c
I'd make a similar assumption and find that the author either was
mistaken or was being deliberately misleading.

But we were talking about
    a = b+c * d;
which is clearly misleading to anyone who knows the relative
precedence of + and * (and I'm confortable assuming that any
reasonably skilled C programmer does know that).  If I actually saw
that, I wouldn't assume that either changing the spacing or adding
the parentheses would fix the problem.  I'd have to consider that
there might be other mistakes.

But to get back to the point, I find this:
    a = b + c*d;
or even this:
    a = b + c * d;
more legible than what you suggested upthread:
    a=(b+(c*d));
I usually put spaces around binary operators, but I might omit them
to emphasize known precedence.

The possibility of adding spaces *and getting them wrong* is,
I believe, something of a straw man argument.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#141766

On 07/03/2019 07:12, Keith Thompson wrote:
> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>>> [...]
>>>> We are not looking at landscape and scanning for predators here.
>>>>
>>>> We're looking at code that needs to give the human reader a conceptual
>>>> structure isomorphe to what the "semantics" implemented by the language
>>>> implementation produces.
>>>>
>>>>      a = b+c * d; // spaces fail all the time.
>>>
>>> So don't do that.  How often do you actually see code like that?
>>>
>>>     a = b + c*d;
>>>
>>> It would be nice if compilers warned about misleading spaces in
>>> expressions (perhaps some do).
>>
>> Often enough.  But the worst part, is that I never encoutered any C
>> programmer able to recite from memory the list of all C opertors sorted
>> by their exact priority level.  Therefore not using systematically
>> parentheses in any C expressions is a sure way to introduce slimy bugs.
>>
>> (I'm not able to do it for C either, when I programmed in pascal, I
>> could do it for pascal operators).
> 
> If you want to argue that it's good to use parentheses to make
> precedence explicit when using operators whose precedence a reader might
> not reasonably be expected to know, I agree.  We might differ on which
> operators those are, but for example I'd certainly parenthesize
>     a | (b ^ c)
> even though it's equivalent to
>     a | b ^ c
> 
> If I saw
>     a | b^c
> I'd assume that the author *thinks* that ^ binds more tightly than | --
> but I'd probably check that assumption, and consider adding parentheses
> if I were in a position to do so.  If I saw
>     a|b ^ c
> I'd make a similar assumption and find that the author either was
> mistaken or was being deliberately misleading.
> 
> But we were talking about
>     a = b+c * d;
> which is clearly misleading to anyone who knows the relative
> precedence of + and * (and I'm confortable assuming that any
> reasonably skilled C programmer does know that).  If I actually saw
> that, I wouldn't assume that either changing the spacing or adding
> the parentheses would fix the problem.  I'd have to consider that
> there might be other mistakes.
> 
> But to get back to the point, I find this:
>     a = b + c*d;
> or even this:
>     a = b + c * d;
> more legible than what you suggested upthread:
>     a=(b+(c*d));
> I usually put spaces around binary operators, but I might omit them
> to emphasize known precedence.
> 
> The possibility of adding spaces *and getting them wrong* is,
> I believe, something of a straw man argument.
> 

I am in full agreement with you here.  Too many parenthesis can make an
expression hard to read - there are limits to how many levels you can
take in at a glance.  (Before Malcolm jumps in with his "rule of three",
it is not a hard limit - it varies by person and by the construct in
question.)

And even if you /do/ have extra parentheses, then spacing is vital.
This is hard to read (IMHO) :

	a=(b+(c*d));

This is much easier:

	a = (b + (c * d));


I think some of the precedence rules are so obvious and well-established
(from primary school upwards) that parentheses are not needed - I would
expect everyone to know the relative precedences of =, + and *.

And if an expression is getting too complicated and needs lots of
parentheses to make it clear, break it up into parts.

[toc] | [prev] | [next] | [standalone]

#141773

On Thursday, March 7, 2019 at 1:12:43 AM UTC-5, Keith Thompson wrote:
> But to get back to the point, I find this:
>     a = b + c*d;
> or even this:
>     a = b + c * d;
> more legible than what you suggested upthread:
>     a=(b+(c*d));

Most developers, if they chose to use parentheses here, would
write:

    a = b + (c * d);

Or some othet form using only one set of parentheses.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#141918

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> [...] I never encoutered any C programmer able to recite from
> memory the list of all C opertors sorted by their exact priority
> level.

Maybe you have and just don't know it.

[toc] | [prev] | [next] | [standalone]

#141753

On Wednesday, March 6, 2019 at 11:53:20 AM UTC-6, Keith Thompson wrote:
> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> [...]
> > We are not looking at landscape and scanning for predators here.
> >
> > We're looking at code that needs to give the human reader a conceptual
> > structure isomorphe to what the "semantics" implemented by the language
> > implementation produces.
> >
> >      a = b+c * d; // spaces fail all the time.
> 
> So don't do that.  How often do you actually see code like that?
> 
>     a = b + c*d;
> 
> It would be nice if compilers warned about misleading spaces in
> expressions (perhaps some do).
> 

Coincidentally, the parsers I'm working on which were the original
topic of this thread are intended to be used in a formatting tool
which will produce this very kind of warning.

I've been somewhat delayed by having discovered that combinator
parsers really need lazy evaluation to work well. So, laziness
is now the top of my stack.

[toc] | [prev] | [next] | [standalone]

#141765

luser droog <luser.droog@gmail.com> writes:
[...]
> I've been somewhat delayed by having discovered that combinator
> parsers really need lazy evaluation to work well. So, laziness
> is now the top of my stack.

And it's hard to get past laziness, isn't it?

8-)}

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#141749

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
<cut>
>>> Don't use spaces other than where required to separate tokens, and
>>> for indentation (spaces pay more than tabs).  But don't use them
>>> in expression:  they're misleading!
>>>
>>>     a = b+c * d; // spaces fail all the time.
>>>
>>> Instead, use parentheses:
>>>
>>>     a=(b+(c*d));
>>
>> This advice has it exactly backwards.  For visual separation,
>> spaces are better than parentheses because they are a better
>> match to human perceptual hardware.  For semantic grouping,
>> variable spacing is better than parentheses, both because it is
>> more readily perceived, and because it offers a redundancy that
>> can be used as a check on what the author intended.  The
>> "misleadingness" in the example (and other similar examples) can
>> be programmatically detected, and provides a tipoff that there is
>> something wrong - either a misunderstanding on the part of the
>> author, or a mistake in the algorithm, or perhaps both.  Using
>> spacing to (redundantly) show grouping adds useful information.
>> Taking out all spaces and putting in redundant parentheses takes
>> away information that is often useful - a losing proposition all
>> the way around.
>
> We are not looking at landscape and scanning for predators here.
>
> We're looking at code that needs to give the human reader a conceptual
> structure isomorphe to what the "semantics" implemented by the language
> implementation produces.
>
>      a = b+c * d; // spaces fail all the time.

Surely that's a win?  If the code is using spaces as Tim suggests it
flags up a bug, at least it leaps out at me: "programmer is either
confused about layout or confused about operators -- double check the
intent and correct one or the other".

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#141750

On Wednesday, March 6, 2019 at 2:38:55 PM UTC-5, Ben Bacarisse wrote:
> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> > We are not looking at landscape and scanning for predators here.
> >
> > We're looking at code that needs to give the human reader a conceptual
> > structure isomorphe to what the "semantics" implemented by the language
> > implementation produces.
> >
> >      a = b+c * d; // spaces fail all the time.
> 
> Surely that's a win?  If the code is using spaces as Tim suggests it
> flags up a bug, at least it leaps out at me: "programmer is either
> confused about layout or confused about operators -- double check the
> intent and correct one or the other".

So you're prepared to cast your eyes on all of the source code
in some large project to catch some odd spacing at some place?

This is a coding error.  The author may have coded it as it is
intended, but the spacing does not convey that visually.

The compiler should compile it as-is using the syntax required,
and the coding style should be unrelated to the actual syntax.
If a company seeks to enforce a standard (many do), there should
be a tool for examining the source code.

Linux has a tool like this, for example.  And the Netbeans Java-
based IDE has a feature which will auto-format code easily to
many kinds of standards if needed.  Eclipse probably has it too.

The right tool for the right job.  Our eyes are not a good source
of anything to catch "bugs" like that in large code bases.  We
need automation.  And that automation component should be completely
divorced from the compiler.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#141774

Rick C. Hodgin:

>So you're prepared to cast your eyes on all of the source
>code in some large project to catch some odd spacing at
>some place?
>
>This is a coding error.  The author may have coded it as it
>is intended, but the spacing does not convey that visually.
>
>The compiler should compile it as-is using the syntax
>required, and the coding style should be unrelated to the
>actual syntax.  If a company seeks to enforce a standard
>(many do), there should be a tool for examining the source
>code.
>
>Linux has a tool like this, for example.  And the Netbeans
>Java- based IDE has a feature which will auto-format code
>easily to many kinds of standards if needed.  Eclipse
>probably has it too.
>
>The right tool for the right job.  Our eyes are not a good
>source of anything to catch "bugs" like that in large code
>bases.  We need automation.  And that automation component
>should be completely divorced from the compiler.

Manual formatting expresses the programmer's intent, whereas
a tool formats code according to mechanical rules.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#141775

On Thursday, March 7, 2019 at 6:43:09 AM UTC-5, Anton Shepelev wrote:
> Rick C. Hodgin:
> 
> >So you're prepared to cast your eyes on all of the source
> >code in some large project to catch some odd spacing at
> >some place?
> >
> >This is a coding error.  The author may have coded it as it
> >is intended, but the spacing does not convey that visually.
> >
> >The compiler should compile it as-is using the syntax
> >required, and the coding style should be unrelated to the
> >actual syntax.  If a company seeks to enforce a standard
> >(many do), there should be a tool for examining the source
> >code.
> >
> >Linux has a tool like this, for example.  And the Netbeans
> >Java- based IDE has a feature which will auto-format code
> >easily to many kinds of standards if needed.  Eclipse
> >probably has it too.
> >
> >The right tool for the right job.  Our eyes are not a good
> >source of anything to catch "bugs" like that in large code
> >bases.  We need automation.  And that automation component
> >should be completely divorced from the compiler.
> 
> Manual formatting expresses the programmer's intent, whereas
> a tool formats code according to mechanical rules.

That is my point exactly.  The compiler should compile based on
syntax, not spacing.

And tools should be used to enforce spacing requirements.  Linux
uses one of these tools for their source code submissions.  It
analyzes and reports code styles which deviate from their standard
prior to submission.  Greg Kroah Hartmann has a video on it:

    https://www.youtube.com/watch?v=LLBrBBImJt4

If a particular spacing is required, use a tool.  Don't expect
the compiler to warn you about improper spacing.  And use whatever
spacing works for you.  I use very unusual spacing because of
my dyslexia.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#141776

On 07/03/2019 12:58, Rick C. Hodgin wrote:
> On Thursday, March 7, 2019 at 6:43:09 AM UTC-5, Anton Shepelev wrote:
>> Rick C. Hodgin:
>>
>>> So you're prepared to cast your eyes on all of the source
>>> code in some large project to catch some odd spacing at
>>> some place?
>>>
>>> This is a coding error.  The author may have coded it as it
>>> is intended, but the spacing does not convey that visually.
>>>
>>> The compiler should compile it as-is using the syntax
>>> required, and the coding style should be unrelated to the
>>> actual syntax.  If a company seeks to enforce a standard
>>> (many do), there should be a tool for examining the source
>>> code.
>>>
>>> Linux has a tool like this, for example.  And the Netbeans
>>> Java- based IDE has a feature which will auto-format code
>>> easily to many kinds of standards if needed.  Eclipse
>>> probably has it too.
>>>
>>> The right tool for the right job.  Our eyes are not a good
>>> source of anything to catch "bugs" like that in large code
>>> bases.  We need automation.  And that automation component
>>> should be completely divorced from the compiler.
>>
>> Manual formatting expresses the programmer's intent, whereas
>> a tool formats code according to mechanical rules.
> 
> That is my point exactly.  The compiler should compile based on
> syntax, not spacing.
> 
> And tools should be used to enforce spacing requirements.  Linux
> uses one of these tools for their source code submissions.  It
> analyzes and reports code styles which deviate from their standard
> prior to submission.  Greg Kroah Hartmann has a video on it:
> 
>     https://www.youtube.com/watch?v=LLBrBBImJt4
> 
> If a particular spacing is required, use a tool.  Don't expect
> the compiler to warn you about improper spacing.  And use whatever
> spacing works for you.  I use very unusual spacing because of
> my dyslexia.
> 

The compiler /is/ a tool.  I don't know of any compilers that enforce or
warn about particular spacing requirements within expressions (gcc can
warn about misleading indentation, which is a bigger problem and also
one that is easier to check mechanically).  But I don't see any
particular reason why an independent tool could check spacing while a
compiler could not.  It is merely a matter of where the particular tool
developers want to spend their time and effort.

[toc] | [prev] | [next] | [standalone]

#141157

On Wed, 20 Feb 2019 09:28:20 +0100, Rosario19 wrote:

>On Tue, 19 Feb 2019 19:51:49 -0800 (PST), luser droog wrote:
>>Very interesting breakdown. Thanks for this. I suppose you're right
>>that my tree is not very abstract. I think that's okay for my 
>>immediate purposes. I plan to make a formatting tool before making
>>a compiler. And for a formatting tool, what I need is a tree that
>>faithfully represents the text that was typed while also having 
>>all the needed structural information to make formatting decisions.
>>
>>I'm currently working on where to add "whitespace eaters" into my
>>grammar 
>
>>and how to attach that whitespace to the token so it can
>>be considered during tree traversal. 
>
>one program language without white spaces has readability == 0
>
>the true because program now are more readable it is not because they
>invent loop instructions (for break ecc) and structural instructions
>but main, because **indentation** and visual rememeber of loop
>and using indentation and spaces for show rendundance in the code...

than was one good idea build for loop 

for(Initialization; WhenEndTheLoop; variables incrementation or
variations)

so one know where to see in the loop if search "WhenEndTheLoop" or 
where variables are incremented or changed

[toc] | [prev] | [next] | [standalone]

#141161

On 19/02/2019 21:14, BGB wrote:

> An AST would reflect the structural and functional elements of the tree, 
> but would not retain the tokens which go into creating them (nor 
> necessarily strictly follow the structure of the source program).
> 
> 
> But, yeah, there are several conventional ways to construct an AST:
>    tag union (seems to be reasonably popular);
>    struct-casting (this is a nasty style IMO);
>    cons cells (source-language transformed into a Lisp-like form);
>    key/value tagged objects (not sure of a better term).
>      I am not currently aware of anyone else using these.
> 
> 
> Tag union and struct casting appear to be the most popular strategies in 
> the compilers I have looked at.
> 
> I have used cons cells (and XML DOM) in the past, but currently lean 
> against these (both have some notable drawbacks).
> 
> My current general preference here is key/value objects.
> 
> 
> == Tag Union ==

> A tag-union style nodetype:
>    typedef struct ast_node_s ast_node;
>    struct ast_node_s {
>      ast_node *next;    //next node in linked-list tree
>      short itag;        //node type tag
>      short sfn;        //source filename index
>      int sln;        //source line number
>      union {
...

> An advantage of this is that it can be expressed fairly 
> straightforwardly in C, and is reasonably efficient to access. Memory 
> cost is intermediate (the nodes have the cost of the worst-case node type).
> 
> 
> One big drawback is that printing/parsing these types of nodes will 
> typically take nearly as much code as the parser itself. Another 
> drawback is that they tend to end up with enough "secondary costs" to 
> eat what advantages they might otherwise have compared with a key/value 
> approach in this use-case.

I guess this is closest to what I use, but I haven't noticed any 
particular problems.

My compilers are little more demanding as they must compile all sources 
of a program at the same time, so puts more pressure on memory.

But the biggest program I have uses about 100,000 nodes (of 64 bytes 
each), totalling 13MB. In all, total memory usage is 30MB, less than 
0.5% of the 8MB in my machine, to produce a 0.5MB executable.

Speed isn't bad either, in that parsing (converting from raw source to 
first stage of AST) can be done at up to 2M lines per second (on a 
machine somewhat slower than yours).

Printing the AST /is/ fiddly, but that would be an optional part of the 
process. It's anyway only some 200 lines, 3% of parser/tokeniser.

What it comes down to is that the source code expresses a tree-like 
structure and the data structure to represent it is also tree-like. 
Although subsequent processing needs to flatten it out.

(Unless you have a one-pass compiler which can eliminate that 
intermediate stage.)

[toc] | [prev] | [next] | [standalone]

#141163

On 2/20/2019 8:26 AM, Bart wrote:
> On 19/02/2019 21:14, BGB wrote:
> 
>> An AST would reflect the structural and functional elements of the 
>> tree, but would not retain the tokens which go into creating them (nor 
>> necessarily strictly follow the structure of the source program).
>>
>>
>> But, yeah, there are several conventional ways to construct an AST:
>>    tag union (seems to be reasonably popular);
>>    struct-casting (this is a nasty style IMO);
>>    cons cells (source-language transformed into a Lisp-like form);
>>    key/value tagged objects (not sure of a better term).
>>      I am not currently aware of anyone else using these.
>>
>>
>> Tag union and struct casting appear to be the most popular strategies 
>> in the compilers I have looked at.
>>
>> I have used cons cells (and XML DOM) in the past, but currently lean 
>> against these (both have some notable drawbacks).
>>
>> My current general preference here is key/value objects.
>>
>>
>> == Tag Union ==
> 
>> A tag-union style nodetype:
>>    typedef struct ast_node_s ast_node;
>>    struct ast_node_s {
>>      ast_node *next;    //next node in linked-list tree
>>      short itag;        //node type tag
>>      short sfn;        //source filename index
>>      int sln;        //source line number
>>      union {
> ...
> 
>> An advantage of this is that it can be expressed fairly 
>> straightforwardly in C, and is reasonably efficient to access. Memory 
>> cost is intermediate (the nodes have the cost of the worst-case node 
>> type).
>>
>>
>> One big drawback is that printing/parsing these types of nodes will 
>> typically take nearly as much code as the parser itself. Another 
>> drawback is that they tend to end up with enough "secondary costs" to 
>> eat what advantages they might otherwise have compared with a 
>> key/value approach in this use-case.
> 
> I guess this is closest to what I use, but I haven't noticed any 
> particular problems.
> 
> My compilers are little more demanding as they must compile all sources 
> of a program at the same time, so puts more pressure on memory.
> 

Mine also compiles all sources for a program at once.
My preferred strategy also tries to limit memory use.

It isn't optimally efficient for small nodes, but there isn't really a 
great solution here (if only one type of node is used in-memory).


Realizes that my key/value objects are essentially small associative 
arrays, though (for whatever reason), Wikipedia doesn't seem to mention 
the possibility of implementing them with two parallel arrays and 
binary-search (nor the possibility that one might use small-order 
B-Trees rather than AVL or R-B trees or similar).


One thing I had also failed to mention was internal linking via external 
linking or arrays for node lists. BGBCC uses internally-linked nodes, 
which has the drawback that expression-rewriting typically needs to make 
copies of the sub-expressions (wastes memory due to duplicating nodes 
during compilation).

External linking (which was used in my BS2VM compiler) can avoid needing 
to clone these node lists (saving some memory), but now one needs a 
special node type which merely functions as an ordered array of other 
nodes (rather than doing a linked-list walk).

One other thing I omitted from the examples I gave was that in my case, 
the nodes also contain reference-counts.

So many tradeoffs...


> But the biggest program I have uses about 100,000 nodes (of 64 bytes 
> each), totalling 13MB. In all, total memory usage is 30MB, less than 
> 0.5% of the 8MB in my machine, to produce a 0.5MB executable.
> 
> Speed isn't bad either, in that parsing (converting from raw source to 
> first stage of AST) can be done at up to 2M lines per second (on a 
> machine somewhat slower than yours).
> 

In my case, the majority of time here seems to go into the tokenizer and 
3AC/SSA backend (mostly things like register allocation), rather than 
into AST related mechanics.

Parse is averaging ~ 5 ms per translation unit (after preprocessing).
Doing some rough estimates, it also works out to around 2M lines per second.


The AST->RIL stage (converts AST to an stack-based bytecode) is ~11ms 
per TU. This involves both AST walking logic, as well as things like 
constant folding and some expression-level transforms.


For Doom, backend (codegen) is ~870ms, which works out larger than the 
entire frontend process (frontend is ~700ms in total for all TUs).


Memory use is ~ 170MB for Doom, and ~210 for Quake.

For Doom, it works out to around 105 kLOC if both Doom and the C library 
are counted, or 57 kLOC if it is Doom by itself.

Doom currently produces a binary that is 289kB (Quake is currently 310kB).

Roughly, this works out to around 3 to 5 bytes per LOC on average.
Though, some amount of this is due to space-saving trickery.


> Printing the AST /is/ fiddly, but that would be an optional part of the 
> process. It's anyway only some 200 lines, 3% of parser/tokeniser.
> 

The issue I see with it, is that generally to print this style of tree, 
it is necessary to have logic to print every type of node which exists 
(can be relatively large with C-family languages).

Reloading such a tree would face a similar issue.

This can be sidestepped with a tree structure which doesn't require 
separate handling for every type of AST node which exists (because all 
the nodes are structurally-equivalent).


If the serialization logic doesn't really need to care which specific 
AST node types it is dealing with, it can be made simpler.


> What it comes down to is that the source code expresses a tree-like 
> structure and the data structure to represent it is also tree-like. 
> Although subsequent processing needs to flatten it out.
> 
> (Unless you have a one-pass compiler which can eliminate that 
> intermediate stage.)
> 

Well, partly, Issue was AST vs CST, where one represents a more abstract 
structure, and the other is a tree built from tokens.

It makes sense to avoid confusing an AST with a CST, as they differ in 
terms of both structure and function.

[toc] | [prev] | [next] | [standalone]

#141167

The last AST that I worked on was hard in the respect that the traversal required a form of mutal recursion. And any errors in the tree could only be detected with a backtracking algorithm.

[toc] | [prev] | [next] | [standalone]

#141168

On Wednesday, February 20, 2019 at 5:32:41 PM UTC-3, BGB wrote:
...
> Well, partly, Issue was AST vs CST, where one represents a more abstract 
> structure, and the other is a tree built from tokens.

I had to make a decision in my project (cprime) and I face this 
dilemma while representing declarations.

int *a, b;

In a point of view about what is being declared, an AST could have
two entries.

int *a;
int b;

I choose to have the tokens CST and I can inquire the root node
about specific questions. 

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web