Ahead of "main"?

[mdh]

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?
thanks.

[Malcolm McLean]

"mdh" <md**@comcast.netwrote in message
news:11*********************@h2g2000hsg.googlegrou ps.com...

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?
thanks.

Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.
Old C also had no prototypes. So if you put functions in reverse order of
hierarchy, the compiler could do additional checking of arguments. Nowadays
we should prototype all functions, so it doesn't matter where main() is
placed, though obviously it should be either the first or the last function
for readbility.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Eric Sosman]

mdh wrote:

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?

Yes. If you use a function before declaring it, the
compiler makes assumptions about the arguments the function
takes and the value it returns. If the assumptions don't
match what the function actually does, you're in trouble.
(The latest compilers try to keep you out of trouble by
making no assumptions; instead, they issue error messages.)

Here's a point to ponder: A function definition -- the
type, name, arguments, and function body enclosed in { } --
not only defines the function, but also declares it (two
two-syllable verbs both beginning with DE, but they are not
the same). It is possible to declare a function without
defining it, by writing all the same things but omitting the
function body and putting a ; where the { }-enclosed stuff
would have been:

double trouble(int fireBurn, int cauldronBubble);

This tells the compiler about the arguments trouble() expects
and the type of value it returns, which is enough to allow
the compiler to invoke it properly (and to check for some
errors, like writing only one argument). Anytime after a
declaration line like this, you can call the function and
all will be well.

Still later, at some convenient point in the file, you
can supply the actual definition of the function:

double trouble(int fireBurn, int cauldronBubble)
{
if (fireBurn != 0)
return (double)cauldronBubble / fireBurn;
else
return 42.0;
}

There are two main reasons (and some less pressing ones)
for wanting to write declaration-only lines. First, as you
move to larger programs you'll find yourself breaking them
up into separately-compiled files: Why should you copy the
entire body of trouble() into twenty different programs, when
you can compile it once in one file and then let all twenty
programs call it? To make this work, you need to write a
declaration-only line for trouble() that the other twenty
programs can use; the usual practice is to put this line in
a .h file the twenty programs can all #include.

A second reason pops up less frequently, but does occur
now and then. What if you have two functions macduff() and
macbeth(), and under some circumstances each of them calls
the other?

double macduff(int x) {
...
if (! i_am_thane)
y = macbeth(x);
...
}

double macbeth(int y) {
...
layOn = macduff(y + 42);
...
}

No matter which definition you place first, the other function's
definition will not have appeared by the time you get to its
call. The compiler will either make a wrong assumption about
the as-yet-undefined function, or will protest and sulk in a
corner. The solution is to write a declaration-only line for
one (or both) of the functions:

double macbeth(int); /* optional: omit arg names */

double macduff(int x) {
...
}

double macbeth(int y) {
...
}

--
Eric Sosman
es*****@acm-dot-org.invalid

[mdh]

On Apr 29, 1:41 pm, Eric Sosman <[e-mail]:

mdh wrote:

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a ... diffference in declaring a function
within "main" or "ahead" of it.

>
Yes. If you use a function before declaring it,.....

Here's a point to ponder: A function definition --..... also declares it (two
two-syllable verbs both beginning with DE, but they are not
the same). It is possible to declare a function without
defining it,......

Thank you....as I do C more and more, I realize that words really
count.

>
There are two main reasons (and some less pressing ones)
for wanting to write declaration-only lines. First, as you
move to larger programs you'll find yourself breaking them
up into separately-compiled files:

>
A second reason pops up less frequently, but does occur
now and then. What if you have two functions macduff() and
macbeth(), and under some circumstances each of them calls
the other?

Thank you Eric.
So, if I understand you correctly, in my case for a small program, the
key seems to be to understand that a declaration needs to occur prior
to the function being called.
Where that declaration actually occurs (prior to main, or within main)
( under these limited circumstances) is of no consequence. However,
once one gets into the "real" world of C, this would be good
programming ( as you noted with seperate .h files), so I may as well
get used to practising good style!!

[mdh]

On Apr 29, 1:40 pm, "Malcolm McLean" <[e-mail]:

>
Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.
Old C also had no prototypes. So if you put functions in reverse order of
hierarchy, the compiler could do additional checking of arguments. Nowadays
we should prototype all functions, so it doesn't matter where main() is
placed, though obviously it should be either the first or the last function
for readbility.

