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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#141754

On 06/03/2019 20:23, Bart wrote:
> On 06/03/2019 18:49, Pascal J. Bourguignon wrote:
>> 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).

I don't know of any.  Recent gcc can warn about misleading indentation, 
which is nice, but not about spacing in expressions.

>>
>> 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.
> 
> One or two here claim to know the precedences by heart, notably Tim 
> Rentsch.
> 
> It gets dangerous when they expect everyone else to know them, so their 
> own code is largely devoid of parentheses.
> 
>> (I'm not able to do it for C either, when I programmed in pascal, I
>> could do it for pascal operators).
> 
> 
> C is a basket-case because there are so many precedences (10 just for 
> binary operators, which is a little crazy (have == and <= different, and 
> which one is higher and which lower?), and many are unintuitive.
> 

Many of the C operator precedences are quite obvious and sensible.  The 
others are reasonable enough if you think about hard enough - but 
personally I find they can be difficult to grasp immediately.  I'll 
write "(a < 1) && (b > 1)", even though the parentheses are not needed 
here.  But I write "a = b + c * d" without parentheses (and with that 
spacing).

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

#141824

On 3/6/2019 1:23 PM, Bart wrote:
> On 06/03/2019 18:49, Pascal J. Bourguignon wrote:
>> 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.
> 
> One or two here claim to know the precedences by heart, notably Tim 
> Rentsch.
> 
> It gets dangerous when they expect everyone else to know them, so their 
> own code is largely devoid of parentheses.
> 

I tend to prefer a having a few extra parenthesis, using them to keep 
the intended behavior unambiguous.

I have also tended to write things like "return(0);", even if 
technically the parens are superfluous in this case.


I frequently also like using whitespace to keep things lined up, which 
was one thing that really annoyed me when trying to use Visual Studio 
for code editing:
It would automatically reformat things and mess with my attempts to use 
whitespace for visual alignment (with no obvious way at the time to turn 
this off).

Decided to leave out a bunch of stuff, mostly about my annoyances with 
trying to use VS as a code editor, it seemingly trying to be too clever 
and, at least for me, ruining it for the main thing it was designed to 
do (well, that and input lag; if the text editor is obviously lagging 
behind whatever keys I hit on the keyboard, I am not happy; ...).


Maybe my style is non-standard, but I prefer to format it the way I find 
it preferable (and have generally ended up preferring the use of 
text-editors rather than IDE's; though VS still works pretty well as a 
debugger).


>> (I'm not able to do it for C either, when I programmed in pascal, I
>> could do it for pascal operators).
> 
> 
> C is a basket-case because there are so many precedences (10 just for 
> binary operators, which is a little crazy (have == and <= different, and 
> which one is higher and which lower?), and many are unintuitive.
> 

It is a bit arbitrary, particularly at the outer levels. In a few of my 
languages, I had collapsed them down somewhat and made things 
left-associative.

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

#141827

On 3/6/19 22:54, BGB wrote:
> On 3/6/2019 1:23 PM, Bart wrote:
...
>> One or two here claim to know the precedences by heart, notably Tim 
>> Rentsch.

I know most of them, including in particular the ones that I use most
frequently. Bart seems to imply that he's not sure he believes that
claim. He shouldn't - as a professional programmer I've had far more
than enough practical experience with them to memorize those precedence
levels, despite having never gone out of my way to memorize them.

>> It gets dangerous when they expect everyone else to know them, so their 
>> own code is largely devoid of parentheses.

It's not so much that I expect everyone else to know them, but rather
that I have a hard time anticipating which expressions might be less
clear to the average C programmer than they are to me.

> I tend to prefer a having a few extra parenthesis, using them to keep 
> the intended behavior unambiguous.

If they're needed to make the behavior unambiguous, they're not "extra".
"extra" parenthesis are the ones used to help people who don't have the
precedences memorized to know what the behavior is even though those
parentheses are not needed to cause that behavior to happen.

> I have also tended to write things like "return(0);", even if 
> technically the parens are superfluous in this case.

That makes a return statement look like a function-call statement.
Because of the popularity of that style, I've known people who thought
that it was a function.

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

#141828

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

>> I have also tended to write things like "return(0);", even if 
>> technically the parens are superfluous in this case.
>
> That makes a return statement look like a function-call statement.
> Because of the popularity of that style, I've known people who thought
> that it was a function.

This shows that it is an advantage to adopt an homogenous syntax.
Note that we already have:

 if(…)
 while(…)
 do(…)
 for(…)

 your_random_function(…)

so why not:

 return(…)


Now, in for(…;…;…)… we already have 3 expressions in the parentheses, so
the question is why not also put inside the parentheses the following
expression?  in if(…)… we already have one expression in the
parentheses, so the question is why not also put inside the parentheses
the following expression?  and so on.

  (if test then else)
  (while test body)
  (do body)
  (for (init test increment) body)
  (return expression)
  (your-random-function arguments)

and you get lisp :-)  yay!



-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

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

#141829

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>>> I have also tended to write things like "return(0);", even if 
>>> technically the parens are superfluous in this case.
>>
>> That makes a return statement look like a function-call statement.
>> Because of the popularity of that style, I've known people who thought
>> that it was a function.
>
> This shows that it is an advantage to adopt an homogenous syntax.

I don't see how it shows that.

> Note that we already have:
>
>  if(…)
>  while(…)
>  do(…)
>  for(…)
>
>  your_random_function(…)

In each of those cases, the closing ")" is needed to mark the end of the
condition.  Some languages instead use a keyword (if condition then,
while condition do, etc.)    

> so why not:
>
>  return(…)

Because the parentheses are unnecessary (the semicolon marks the end of
the expression), and as others have said they make it look too much like
a function call, *which it isn't*.

(Personally, I always use a space in "if (condition)" and never in
"func(params)").

[...]

-- 
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]

