Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: getting perl and C working together in a way that makes sense

Reply
Thread Tools

Re: getting perl and C working together in a way that makes sense

 
 
Mark Bluemel
Guest
Posts: n/a
 
      02-03-2013
On Feb 2, 11:45*am, "BartC" <(E-Mail Removed)> wrote:
>... The above function in reality looks like the following (you may wish
> to avert your eyes):
>
> global function int eof(FILE* handle) =
> int c;
>
> c:=getc(handle);
> if (c=EOF) then
> *return 1;
> fi
> ungetc(c,handle);
> return 0;
> end
>
> This is converted to standard C code by a preprocessor, so the issue of C
> people not understanding it doesn't arise. And the preprocessor is a small
> program that uses a while-loop with, obviously, an eof() test at the
> beginning! This transparent conversion to C only adds some 3% to compilation
> times, so the extra overheads of such an eof are not a problem in this
> case.)


You are Stephen Bourne and I claim my 5 curly braces.

<http://oldhome.schmorp.de/marc/bournegol.html>

 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      02-03-2013
On Sun, 2013-02-03, Mark Bluemel wrote:
> On Feb 2, 11:45*am, "BartC" <(E-Mail Removed)> wrote:

....
>> This is converted to standard C code by a preprocessor, so the issue of C
>> people not understanding it doesn't arise.

....

> You are Stephen Bourne and I claim my 5 curly braces.
>
> <http://oldhome.schmorp.de/marc/bournegol.html>


/*
* UNIX shell
*
* S. R. Bourne
* Bell Telephone Laboratories
*
*/

#define LOCAL static
#define PROC extern
...
#define ELIF} else if (
...

Ugh. Wonder what Dennis and the others at Bell Labs had to say about
that?

(Oddly, earlier today I edited source code which for some reason uses
the LOCAL macro just like Bourne did ~40 years ago.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
BartC
Guest
Posts: n/a
 
      02-03-2013


"Jorgen Grahn" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..
> On Sun, 2013-02-03, Mark Bluemel wrote:


>> <http://oldhome.schmorp.de/marc/bournegol.html>

>
> /*
> * UNIX shell
> *
> * S. R. Bourne
> * Bell Telephone Laboratories
> *
> */
>
> #define LOCAL static
> #define PROC extern
> ...
> #define ELIF} else if (
> ...
>
> Ugh. Wonder what Dennis and the others at Bell Labs had to say about
> that?


Are these the same people who devised:

#if
#elif
#endif

for the preprocessor? If so why didn't they use the same style of syntax for
the language itself? Then they could have got rid of all those annoying
braces as obviously others have attempted to do!

--
Bartc

 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      02-03-2013
On 2/3/2013 16:51, BartC wrote:
>
>
> "Jorgen Grahn" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed). ..
>> On Sun, 2013-02-03, Mark Bluemel wrote:

>
>>> <http://oldhome.schmorp.de/marc/bournegol.html>

>>
>> /*
>> * UNIX shell
>> *
>> * S. R. Bourne
>> * Bell Telephone Laboratories
>> *
>> */
>>
>> #define LOCAL static
>> #define PROC extern
>> ...
>> #define ELIF} else if (
>> ...
>>
>> Ugh. Wonder what Dennis and the others at Bell Labs had to say about
>> that?

>
> Are these the same people who devised:
>
> #if
> #elif
> #endif
>
> for the preprocessor? If so why didn't they use the same style of syntax
> for
> the language itself? Then they could have got rid of all those annoying
> braces as obviously others have attempted to do!
>


I'm sure you're already aware that the braces used with 'if' contribute
to what's called a "compound statement". I guess that you would
consider 'endif', 'endwhile' (remember BASIC's "wend"?), 'endswitch',
'endfor' to be less annoying than the more general compound statement?
What makes the braces annoying, exactly?

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-03-2013
"BartC" <(E-Mail Removed)> writes:
> "Jorgen Grahn" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed). ..
>> On Sun, 2013-02-03, Mark Bluemel wrote:

>
>>> <http://oldhome.schmorp.de/marc/bournegol.html>

>>
>> /*
>> * UNIX shell
>> *
>> * S. R. Bourne
>> * Bell Telephone Laboratories
>> *
>> */
>>
>> #define LOCAL static
>> #define PROC extern
>> ...
>> #define ELIF} else if (
>> ...
>>
>> Ugh. Wonder what Dennis and the others at Bell Labs had to say about
>> that?

