Can variables be declared within a begin end block?
eg.
if y = xxx then
begin
  var xxx;
  var yyy;
end

There are there as shortnames for long expressions

Frank Church wrote

Can variables be declared within a begin end block?

No.

Michael.

On Thu, Oct 14, 2010 at 11:21 AM, Michael Van Canneyt <

That found in Gnu Pascal
Can we ask to be feature request?

Thanks

No.

That is a rather emphatic no :).
Is there some performance or other related reason why it is a bad idea? I'm not knowledgeable in this area but I'd like to know.

Sometimes my variable declarations is filled with lots of variables for the sake of making code involving long derived expressions comprehensible and the clutter the understanding at the top level of the procedure.

Can a procedure be declared inline just for the sake of introducing those variables?

Frank Church wrote

On 18 October 2010 07:49, Florian Klaempfl wrote:

[...]

I guess it has something to do with 'functions/procedures not to be longer than 3 editor screens' and 'if it is longer and has more responsibilities than the name implies, do split it up' kind of paradigm. c(-like) languages are very bad (don't keep you restrained) at this kind of use ;) and Gnu Pascal is a mere frontend to GCC so it may inherit c-isms ;)

Having variables declared within code block used to require to parse the source code at least 2 times as opposed to nice Pascal way of doing it ONCE only. This was a compiler performance winner in the times of ancient 286, 386 ;) (dug out from depths of my memory, may be outdated badly).

L.

It's just a matter of readability, e.g. having a variable declared in two blocks with the same name can cause you a lot of headache:

procedure p;

begin
...

  begin
    var i : integer;
    ...
    ...
    ...
    i:=12341234;
    ...
    ...
    ...
    ...
  end;
  ...
  ...
  ...
  begin
    var i : integer;
    ...
    writeln(i); <--- this i is not the same as above so i does not

contain 12341234 but it contains probably some garbage.

  end;

Lukasz Sokol wrote

Having variables declared within code block used to require to parse the source code at least 2 times

Or create them on the stack at the begin and remove them at the end of the block (which would be the only way to have some additional functionality through this).

Bernd

My need is not for such kind or variables - it is for something like this.

say I have some thing like:
StringList.NameOfIndex(TableName.FieldByName('xxxx').AsString) > AnotherEqualLongExpression + SomeOtherEvenLongerExpression.

I just want to create shorter variables like
si :=  StringList.NameOfIndex(TableName.FieldByName('xxxx').AsString);
ae := xxx;
so:= yyy

to express complicated logic with them.

When I put them all at the top of the procedure, they are extra noise, which is not necessary for the understanding the purpose at the top level of the procedure.

I understand the need to avoid stuff that could create unintended errors and have experienced such issues before. I will be careful not to use the more than enough rope I have been given to hang myself. I promise :)

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

I sometimes use nested procedures for such purposes when it comes to the program logic itself, having something like that for variables would be nice.

PS. The promise above should be "we promise" :)

Maybe the usage of WITH could be helpful in some of these cases

Bernd

Frank Church wrote

I understand the need to avoid stuff that could create unintended errors

It would create something that I would call "irregularity" (or even ugliness) in the language grammar. Nowhere else is it ever allowed to have certain things inside a begin/end block, type, const, var are all only allowed in the *same* certain places outside of such blocks. Allowing var would also raise the question why not also allow type and const and this would open a can of worms. It would destroy some (much) of the simplicity (regularity, strictness, beauty, I don't know a better word) of the grammar.

Bernd

My thoughts exactly.

Object Pascal is a simple, beautiful and easy to read language. The FPC team tries to keep it that way.

If someone needs convincing that this is actually a plus: go and (try to) read and understand any moderately complicated perl program. Latex2html is a nice start :-)

Michael.

I don't see the great extra noise of a

procedure SomeProc([someVars : Type]);
var
  [somevars : type;]
  si,ae,so : double; // temp vars for easy math;
begin
  [...]
end;

and i think the easy answer is:

No you could't, because in pascal you have to declare the vars in the beginning of a procedure.

or:

No because this is pascal and not C

or:

why couldn't i use spanish in my english? :) *just kidding*

have all a nice day.