#141837

On 09/03/2019 03:22, Keith Thompson wrote:
> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>
>>>> I have also tended to write things like "return(0);", even if
>>>> technically the parens are superfluous in this case.
>>>
>>> That makes a return statement look like a function-call statement.
>>> Because of the popularity of that style, I've known people who thought
>>> that it was a function.
>>
>> This shows that it is an advantage to adopt an homogenous syntax.
> 
> I don't see how it shows that.
> 
>> Note that we already have:
>>
>>   if(…)
>>   while(…)
>>   do(…)
>>   for(…)
>>
>>   your_random_function(…)
> 
> In each of those cases, the closing ")" is needed to mark the end of the
> condition.  Some languages instead use a keyword (if condition then,
> while condition do, etc.)
> 
>> so why not:
>>
>>   return(…)
> 
> Because the parentheses are unnecessary (the semicolon marks the end of
> the expression), and as others have said they make it look too much like
> a function call, *which it isn't*.
> 
> (Personally, I always use a space in "if (condition)" and never in
> "func(params)").
> 

I make the distinction in spacing between:

	foo(x);		// no space, function call

and for non-funciton calls:

	if (x) ...
	while (x) ...

I see these as different uses of parenthesis - /not/ a homogenous syntax 
- and the spacing makes that clearer.

If I wanted to put extra parenthesis on a return (I don't usually, 
unless it is a complex expression and I think it looks clearer), then 
there would be a space:

	return (x + y);

To me, that is clearly not a funciton call.

(I have no space for macro calls either.)

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

#141844

David Brown <david.brown@hesbynett.no> writes:
[...]
> If I wanted to put extra parenthesis on a return (I don't usually, 
> unless it is a complex expression and I think it looks clearer), then 
> there would be a space:
>
> 	return (x + y);
>
> To me, that is clearly not a funciton call.

Agreed.

One small point, though.  I don't think there's *ever* a case where I
would find a return statement clearer with parentheses than without.
(Of course I'm talking about top-level parentheses on the full
expression.)  The expression is clearly delimited by the "return"
keyword and the semicolon.

-- 
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]

#141857

On 09/03/2019 21:20, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> If I wanted to put extra parenthesis on a return (I don't usually,
>> unless it is a complex expression and I think it looks clearer), then
>> there would be a space:
>>
>> 	return (x + y);
>>
>> To me, that is clearly not a funciton call.
> 
> Agreed.
> 
> One small point, though.  I don't think there's *ever* a case where I
> would find a return statement clearer with parentheses than without.
> (Of course I'm talking about top-level parentheses on the full
> expression.)  The expression is clearly delimited by the "return"
> keyword and the semicolon.
> 