>
> Are these the same people who devised:
>
> #if
> #elif
> #endif
>
> for the preprocessor? If so why didn't they use the same style of syntax for
> the language itself? Then they could have got rid of all those annoying
> braces as obviously others have attempted to do!


The answer is simple: the designers of C did not consider the braces to
be annoying.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      02-03-2013
In article <kemq02$dq2$(E-Mail Removed)>,
Shao Miller <(E-Mail Removed)> wrote:
....
>I'm sure you're already aware that the braces used with 'if' contribute
>to what's called a "compound statement". I guess that you would
>consider 'endif', 'endwhile' (remember BASIC's "wend"?), 'endswitch',
>'endfor' to be less annoying than the more general compound statement?
>What makes the braces annoying, exactly?


The reason is that when the "end" thingie is named such that it
unambiguously matches up with control structure beginning thingie, then you
can easily tell to which thing it is (or should be) matched. I.e., when you
have FOR/NEXT, IF/ENDIF, WHILE/ENDWHILE (or whatever your particular
language uses), you don't have to go searching for what it matches to. Yes,
I know that nowadays we have syntax-checking editors and tools to sort it
out, but it wasn't always like this.

Further, if you have an editing slip-of-the-finger (or, in the old days,
dropped a stack of punched cards), you could then be screwed good.

So, there is clearly an advantage in having it matched up, instead of all
the control structures using the same block-delimters.

--
Given Bush and his insanely expensive wars (*), that we will be paying for
for generations to come, the only possible response a sensible person need
ever give, when a GOPer/TeaBagger says anything about "deficits", is a
polite snicker.

(*) Obvious money transfers between the taxpayers and Bush's moneyed
interests. Someday, we'll actually figure out a way to have a war where the
money just gets moved around and nobody (on either side) gets injured or
killed. That will be an accomplishment of which we will be justly proud.

 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      02-03-2013
"Shao Miller" <(E-Mail Removed)> wrote in message
news:kemq02$dq2$(E-Mail Removed)...
> On 2/3/2013 16:51, BartC wrote:


>> Are these the same people who devised:
>>
>> #if
>> #elif
>> #endif
>>
>> for the preprocessor? If so why didn't they use the same style of syntax
>> for
>> the language itself? Then they could have got rid of all those annoying
>> braces as obviously others have attempted to do!
>>

>
> I'm sure you're already aware that the braces used with 'if' contribute to
> what's called a "compound statement". I guess that you would consider
> 'endif', 'endwhile' (remember BASIC's "wend"?), 'endswitch', 'endfor' to
> be less annoying than the more general compound statement?


Those forms are a little annoying, but less so than braces!

Together with 'then', if-statements become:

if (...) then
stmt1;
stmt2;
...
else
stmt6;
...
endif

The need for a specific compound statement disappears. You don't need to
keep adding and removing braces when the number of statements in each block
changes between 1 and more than 1. The 'else' and 'endif' keywords are more
likely to be where you might expect it (ie. lined up with 'if'). The 'endif'
terminator will *always* be there (unlike a closing }). Writing 'endwhile'
instead of 'endif' would be a more obvious error, and instantly picked up,
than writing '}' instead of '}' (where the first '}' is supposed to close
'while', and the second is for closing 'if').

> What makes the braces annoying, exactly?


Where do I start?! Let's take the 'else' statement, which appears in these
different contexts:

else
} else
else {
} else {

The trouble is each of those braces isn't positioned as consistently as I've
shown. It can be difficult to tell at a glance which of these 4 else's
you're dealing with. That's significant when you have the modify the 1 or N
statements before or after the else. The fact that you have to be constantly
aware that you have 1 or N statements is itself annoying!

There are too many possibilities and styles for placement of a '{' and '}':

if (... ) {
stmt;

if (...)
{ stmt;

if (...)
{
stmt;

with the additional options of whether they '{' an '}' line up with each
other, and with 'if' and 'else.

Then there is no distinction the various '}': the same symbol closes an if,
for, while, do, switch, and even a function! (Initialisation data too.)
You just can't tell them apart (see point I made above). With {,} often
being optional, a missing or superfluous { or } can cause chaos (if you
can't enlist help from a smart editor).

Finally, they are just too flimsy a symbol to close something substantial
such as a large switch or function body.

--
Bartc

 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      02-04-2013
On 2/3/2013 18:43, Kenny McCormack wrote:
> In article <kemq02$dq2$(E-Mail Removed)>,
> Shao Miller <(E-Mail Removed)> wrote:
> ...
>> I'm sure you're already aware that the braces used with 'if' contribute
>> to what's called a "compound statement". I guess that you would
>> consider 'endif', 'endwhile' (remember BASIC's "wend"?), 'endswitch',
>> 'endfor' to be less annoying than the more general compound statement?
>> What makes the braces annoying, exactly?

>
> The reason is that when the "end" thingie is named such that it
> unambiguously matches up with control structure beginning thingie, then you
> can easily tell to which thing it is (or should be) matched. I.e., when you
> have FOR/NEXT, IF/ENDIF, WHILE/ENDWHILE (or whatever your particular
> language uses), you don't have to go searching for what it matches to. Yes,
> I know that nowadays we have syntax-checking editors and tools to sort it
> out, but it wasn't always like this.
>
> Further, if you have an editing slip-of-the-finger (or, in the old days,
> dropped a stack of punched cards), you could then be screwed good.
>
> So, there is clearly an advantage in having it matched up, instead of all
> the control structures using the same block-delimters.
>


Aha. Yes, I'll admit that in the past, if a compound statement followed
one of these thingies and lasted for more than 24 lines, and if there
were multiple such thingies nested, I'd sometimes throw a /* while */
(or whatever the thingy was) after the closing brace. These days, I try
to avoid these two criteria combined together and the indentation should
be sufficient for the eye to line things up at a glance.

For example, a function might have the majority of its body as a 'while'
loop with a compound statement. That might be more than 24 lines, but
any nested 'if's or other loops have to be really short to avoid
confusion. Then after scrolling down to the bottom of the function,
it's still obvious that the penultimate closing brace in the function is
for the 'while' that was at the beginning, without a /* while */ note.

But I can appreciate the point; thanks.

void func(void) {
while (1) {





while (1) {
int i = 42;
break;
}


















}
}

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-04-2013
"BartC" <(E-Mail Removed)> writes:
> "Shao Miller" <(E-Mail Removed)> wrote in message
> news:kemq02$dq2$(E-Mail Removed)...
>> On 2/3/2013 16:51, BartC wrote:

>
>>> Are these the same people who devised:
>>>
>>> #if
>>> #elif
>>> #endif
>>>
>>> for the preprocessor? If so why didn't they use the same style of syntax
>>> for
>>> the language itself? Then they could have got rid of all those annoying
>>> braces as obviously others have attempted to do!
>>>

>>
>> I'm sure you're already aware that the braces used with 'if' contribute to
>> what's called a "compound statement". I guess that you would consider
>> 'endif', 'endwhile' (remember BASIC's "wend"?), 'endswitch', 'endfor' to
>> be less annoying than the more general compound statement?

>
> Those forms are a little annoying, but less so than braces!


There is no objective measure of annoyance. Braces are annoying *to you*.

> Together with 'then', if-statements become:
>
> if (...) then
> stmt1;
> stmt2;
> ...
> else
> stmt6;
> ...
> endif
>
> The need for a specific compound statement disappears. You don't need to
> keep adding and removing braces when the number of statements in each block
> changes between 1 and more than 1. The 'else' and 'endif' keywords are more
> likely to be where you might expect it (ie. lined up with 'if'). The 'endif'
> terminator will *always* be there (unlike a closing }). Writing 'endwhile'
> instead of 'endif' would be a more obvious error, and instantly picked up,
> than writing '}' instead of '}' (where the first '}' is supposed to close
> 'while', and the second is for closing 'if').


Yes, and there are languages that take that approach. The above looks a
lot like Ada, for example, except that Ada doesn't require parentheses
on the if condition and uses "end if;" at the end.

>> What makes the braces annoying, exactly?

>
> Where do I start?! Let's take the 'else' statement, which appears in these
> different contexts:
>
> else
> } else
> else {
> } else {


With a consistent coding style, I haven't found that to be a problem.

> shown. It can be difficult to tell at a glance which of these 4 else's
> you're dealing with. That's significant when you have the modify the 1 or N
> statements before or after the else. The fact that you have to be constantly
> aware that you have 1 or N statements is itself annoying!
>
> There are too many possibilities and styles for placement of a '{' and '}':
>
> if (... ) {
> stmt;
>
> if (...)
> { stmt;
>
> if (...)
> {
> stmt;
>
> with the additional options of whether they '{' an '}' line up with each
> other, and with 'if' and 'else.


Yes, there are a lot of different brace placement styles in C. I'll
even concede that that's a slight drawback of the language. Then again,
I've seen varying layouts for languages that use begin and end keywords;
unless you impose a specific layout, there are going to be variations.

> Then there is no distinction the various '}': the same symbol closes an if,
> for, while, do, switch, and even a function! (Initialisation data too.)
> You just can't tell them apart (see point I made above). With {,} often
> being optional, a missing or superfluous { or } can cause chaos (if you
> can't enlist help from a smart editor).


{ and } delimit compound statements, nothing else. In:

if (condition) {
do_this();
}
else {
do_that();
}

*none* of the braces are part of the syntax of the if statement.

> Finally, they are just too flimsy a symbol to close something substantial
> such as a large switch or function body.


Again, with a consistent layout, I haven't found it to be a problem.

When I learn a new language, I try to learn it in the style of that
language. I might dislike the layout commonly used for language
X, but I'd still rather stick to the language-specific conventions
than try to impose those of my own preferred language. Similarly,
when I speak French (poorly), I don't insist on pronouncing all
the consonants at the ends of words or using English word order;
I have my opinions about the way French is pronounced, but imposing
those opinions isn't going to do anyone any good.

How you write your own code is entirely up to you -- but if you'd try
approaching C on its own terms, rather than trying to impose, say,
Pascal-like concepts onto C syntax, you just might enjoy the language a
bit more. And you'd certainly find it easier to share code, and to mix
it with code written by others.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      02-04-2013
"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "BartC" <(E-Mail Removed)> writes:


>> Then there is no distinction the various '}': the same symbol closes an
>> if,
>> for, while, do, switch, and even a function! (Initialisation data too.)
>> You just can't tell them apart


> { and } delimit compound statements, nothing else. In:
>
> if (condition) {
> do_this();
> }
> else {
> do_that();
> }
>
> *none* of the braces are part of the syntax of the if statement.


I think it's possible to look at it either way. And in your example, you're
acknowledging that the final '}' is part of the if-else statement, by lining
it up with the else, rather than its matching '{'.

Some problems with { and } are solved if they are always used, even to
enclose a single statement (I believe 'Go' has that requirement). But they
are fiddly to write and I always had problems finding a good home for a
closing } before an else, where it doesn't look like it's in the way.

> How you write your own code is entirely up to you -- but if you'd try
> approaching C on its own terms, rather than trying to impose, say,
> Pascal-like concepts onto C syntax, you just might enjoy the language a
> bit more. And you'd certainly find it easier to share code, and to mix
> it with code written by others.


I've tried using normal C syntax, and had endless problems and loads of bugs
because of braces. So here:

else /* comment */
stmt1;
}

the last } is misaligned making it look like it's closing this else branch.
However it still compiles without errors. Then I add an extra statement to
the else branch:

else /* comment */
stmt1;
stmt2;
}

Now have to spend time figuring out why it doesn't work as I expected!
(Although I've spent even more time solving mysterious bugs due to missing a
'*/' at the end of a comment (it gets matched with the next comment in the
code, but a bunch of intermediate lines get commented out); that's another
story however.)

--
Bartc

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: getting perl and C working together in a way that makes sense Jorgen Grahn C Programming 0 02-02-2013 09:55 AM
Re: getting perl and C working together in a way that makes sense Malcolm McLean C Programming 5 02-02-2013 08:31 AM
Re: getting perl and C working together in a way that makes sense Mark Bluemel C Programming 2 02-01-2013 06:58 PM
Re: getting perl and C working together in a way that makes sense Keith Thompson C Programming 0 02-01-2013 04:14 PM
Re: getting perl and C working together in a way that makes sense Johann Klammer C Programming 0 02-01-2013 08:30 AM



Advertisments