Closures in leu of pointers?

rusi rustompmody at gmail.com
Sun Jun 30 04:56:25 EDT 2013


On Sunday, June 30, 2013 2:23:35 AM UTC+5:30, Terry Reedy wrote:
> 
> 
> 
> If, in the general case, the compiler requires two passes to understand 
> a function body, then *so do people*#. This requirement is what trips up 
> people who are either not used to the idea of two-pass compilation or do 
> not cognize that the language requires it.
> 
> # The alternative for either program or people is a 1-pass + 
> backtracking process where all understandings are kept provisional until 
> the end of the body and revised as required. 2 passes are simpler.


Well languages like C have half a dozen such passes!

They are called, preprocessing, compiling, assembling, linking, dynamic linking etc.

And then we have that a variable at one stage becomes a constant at another, eg a macro.

All of which adds up to making scoping/variables an arcane craft.

Now having such passes is one thing. Defining the language in terms of them quite another...

> (Python) is compiled, and the compilation of functions is a two pass 
> affair. The first pass classifies all names. The second pass generates 
> code based on the classification of the first pass. This is not part of 
> the grammar, but implied (required) by the semantic description.


So if understanding a language in terms of machine states -- a so called operational definition -- is unsatisfactory, understanding it in terms of the machine-states of the implementation is doubly so  -- we may call it a meta-operational definition.

Now, thanks to Joel Spolsky we know that abstractions in general will leak including our primary abstractions viz programming languages.  So, no completely banning operational understanding is generally impossible.

However when it is avoidable it should be avoided.

I documented the hell that teachers have teaching operational/meta-operational langauges like C 25 years ago http://www.the-magus.in/Publications/chor.pdf
And I would wish that python at least tries not to repeat C's mistakes!



More information about the Python-list mailing list