I can't think of many example situations where I would have parenthesis 
on a return statement.  If the expression involved was too complicated 
to be clearly understood, I'd break it up.  A quick search of some code 
I've written shows occasional use of it - often for something like:

	return (x == 0);

I haven't bothered looking at the context, but I assume I simply thought 
it looked clearer that way.

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

#141830

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

> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>>> I have also tended to write things like "return(0);", even if 
>>> technically the parens are superfluous in this case.
>>
>> That makes a return statement look like a function-call statement.
>> Because of the popularity of that style, I've known people who thought
>> that it was a function.
>
> This shows that it is an advantage to adopt an homogenous syntax.
> Note that we already have:
>
>  if(…)
>  while(…)
>  do(…)

Not in C.  The 'do' statement ends with the condition after a 'while'.

>  for(…)
>
>  your_random_function(…)
>
> so why not:
>
>  return(…)

Ken Thompson certainly thought so (early C imported this syntax from B).
But then you'd also need

  goto(...)
  break()
  continue()

and so on too if you want consistency.

> Now, in for(…;…;…)… we already have 3 expressions in the parentheses,

or a declaration and two expressions.

> so
> the question is why not also put inside the parentheses the following
> expression?  in if(…)… we already have one expression in the
> parentheses, so the question is why not also put inside the parentheses
> the following expression?  and so on.
>
>   (if test then else)
>   (while test body)
>   (do body)
>   (for (init test increment) body)
>   (return expression)
>   (your-random-function arguments)
>
> and you get lisp :-)  yay!

No, you just get a syntax a bit like Lisp's.  If you think I'm
nit-picking, write a simple translator from this unified syntax to C's
current syntax and you can then drop using Lisp and switch to C.
Doesn't appeal?  No, I thought not!

(Yes, I saw the :-), but it's too valuable point both ways.  Many people
hate C's syntax, and many people hate Lisp's syntax, but what makes C C
and Lisp Lisp is very much more than that.)

-- 
Ben.

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

#141831

On 3/8/2019 5:52 PM, James Kuyper wrote:
> On 3/6/19 22:54, BGB wrote:
>> On 3/6/2019 1:23 PM, Bart wrote:
> ...
>>> One or two here claim to know the precedences by heart, notably Tim
>>> Rentsch.
> 
> I know most of them, including in particular the ones that I use most
> frequently. Bart seems to imply that he's not sure he believes that
> claim. He shouldn't - as a professional programmer I've had far more
> than enough practical experience with them to memorize those precedence
> levels, despite having never gone out of my way to memorize them.
> 

For the most part, one can have a sense of which things are more tightly 
associative, but not necessarily remembering off-hand which operators go 
on which precedence level.

It is sort of like the ASCII chart, one can remember approximately where 
the characters are, and can mostly reconstruct the table from memory, 
but manually converting a specific character sequence to its hexadecimal 
equivalent may still require looking at the table.


>>> It gets dangerous when they expect everyone else to know them, so their
>>> own code is largely devoid of parentheses.
> 
> It's not so much that I expect everyone else to know them, but rather
> that I have a hard time anticipating which expressions might be less
> clear to the average C programmer than they are to me.
> 
>> I tend to prefer a having a few extra parenthesis, using them to keep
>> the intended behavior unambiguous.
> 
> If they're needed to make the behavior unambiguous, they're not "extra".
> "extra" parenthesis are the ones used to help people who don't have the
> precedences memorized to know what the behavior is even though those
> parentheses are not needed to cause that behavior to happen.
> 

There is unambiguous for the parser, which may be less than those 
appropriate for the expression being "visually ambiguous".

Say:
   if((x>3) && (y<4))
One can also write:
   if(x>3 && y<4)

But, I personally prefer the former style, as the ordering looks more 
explicit.

Similar for preferring '*(--ptr)' rather than '*--ptr', ...


>> I have also tended to write things like "return(0);", even if
>> technically the parens are superfluous in this case.
> 
> That makes a return statement look like a function-call statement.
> Because of the popularity of that style, I've known people who thought
> that it was a function.
> 

Yep.

I think in my case, it is partly an "I have always done it that way" thing.


But, sometimes patterns change as well, for example, I spent much of my 
life only capitalizing the first letter of each sentence in certain 
cases ("proper" writing), and not in more casual writing (emails, Usenet 
posts, ...).

