🚀 go-pugleaf

>>>>> "Michael" == Michael Malak (malak@grebyn.com)
>>>>> "Lars" == fischer@iesd.auc.dk (Lars Peter Fischer)
>>>>> "John" == John MAX Skaller (maxtal@extro.ucc.su.OZ.AU)

Michael>    1) It has structured syntactic blocks for constants, types and
Michael>       variables.

Lars> Which is not much of an advantage. Look at all the pain Knuth has gone
Lars> through to work around it.

John> 	Could you explain? Seems to me that the simple concept of
John> nesting the symbol table so that symbols go out of scope at the
John> end of the block is very nice.

Ah, yes, but Pascal goes further. I says First we define all the
Types, then all the Variables, then all the Functions, and so on. This
is a pain because it forces you to write type definition here,
variable declarations there, and the functions that manipulate
variables of the types somewhere else again. This is a real pain and
makes code for anything but toy programs very hard to read.

Contrast with the ability in C to group functions, variables and types
as appropriate, in separate compilation units if desired.

Knuth ended up inventing WEB in part to solve these problems, and so
we might see this particular Pascal deficiency as an advantage, since
WEB truly enriches the toolchest of the programmer.

John> 	Dont quite agree. Many 'mess-arounds' in C could be avoided
John> if nested proceedures were supported. C's failure to provide them
John> possibly results from being designed with archaic architectures
John> in mind.

Which mess-arounds are we talking about here? I don't get the
architecture bit -- why would nesting functions be dependent on the
architecture of the hardware used.

John> 	Functional decomposition is a valid technique in my opinion.
John> So is partitioning the state space with objects. Forcing the programmer
John> to use data decomposition because functional decomposition is not
John> properly supported is against the spirit of C++ in my opinion.

Sure. There's no reason you can't use functional decomposition in C.
The question is, will nested functions make it simpler to do? I find
it much more useful to simply hide detail in compilation modules, and
I can't see that writing function A inside function B is any help as
compared to having A be a module-private function living in the same
space as B. The chance that A is not ever going to be used from
anywhere but from B is often slim, and it makes for some strange
structures when some functions are nested while others are moved up
because they are used from to places.

Nah, nested *classes* is what's important to the spirit of C++.
Happily we have that now. If we could just have virtual classes, we'd
be almost there.

John> 	But C cannot be used easily for functional decomposition
John> because it doesn't provide proper support for nested functions.
John> Structured design may not be tied to a specific language,
John> but structured programming in a structured language is certainly
John> easier than in a non-structured one. 

Again, I don't agree that you cannot do functional decomposition if
you do not have nested functions, and I most certainly do not agree
that C is not a structured language. 

I've done my deal of Pascal programming, and once I got hold of a
version that supported separated compilation units I don't think I
really found much use for nested functions again.

Functional decomposition is seldom used in such a pure form that it is
not mixed with a module concept and with identification of data
structures, and such that the decomposition results in a tree and not
DAG.

John> Do you really want to write code in the old BASIC (you know, the
John> one with line numbers and GOSUB without parameters?)

Why on earth do you bring this up? It has nothing to do with C or the
current discussion, or else I've missed something here.

/Lars
--
Lars Fischer, fischer@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Aalborg Univ., DENMARK. | these things.  -- Calvin