headers
Sven Berkvens-Matthijsse | 8 Dec 21:07

Re: req - block-local variables

> On Sat, 2007-12-08 at 10:03 +0100, Stefan Behnel wrote:
> > David McNab wrote:
> > > I'm wishing for the ability to declare cdef vars within blocks
> > > whose scope is confined to the block, just like in C - no
> > > 'leaking out'.
> > 
> > That would be mainly of syntactical interest. While I understand
> > that it would be nice for readability to declare a name only in
> > the scope where it is supposed to be used, you would likely not
> > gain much performance-wise, as C compilers are pretty good in
> > figuring out the 'real' scope of a variable.

Something that is allowed in all versions of C is declaring new
variables at the top of a block, which can then be used only in that
block. One could say: move the variable to the top of the function or
method, as we've stated in the rest of this e-mail thread.

But, there is a situation that can be (ab)used in C in which this
cannot be done without some thought: it's possible to declare
variables with the same name in different blocks that do not have the
same type. For example (in C):

if (something == 0)
{
	unsigned int i;

	for (i = 0; i < something_that_is_unsigned; i++)
		do_something1();
}
else
(Continue reading)

Permalink | Reply |
headers
Robert Bradshaw | 8 Dec 22:19
Favicon

Re: req - block-local variables

On Dec 8, 2007, at 12:07 PM, Sven Berkvens-Matthijsse wrote:

>> On Sat, 2007-12-08 at 10:03 +0100, Stefan Behnel wrote:
>>> David McNab wrote:
>>>> I'm wishing for the ability to declare cdef vars within blocks
>>>> whose scope is confined to the block, just like in C - no
>>>> 'leaking out'.
>>>
>>> That would be mainly of syntactical interest. While I understand
>>> that it would be nice for readability to declare a name only in
>>> the scope where it is supposed to be used, you would likely not
>>> gain much performance-wise, as C compilers are pretty good in
>>> figuring out the 'real' scope of a variable.
>
> Something that is allowed in all versions of C is declaring new
> variables at the top of a block, which can then be used only in that
> block. One could say: move the variable to the top of the function or
> method, as we've stated in the rest of this e-mail thread.
>
> But, there is a situation that can be (ab)used in C in which this
> cannot be done without some thought: it's possible to declare
> variables with the same name in different blocks that do not have the
> same type.

Good point, but I'm not sure this "feature" would be a good thing to  
bring over to Cython...

> I realize that in Python, it does not work this way (and in fact, the
> type difference is not a issue in pure Python anyway), which would
> make Pyrex/Cython less compatible with pure Python. Therefore, it
(Continue reading)

Permalink | Reply |
headers
Greg Ewing | 9 Dec 00:57
Picon
Picon
Favicon

Re: [Cython-dev] req - block-local variables

Robert Bradshaw wrote:
> On Dec 8, 2007, at 12:07 PM, Sven Berkvens-Matthijsse wrote:
> 
>>> On Sat, 2007-12-08 at 10:03 +0100, Stefan Behnel (I think) wrote:
>>>
>>> I find that with large functions, it's distracting to keep flipping
>>> between lines of code in the function and the cdef vars at the top
>>> of the function.

I would argue that if you can't fit them both on the screen
at once, your function is too big and needs breaking up.

> Variables don't have to be defined at the top of a function,  
> they just (currently) can't be defined inside blocks. This  restriction 
> could be removed (with leaking) fairly easily and would  solve this 
> issue. What are the drawbacks to doing this.
> 
> Greg, I'm cc'ing you because I'm guessing you had some reason to  
> explicitly dis-allow this. Comments?

Well, the "with leaking" is kind of a clue. Various aspects of
the code generation assume that function-local variables live for
the whole lifetime of the function call and only need to be
cleaned up at the end. Changing that would require some careful
thought, and there doesn't seem to be any strong motivation to
try.

Possibly it could be made legal to declare variables anywhere
in the function, but still have them all at function scope.
But that might be confusing to people expecting them to be
(Continue reading)

Permalink | Reply |
headers
Robert Bradshaw | 9 Dec 11:39
Favicon

Re: req - block-local variables

On Dec 8, 2007, at 3:57 PM, Greg Ewing wrote:

> Robert Bradshaw wrote:
>> On Dec 8, 2007, at 12:07 PM, Sven Berkvens-Matthijsse wrote:
>>>> On Sat, 2007-12-08 at 10:03 +0100, Stefan Behnel (I think) wrote:
>>>>
>>>> I find that with large functions, it's distracting to keep flipping
>>>> between lines of code in the function and the cdef vars at the top
>>>> of the function.
>
> I would argue that if you can't fit them both on the screen
> at once, your function is too big and needs breaking up.