Eventually, I started slipping up, using capitalization in emails and 
similar as well, and mostly since then have been using it everywhere 
(since the pattern was effectively broken at that point).

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

#141917

Bart <bc@freeuk.com> writes:

> On 06/03/2019 18:49, Pascal J. Bourguignon wrote:
>
>> 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.
>
> 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.

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

#141949

On Wed, 2019-03-13, 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.

When you write, elsewhere in the thread

     It isn't hard to remember if one makes an effort to learn.
     Fifteen to thiry minutes, tops, and that's a one-time cost.

it's easy to assume you made that effort.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#141952

On 3/14/19 02:48, Jorgen Grahn wrote:
> On Wed, 2019-03-13, 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.
> 
> When you write, elsewhere in the thread
> 
>      It isn't hard to remember if one makes an effort to learn.
>      Fifteen to thiry minutes, tops, and that's a one-time cost.
> 
> it's easy to assume you made that effort.

Tim is all about subtle distinctions - too subtle for most other people.
There are, as a rule, subtle differences between what Tim seems to be
saying and what he's actually saying. Examining his words carefully is
not a particularly effective way of uncovering those differences. Asking
him questions about what he meant is slightly more effective, but the
same rule applies to his answers to your questions. Also, he will find
subtle distinctions between what you asked and what he believes the
words you used in your question actually mean, and as a result usually
answers a different question than the one you intended to ask. Of
course, that's only if he bothers answering directly at all - his
answers are often subtle clues intended to lead you to figuring out the
answer for yourself. In my experience, they're usually too subtle to
achieve that goal.

So, I'm quite confident that he interprets his comment about "it isn't
hard to remember" in a way that makes it refer to something different
from "knowing the precedences by heart". It's probably similar to the
distinction that I made in my own response, much more explicitly,
between knowing all of them and knowing most of them, with an emphasis
on knowing best the ones that you use most frequently.

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

#141958

On Thu, 2019-03-14, James Kuyper wrote:
> On 3/14/19 02:48, Jorgen Grahn wrote:
>> On Wed, 2019-03-13, 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.
>> 
>> When you write, elsewhere in the thread
>> 
>>      It isn't hard to remember if one makes an effort to learn.
>>      Fifteen to thiry minutes, tops, and that's a one-time cost.
>> 
>> it's easy to assume you made that effort.
>
> Tim is all about subtle distinctions - too subtle for most other people.
> There are, as a rule, subtle differences between what Tim seems to be
...

Well, I later saw a posting about a difference between learning and
memorizing ... My only point is, I guess, most people aren't good at
splitting hairs.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#141963

On Thursday, March 14, 2019 at 10:58:21 AM UTC-4, Jorgen Grahn wrote:
> On Thu, 2019-03-14, James Kuyper wrote:
...
> > Tim is all about subtle distinctions - too subtle for most other people.
> > There are, as a rule, subtle differences between what Tim seems to be
> ...
> 
> Well, I later saw a posting about a difference between learning and
> memorizing ... My only point is, I guess, most people aren't good at
> splitting hairs.

By most people's standards, I'm an expert at splitting hairs - but Tim splits hairs I can't even see.

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

#142036

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Thu, 2019-03-14, James Kuyper wrote:
>
>> On 3/14/19 02:48, Jorgen Grahn wrote:
>>
>>> On Wed, 2019-03-13, 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.
>>>
>>> When you write, elsewhere in the thread
>>>
>>>      It isn't hard to remember if one makes an effort to learn.
>>>      Fifteen to thiry minutes, tops, and that's a one-time cost.
>>>
>>> it's easy to assume you made that effort.
>>
>> Tim is all about subtle distinctions - too subtle for most other people.
>> There are, as a rule, subtle differences between what Tim seems to be
>
> ...
>
> Well, I later saw a posting about a difference between learning and
> memorizing ... My only point is, I guess, most people aren't good at
> splitting hairs.

There are times when I engage in hair splitting, but this wasn't
one of them.  There is an important difference between the two
modes here, which is a significant component of what I've been
saying about C expression syntax.  Let me offer a story to
illustrate.