tks.

[Stephen Sprunk]

"mdh" <md**@comcast.netwrote in message
news:11*********************@h2g2000hsg.googlegrou ps.com...

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?

In Standard C, functions cannot be declared "within" main(); these are
called nested functions and are implemented as an extension by some
compilers, but in general you should never use them. Therefore, the debate
is about whether to declare functions before or after main().

As a rule, you should declare all functions before you call them; I won't go
into the reasons why, as Eric did a good job of that. One style is to
define all other functions before main(), which also declares them. The
other is to declare all of your functions in a group near the beginning of
the source, and then you can define them in any order you want. The latter
style is effectively required when you move to multi-file projects, and the
standard practice is to put all of your function declarations in header (.h)
files so that each source file can simply #include the appropriate header
files and then use whatever functions are needed.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

[Eric Sosman]

mdh wrote:

On Apr 29, 1:41 pm, Eric Sosman <[e-mail]:

>[...]
Here's a point to ponder: A function definition --..... also declares it (two
two-syllable verbs both beginning with DE, but they are not
the same). It is possible to declare a function without
defining it,......

[...]
So, if I understand you correctly, in my case for a small program, the
key seems to be to understand that a declaration needs to occur prior
to the function being called.
Where that declaration actually occurs (prior to main, or within main)
( under these limited circumstances) is of no consequence. However,
once one gets into the "real" world of C, this would be good
programming ( as you noted with seperate .h files), so I may as well
get used to practising good style!!

I think you are still confusing "declaration" and
"definition." You should declare every function before
trying to call it (modern compilers change "should" to
"must"), but you can define the function wherever you
like. Since a definition is also a declaration (but not
vice-versa), if you define the function before calling
it you don't need a separate declaration. If you define
the function after calling it, or if you define it in a
separately-compiled file, you need a declaration prior
to the first call.

Eventually this will make sense. Trust me.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Barry Schwarz]

On Sun, 29 Apr 2007 21:40:00 +0100, "Malcolm McLean"
<re*******@btinternet.comwrote:

>
"mdh" <md**@comcast.netwrote in message
news:11*********************@h2g2000hsg.googlegro ups.com...

>Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?
thanks.

Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.

It is certainly possible to declare a function within another.
Defining is prohibited but declaring is allowed. The drawback is that
the declaration has block scope and will not be visible to any other
function in the translation unit.

>Old C also had no prototypes. So if you put functions in reverse order of

Not always possible if function1 and function2 call each other as part
of a recursive algorithm.

>hierarchy, the compiler could do additional checking of arguments. Nowadays
we should prototype all functions, so it doesn't matter where main() is
placed, though obviously it should be either the first or the last function
for readbility.

Remove del for email

[Flash Gordon]

Stephen Sprunk wrote, On 29/04/07 22:35:

"mdh" <md**@comcast.netwrote in message
news:11*********************@h2g2000hsg.googlegrou ps.com...

>Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?

In Standard C, functions cannot be declared "within" main(); these are
called nested functions and are implemented as an extension by some
compilers, but in general you should never use them.

Wrong. They can be *declared* within main or any other function, they
just cannot be *defined* in a function. A declaration says something
exists, a definition says what it is, the difference is important in C.

Therefore, the
debate is about whether to declare functions before or after main().

As a rule, you should declare all functions before you call them; I
won't go into the reasons why, as Eric did a good job of that. One
style is to define all other functions before main(), which also
declares them. The other is to declare all of your functions in a group
near the beginning of the source, and then you can define them in any
order you want. The latter style is effectively required when you move
to multi-file projects, and the standard practice is to put all of your
function declarations in header (.h) files so that each source file can
simply #include the appropriate header files and then use whatever
functions are needed.

Actually, you should not put *all* your function definitions in header
files, since generally there are some which should be local to a given
source file and declared static in that source file. I.e. you should
always limit visibility to the smallest unit that makes sense, since
then you don't have to look as far to see all of the usage.
--
Flash Gordon

[J. J. Farrell]

On Apr 29, 1:40 pm, "Malcolm McLean" <[e-mail]:

"mdh" <[e-mail] in message

news:11*********************@h2g2000hsg.googlegrou ps.com...Hi all,

Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?
thanks.

Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.