Michael Van Canneyt wrote

Object Pascal is a simple, beautiful and easy to read language. The FPC team tries to keep it that way.

And that is why I like the FPC team so much. :D

Regards,
Sven

On Mon, 18 Oct 2010 15:42:31 +0200, Florian Klaempfl wrote about Re: [fpc-pascal] Can variables be declared within a block?:

[snip]

This was not usually a problem in ALGOL 60/68, PL/I or C/C++ -- these languages have supported short scopes for up to 50 years -- as the programmer was required to be aware of the different scopes of the like-named variables.

I still use short scoped variables today, usually in C or C++. I have never had any such problems, even going back almost 40 years when I programmed in ALGOL 60. All block structured languages require the programmer to understand the scope of all variables.

Indeed, short scopes can often circumvent name collisions, e.g.

long some_func(unsigned long arg_1)
{
long i; /* procedure/function scoped */

    unsigned max_iters;
    . . .
    /* calculate "i", "max_iters" and any others */
    . . .
    for (unsigned i = 0; i < max_iters; ++i) /* short scope "i" */
    {
       /* "i" here is distinct from the one at function scope. */
       . . .
    }
    . . .
    return i; /* back to procedure scoped "i". */

}

Whether it is wise to use such lax naming of variables is open to debate, but at least C and C++ allow the above.

That said, short scoping was never a part of original Pascal. I think Jensen & Wirth omitted it because it made the compiler simpler.

agreed.

When I went from C++ to Pascal back in 98/99, I found it quite hard initially. Not being able to put variables anywhere & everywhere was really awkward, but it dawned on me that I shouold be coding better. Since then, i would say "If you need vars throughout your code, then something is wrong with your code"

- V

Since then, i would say "If you need vars throughout your code, then something is wrong with your code"

for (int i = 0;...)
Can't see anything wrong. I use declaration of variables inside blocks quite often in Java and C++ but have never missed it in pascal. Please enlighten me. What is so bad about creating temporary variables inside blocks instead of the beginning of a function in a language that supports it?

R.

for (int i = 0;...) Can't see anything wrong. I use declaration of variables inside blocks quite often in Java and C++ but have never missed it in pascal. Please enlighten me. What is so bad about creating temporary variables inside blocks instead of the beginning of a function in a language that supports it? R.

But it should make you wonder why this is no longer allowed in the latest C++ standards.

On Mon, 18 Oct 2010 19:46:04 -0200, Andreas Berger wrote about Re: [fpc-pascal] Can variables be declared within a block?:

What do you mean?