Where I went to school, Chemistry majors were given a closed-book
exam - the nature of which was known in advance - on the chemical
elements.  The test consisted of being given a blank outline of
the standard periodic table, with the test being to fill it in
during the examination period.  (I was not a Chemistry major.  I
don't know what level of detail was asked for, or was expected.)

This test is one that could be approached just as an exercise in
rote memorization.  But that wasn't the purpose of test, and most
students didn't approach it that way.  The point is to understand
the nature of relationships between the various elements, which
if done allows the blank periodic table to be filled in fairly
easily, and much moreso than just relying on straight memorization
(at least for Chemistry majors).  The value of preparing for the
exam is not to know how to fill in a blank periodic table, but to
learn how the different elements relate to each other, which goes
a long way towards understanding how the chemistry works when
various elements are combined.

Similarly, how operators in C relate to each other has a fair
amount of organizational structure.  Most of what I know about
C expression syntax comes from understanding that structure,
not rote memorization.  Rarely is it the case that I feel a
need to look up how a given expression parses, but a more
important benefit is a deeper understanding of the language as
a whole and how it all fits together.  I do think there is
value in knowing the whole of C expression syntax (even if not
necessarily the exact grammar rules that define that syntax).
More importantly though there is value in understanding the
structure of the language as a whole, which learning more
of C's expression syntax will promote.

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

#142302

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 3/14/19 02:48, Jorgen Grahn wrote:
>
>> On Wed, 2019-03-13, 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.
>>
>> When you write, elsewhere in the thread
>>
>>      It isn't hard to remember if one makes an effort to learn.
>>      Fifteen to thiry minutes, tops, and that's a one-time cost.
>>
>> it's easy to assume you made that effort.
>
> Tim is all about subtle distinctions - too subtle for most other people.
> There are, as a rule, subtle differences between what Tim seems to be
> saying and what he's actually saying.  Examining his words carefully is
> not a particularly effective way of uncovering those differences.  Asking
> him questions about what he meant is slightly more effective, but the
> same rule applies to his answers to your questions.  Also, he will find
> subtle distinctions between what you asked and what he believes the
> words you used in your question actually mean, and as a result usually
> answers a different question than the one you intended to ask.  Of
> course, that's only if he bothers answering directly at all - his
> answers are often subtle clues intended to lead you to figuring out the
> answer for yourself.  In my experience, they're usually too subtle to
> achieve that goal.

This description equates my behavior towards you with my behavior
towards other people.  They aren't the same (and quite obviously
so).

btw, it's extremely rude to give this sort of characterization
about a third person in an open forum.

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

#142424

On Saturday, March 23, 2019 at 1:58:01 PM UTC-4, Tim Rentsch wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
...
> > Tim is all about subtle distinctions - too subtle for most other people.
> > There are, as a rule, subtle differences between what Tim seems to be
> > saying and what he's actually saying.  Examining his words carefully is
> > not a particularly effective way of uncovering those differences.  Asking
> > him questions about what he meant is slightly more effective, but the
> > same rule applies to his answers to your questions.  Also, he will find
> > subtle distinctions between what you asked and what he believes the
> > words you used in your question actually mean, and as a result usually
> > answers a different question than the one you intended to ask.  Of
> > course, that's only if he bothers answering directly at all - his
> > answers are often subtle clues intended to lead you to figuring out the
> > answer for yourself.  In my experience, they're usually too subtle to
> > achieve that goal.
> 
> This description equates my behavior towards you with my behavior
> towards other people.  They aren't the same (and quite obviously
> so).
> 
> btw, it's extremely rude to give this sort of characterization
> about a third person in an open forum.

I think the behavior I've described is extremely rude, so we're at least
even in that regard. I don't expect you to agree with me about that; if
you did, you wouldn't engage in such behavior. I am not inclined to
discuss the issue further.

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

#142032

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Wed, 2019-03-13, 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.
>
> When you write, elsewhere in the thread
>
>      It isn't hard to remember if one makes an effort to learn.
>      Fifteen to thiry minutes, tops, and that's a one-time cost.
>
> it's easy to assume you made that effort.

I did make _an_ effort.  I did not make the effort that Bart's
comment would usually imply.  Bart has a habit of evolving the
meaning of remarks by making seemingly minor changes in wording,
so it's important to call him on even small infractions.

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

#141959

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.

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

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

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

csiph-web