Nonsense. There is no problem declaring functions inside main or any
other function. The reasons why you may not want to do so are the
scoping rules, since the declaration would only be visible within the
same block as the declaration. On the other hand, that's perhaps
exactly why you would want to do it on the few occasions where it
makes sense to do so.

[Richard Tobin]

In article <46***********************@free.teranews.com>,
Stephen Sprunk <st*****@sprunk.orgwrote:

>Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?

>In Standard C, functions cannot be declared "within" main(); these are
called nested functions and are implemented as an extension by some
compilers, but in general you should never use them. Therefore, the debate
is about whether to declare functions before or after main().

This would be true if you said "defined" rather than "declared". It's
perfectly legal to declare functions in main(), for example:

int main(void)
{
int foo(void);
...

and this does not create nested functions. It's not however
a common style.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[J. J. Farrell]

On Apr 29, 2:35 pm, "Stephen Sprunk" <[e-mail]:

"mdh" <[e-mail] in message

news:11*********************@h2g2000hsg.googlegrou ps.com...

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?

In Standard C, functions cannot be declared "within" main(); these are
called nested functions ...

No, they're called function declarations are are certainly allowed
within main() and any other function. You're confusing declaration
with definition. You can't define a function within another function
in Standard C.

[Flash Gordon]

Barry Schwarz wrote, On 29/04/07 23:29:

On Sun, 29 Apr 2007 21:40:00 +0100, "Malcolm McLean"
<re*******@btinternet.comwrote:

>"mdh" <md**@comcast.netwrote in message
news:11*********************@h2g2000hsg.googlegro ups.com...

>>Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?
thanks.

Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.

It is certainly possible to declare a function within another.
Defining is prohibited but declaring is allowed. The drawback is that
the declaration has block scope and will not be visible to any other
function in the translation unit.

Of course, if Malcolm meant define, he was also wrong as far as K&R1 is
concerned, since on page 3 it says, "Function definitions cannot be
nested..."

>Old C also had no prototypes. So if you put functions in reverse order of

Not always possible if function1 and function2 call each other as part
of a recursive algorithm.

>hierarchy, the compiler could do additional checking of arguments. Nowadays
we should prototype all functions, so it doesn't matter where main() is
placed, though obviously it should be either the first or the last function
for readbility.

Pre-ANSI there was no requirement for the compiler to check the
parameters even if the function was defined before use. Also on page 3
of K&R1 it refers to using lint to detect inconsistent argument usage.
--
Flash Gordon
Now with a near-mint condition copy of K&R1 courtesy of my company
having a clear-out.

[mdh]

Thank you all who answered. In fact, it does make a lot more sense now.

[mdh]

On Apr 29, 2:42 pm, Eric Sosman <[e-mail]:

>>

I think you are still confusing "declaration" and
"definition." You should declare every function before
trying to call it (modern compilers change "should" to
"must"), but you can define the function wherever you
like.

Maybe I did not articulate that well, but I understand that, thanks.

Eventually this will make sense. Trust me.

How could I not trust anyone who so beautifully intertweaves
Shakespeare with Hitchhikers Guide to the Galaxy?

[Eric Sosman]

mdh wrote:

On Apr 29, 2:42 pm, Eric Sosman <[e-mail]:

> I think you are still confusing "declaration" and
"definition." You should declare every function before
trying to call it (modern compilers change "should" to
"must"), but you can define the function wherever you
like.

Maybe I did not articulate that well, but I understand that, thanks.

> Eventually this will make sense. Trust me.

How could I not trust anyone who so beautifully intertweaves
Shakespeare with Hitchhikers Guide to the Galaxy?

Be bloody, bold, and resolute, and never lose
track of your towel!

--
Eric Sosman
es*****@acm-dot-org.invalid

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:

"mdh" <md**@comcast.netwrote in message
news:11*********************@h2g2000hsg.googlegrou ps.com...

>Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?
thanks.

Some early versions of C had local functions, declared within the
function that called them. The idea never caught on, and it is now not
possible to declare functions within main.

I don't believe any early versions of C ever allowed you to *define*
functions within other functions (though some compilers allow it as an
extension).

It's always been possible to *declare* functions within a function
definition.

(A function definition includes the body that implements the
function. A definition is also a declaration.)

For example, the following is legal, and always has been, though
it's often considered poor style:

int outer()
{
int inner(); /* declare function inner */

inner(); /* call function inner, which must be
defined elsewhere */
}

The following is not legal (except as an extension) and never has been:

int outer()
{
int inner()
{
printf("Nope\n");
}

inner();
}

The real question is whether function *declarations* should appear at
file scope, or within a function definition. If a function is called
*only* from one function, it might make sense to declare it inside the
caller -- but since the definition has to be somewhere else anyway,
that doesn't really help encapsulation.

In any sizeable program, most of your functions are going to be in
separate source files, to be compiled and linked together with the one
containing main(). Usually you want function definitions in a .c
file, and declarations (to be visible to other translation units) in a
..h file.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[mdh]

On Apr 29, 7:05 pm, Keith Thompson <[e-mail]:

In any sizeable program, most of your functions are going to be in
separate source files, to be compiled and linked together with the one
containing main(). Usually you want function definitions in a .c
file, and declarations (to be visible to other translation units) in a
.h file.

tks.

[Richard Heathfield]

Malcolm McLean said:

Some early versions of C had local functions, declared within the
function that called them. The idea never caught on, and it is now not
possible to declare functions within main.

If you could just sort of stop making stuff up, it would be helpful.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Chris Dollin]