:-) I think this is true most of the time, but not always. Even so,  
I'm a fan of keeping things as local as possible. If one doesn't need  
a variable until halfway down the function (or only within a single  
if block) I'd rather declare it there than further up.

>> Variables don't have to be defined at the top of a function,  they  
>> just (currently) can't be defined inside blocks. This  restriction  
>> could be removed (with leaking) fairly easily and would  solve  
>> this issue. What are the drawbacks to doing this.
>> Greg, I'm cc'ing you because I'm guessing you had some reason to   
>> explicitly dis-allow this. Comments?
>
> Well, the "with leaking" is kind of a clue. Various aspects of
> the code generation assume that function-local variables live for
> the whole lifetime of the function call and only need to be
> cleaned up at the end. Changing that would require some careful
> thought, and there doesn't seem to be any strong motivation to
(Continue reading)

Permalink | Reply |
headers
Stefan Behnel | 9 Dec 09:30
Picon
Favicon

Re: [Pyrex] req - block-local variables

Hi,

just making sure that a) this gets forwarded to the Cython list and b) the
quote below doesn't stick with me. A function that requires scrolling to
understand it definitely *is* too long.

Stefan

Greg Ewing wrote:
> Robert Bradshaw wrote:
>> On Dec 8, 2007, at 12:07 PM, Sven Berkvens-Matthijsse wrote:
>>
>>>> On Sat, 2007-12-08 at 10:03 +0100, Stefan Behnel (I think) wrote:
>>>>
>>>> I find that with large functions, it's distracting to keep flipping
>>>> between lines of code in the function and the cdef vars at the top
>>>> of the function.
> 
> I would argue that if you can't fit them both on the screen
> at once, your function is too big and needs breaking up.
> 
>> Variables don't have to be defined at the top of a function,  
>> they just (currently) can't be defined inside blocks. This  restriction 
>> could be removed (with leaking) fairly easily and would  solve this 
>> issue. What are the drawbacks to doing this.
>>
>> Greg, I'm cc'ing you because I'm guessing you had some reason to  
>> explicitly dis-allow this. Comments?
> 
> Well, the "with leaking" is kind of a clue. Various aspects of
(Continue reading)

Permalink | Reply |
headers
David McNab | 8 Dec 22:46
Picon
Favicon

Re: req - block-local variables

On Sat, 2007-12-08 at 13:19 -0800, Robert Bradshaw wrote:
> I agree. Variables don't have to be defined at the top of a function,  
> they just (currently) can't be defined inside blocks. This  
> restriction could be removed (with leaking) fairly easily and would  
> solve this issue. What are the drawbacks to doing this.

I personally would be happy with a compromise solution, whereby cdef
vars declared inside a block 'leak out' to the top of the
function/method.

It would possibly not be difficult to allow variables of the same name
to be declared within different blocks, as long as they are of the same
type.

Might be wise for the compiler to generate C code to zero out the
variable at the top of each block where that variable gets declared.

All this would require scope checks such that any attempts to access
block-local variables from outside of the block get picked up by the
compiler.

Cheers
David
Permalink | Reply |
headers
Robert Bradshaw | 8 Dec 22:52
Favicon

Re: req - block-local variables

On Dec 8, 2007, at 1:46 PM, David McNab wrote:

> On Sat, 2007-12-08 at 13:19 -0800, Robert Bradshaw wrote:
>> I agree. Variables don't have to be defined at the top of a function,
>> they just (currently) can't be defined inside blocks. This
>> restriction could be removed (with leaking) fairly easily and would
>> solve this issue. What are the drawbacks to doing this.
>
> I personally would be happy with a compromise solution, whereby cdef
> vars declared inside a block 'leak out' to the top of the
> function/method.
>
> It would possibly not be difficult to allow variables of the same name
> to be declared within different blocks, as long as they are of the  
> same
> type.
>
> Might be wise for the compiler to generate C code to zero out the
> variable at the top of each block where that variable gets declared.
>
> All this would require scope checks such that any attempts to access
> block-local variables from outside of the block get picked up by the
> compiler.

Allowing block-level scopes would require a massive change to the  
Pyrex scoping code. I think it would be confusing too--there is no  
such thing as a "block-level" scope in Python (just global, class,  
and function level scopes).

- Robert
(Continue reading)

Permalink | Reply |

Gmane