The current C++ standard (ISO 1998+TR1) permits short scope declarations. Indeed, C++ permits declarations to appear anywhere, not just after a { to open a function or compound statement. It has done since the A.R.M. days, and in some implementations before that.

You are correct. Been a while since I programmed in C++. The new standard enforces that the short scope variable declared in a for loop goes out of scope at the end of the loop. Older implementations did not always enforce this. My bad.

or do the same as with that vb-ism: the 'with' keyword. Only difference(s): it is named/typed and it is block-scoped from the point of declaration to the end of the current block statement. (I never use it, so I'm only guessing that it does something similar to the scenario explained above)

on the other hand, what stops the OP from using 'with'? (multiple levels/variables?)

and you won't die from using another stack variable scoped at the beginning of the method.

just to say that I'm not too fond of that c-ism in a pascal language (although I've used it plenty in c++, java, C#, php, ... over the years).

kind regards,
Dimitri Smits

Florian Klaempfl wrote

Am 18.10.2010 14:58, schrieb Frank Church: It's just a matter of readability, e.g. having a variable declared in two blocks with the same name can cause you a lot of headache:

So don't allow identical names.

Ada allows exactly this feature (declaration within a block) and it is extremely simple and not the least confusing. It's also an easy and error-free way to manage dynamic memory allocation without using pointers.

Jerry

for (int i = 0;...) Can't see anything wrong. I use declaration of variables inside blocks quite often in Java and C++ but have never missed it in pascal. Please enlighten me. What is so bad about creating temporary variables inside blocks instead of the beginning of a function in a language that supports it?

I never thought about doing such declarations in Pascal. Although I would not be against it in general (provided that all identifiers have to be different) I see one (small) disadvantage:

If you want to know the number of bytes pushed to the stack (i.e. in a recursive function) then you don't have the declarations at one place anymore but they are spread over the code which would make it hard to get an overview.

Makes you wonder why the ReactOS devs always declare their variables at the beginning of the functions (they're using C). :P Take a look at the source files of ntoskrnl for example.

Regards,
Sven

On Tue, Oct 19, 2010 at 12:23 AM, Jürgen Hestermann <

That seems like an arbitrary restriction, given that Object Pascal *already* allows multiple variables to have the same name *and* be declared somewhere other than the top of the function. Think of exception handlers. I don't know about everyone else, but my exception variables are all always named e.

I could understand disallowing variables from *shadowing* other local variables of the same name (it's legal in C, but better compilers warn about it), but I see no reason for the language to require variables from different local scopes to have unique names. Write that into your local coding guidelines and enforce it in code reviews, not the language spec.

Definitely small. It's already hard to do since you don't know how much stack the compiler will allocate for temporary variables. (If the function's small enough that you *can* predict the compiler's temporary usage, then it's probably also small enough that you can count all the variable declarations no matter where they appear.)

Dimitri Smits wrote

on the other hand, what stops the OP from using 'with'? (multiple levels/variables?)

"with" contaminates the name space. Locally scoped variables don't.

and you won't die from using another stack variable scoped at the beginning of the method.

True. If the subroutine is long enough that an additional declaration block seems necessary, it's probably too long already.

just to say that I'm not too fond of that c-ism in a pascal language (although I've used it plenty in c++, java, C#, php, ... over the years).

Just because C has it doesn't mean it is a C-ism. Local declaration blocks are definitely not an invention of C. IIRC, C89/90 didn't even had it yet.

Vinzent.

On 19 October 2010 15:06, Rob Kennedy
<

your example is at the start of a "for loop" block, which is much the same as having it at the start of a procedure block

pascal prevents people from putting declarations strewn throughout the block, which i found reduces mistakes & bugs from 20-30 people coding, and their code is more readable. Coding standards are do similar thing.

which of the three languages do you find fastest to code in, including any debugging time?

are you sure? i've tried making var's in WITh and Try Except blocks using Delphi7 with no luck. Or is this a difference between object pascal & delphi?

i'd agree with that, local vars are local after all. perhaps make it a compiler option.

- V

your example is at the start of a "for loop" block, which is much the same as having it at the start of a procedure block

So much the same that you can do it in pascal?
What about variables declared inside this for loop or inside the else block of an if statement.

pascal prevents people from putting declarations strewn throughout the block, which i found reduces mistakes & bugs from 20-30 people coding, and their code is more readable. Coding standards are do similar thing.

You were talking about wrong code, not more readable code (which is very subjective in this case). So it looks like there is nothing wrong using this feature if it is available as you failed to show me that there is a problem. But it does not make much sense to discuss this here any further as it is not available in FPC.

R.

Write that into your local coding guidelines and enforce it in code reviews, not the language spec.

This argument can be used to promote each and every change, no matter how obscure it is. But you forget that you may be forced to read code from other people in which case you are suddenly confronted with such weird constructs. Then it does not help that you had guidelines for your own code. I fail to see this as a relevant argument.

As I see it, Pascals success was just the simple (still powerful) syntax and semantic. I would not like that this is given up by following trends and making Pascal the same thicket as C. And for what reason? Just to save a little typing? I can't see how this outwheighs the disadvantage of obscuring the code.

This argument can be used to promote each and every change, no matter how

obscure it is.

Agreed. I'm currently working on a PHP project which is coded badly, no separation between logic and presentation, no database query abstraction, many html tags embedded as PHP strings, etc. This is an example of a language that have good coding guidelines (a framework that I use follows it nicely) but allows bad coding style.

OTOH, almost all Pascal based projects/units/libraries I downloaded from internet are coded in almost the same good style, maybe some different indentation, but that could be easily remedied with Lazarus' JCF code formatting feature. Even though the author is not an advanced Pascal programmer.

So, putting this as a part of language spec is indeed necessary and a correct decision.