Malcolm McLean wrote:

Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.

I'm not sure /exactly/ what you're saying; but if I read you
properly, what you're saying is false.

To the best of my knowledge, no "early" versions of C had local
functions, that is, functions /defined/ inside other functions.
(I don't count BCPL as an early version of C.)

Again to the best of my knowledge, /all/ versions of C allow you
to /declare/ -- not define -- (external) functions inside functions.

Old C also had no prototypes.

Yes (where "Old" means "pre-Standard", for a useful value of "had").

So if you put functions in reverse order of
hierarchy, the compiler could do additional checking of arguments.

Whatever the order you used, the compiler "could" do such checking.
In practice it didn't: one used "lint".

Nowadays we should prototype all functions,

Not true if by "prototype" you mean "declare with a prototype"
rather than "define using typed-argument syntax".

so it doesn't matter where
main() is placed, though obviously it should be either the first or the
last function for readbility.

I'm not sure about that last: it's not /obvious/, even if it's
true.

--
Prototypical Hedgehog
Meaning precedes definition.

[Barry Schwarz]

On Sun, 29 Apr 2007 23:48:23 +0100, Flash Gordon
<sp**@flash-gordon.me.ukwrote:

>Stephen Sprunk wrote, On 29/04/07 22:35:

>"mdh" <md**@comcast.netwrote in message
news:11*********************@h2g2000hsg.googlegro ups.com...

>>Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?

In Standard C, functions cannot be declared "within" main(); these are
called nested functions and are implemented as an extension by some
compilers, but in general you should never use them.

Wrong. They can be *declared* within main or any other function, they
just cannot be *defined* in a function. A declaration says something
exists, a definition says what it is, the difference is important in C.

Therefore, the
debate is about whether to declare functions before or after main().

As a rule, you should declare all functions before you call them; I
won't go into the reasons why, as Eric did a good job of that. One
style is to define all other functions before main(), which also
declares them. The other is to declare all of your functions in a group
near the beginning of the source, and then you can define them in any
order you want. The latter style is effectively required when you move
to multi-file projects, and the standard practice is to put all of your
function declarations in header (.h) files so that each source file can
simply #include the appropriate header files and then use whatever
functions are needed.

Actually, you should not put *all* your function definitions in header
files, since generally there are some which should be local to a given
source file and declared static in that source file. I.e. you should
always limit visibility to the smallest unit that makes sense, since
then you don't have to look as far to see all of the usage.

You should not put any function definitions in a header file. I would
go a step further and say no object definitions either. Only
declarations. The only definitions in a header file should be typedef
(oops, even though it is called a type definition in the standard, it
is specifically described as a declaration) and macro definitions.
Remove del for email

[Richard Tobin]

In article <rm********************************@4ax.com>,
Barry Schwarz <sc******@doezl.netwrote:

>You should not put any function definitions in a header file.

Except inline function definitions.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Flash Gordon]

Barry Schwarz wrote, On 30/04/07 12:00:

On Sun, 29 Apr 2007 23:48:23 +0100, Flash Gordon
<sp**@flash-gordon.me.ukwrote:

>Stephen Sprunk wrote, On 29/04/07 22:35:

<snip>

>>As a rule, you should declare all functions before you call them; I
won't go into the reasons why, as Eric did a good job of that. One
style is to define all other functions before main(), which also
declares them. The other is to declare all of your functions in a group
near the beginning of the source, and then you can define them in any
order you want. The latter style is effectively required when you move
to multi-file projects, and the standard practice is to put all of your
function declarations in header (.h) files so that each source file can
simply #include the appropriate header files and then use whatever
functions are needed.

Actually, you should not put *all* your function definitions in header
files, since generally there are some which should be local to a given
source file and declared static in that source file. I.e. you should
always limit visibility to the smallest unit that makes sense, since
then you don't have to look as far to see all of the usage.

You should not put any function definitions in a header file. I would
go a step further and say no object definitions either. Only
declarations. The only definitions in a header file should be typedef
(oops, even though it is called a type definition in the standard, it
is specifically described as a declaration) and macro definitions.

It was a trypo. I meant you should not put all your function
declarations in your headers.
--
Flash Gordon

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Barry Schwarz wrote:

You should not put any function definitions in a header file. I would
go a step further and say no object definitions either. Only
declarations. The only definitions in a header file should be typedef
(oops, even though it is called a type definition in the standard, it
is specifically described as a declaration)

All definitions are also declarations (macro definitions don't count
as "definitions"). A type definition is both a declaration and a
definition. A definition of an enumeration constant is also a
definition that can be appropriate for header files.

and macro definitions.

[David Thompson]

On Mon, 30 Apr 2007 06:00:41 GMT, Chris Dollin
<[e-mail]:

Malcolm McLean wrote:

Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.

I'm not sure /exactly/ what you're saying; but if I read you
properly, what you're saying is false.

To the best of my knowledge, no "early" versions of C had local
functions, that is, functions /defined/ inside other functions.
(I don't count BCPL as an early version of C.)

And IIRC that vitiated the potential benefit by prohibiting access to
outerscope (nonglobal) variables, punting on the closure issue.

Again to the best of my knowledge, /all/ versions of C allow you
to /declare/ -- not define -- (external) functions inside functions.

Right.

Old C also had no prototypes.

Yes (where "Old" means "pre-Standard", for a useful value of "had").

I'm having trouble thinking of plausible nonuseful values of 'had'.
<OTDoes it depend on what 'is' is? <GG!</>

So if you put functions in reverse order of
hierarchy, the compiler could do additional checking of arguments.

Whatever the order you used, the compiler "could" do such checking.
In practice it didn't: one used "lint".

Nowadays we should prototype all functions,

Not true if by "prototype" you mean "declare with a prototype"
rather than "define using typed-argument syntax".

I'm not sure if your second alternative was meant to be "define using
prototype syntax" or "define using K&R1 syntax" or even both. But:
it is certainly not REQUIRED to use prototypes, even in C99, except
for variable arguments or arithmetic parameters narrower than int or
double. It is however always or almost so a good idea, and thus I
would agree with 'should'.

so it doesn't matter where
main() is placed, though obviously it should be either the first or the
last function for readbility.

I'm not sure about that last: it's not /obvious/, even if it's
true.

Depends on who's looking. <G>

- formerly david.thompson1 || achar(64) || worldnet.att.net

[Chris Dollin]

David Thompson wrote:

On Mon, 30 Apr 2007 06:00:41 GMT, Chris Dollin
<[e-mail]:

>Malcolm McLean wrote:

Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.

I'm not sure /exactly/ what you're saying; but if I read you
properly, what you're saying is false.

To the best of my knowledge, no "early" versions of C had local
functions, that is, functions /defined/ inside other functions.
(I don't count BCPL as an early version of C.)

And IIRC that vitiated the potential benefit by prohibiting access to
outerscope (nonglobal) variables, punting on the closure issue.

While I'm all in favour of full lexical scoping, I don't think that's
compatible with the design of BCPL, and, for the same reasons, with
that of C.

One might be able to manage the downward case with a big dose of
"if the function escapes, The Behaviour Is Undefined". But even
then there's a Cost which people might not be prepared to pay
(since now the function [pointer] has to carry some kind of
scope reference around with it.)

--
"People are part of the design. It's dangerous to forget that." /Star Cops/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England