*I have been playing on other languages sometimes and I see some features that speed-up a lot the code creating. I'm posting here one, I want to see what you think about it.
*
*Good:* fast algorithm testings, code creating
*Bad?:* not a standard of the pascal language

/*method* MyMethod;
*var* A, B: Integer;
*begin
*
{ Simple sample of a variable inside the method begin/end near to a
for-loop }
*var* I: Integer;
*for* I := a *to* b *do*...

{ Or even }
*for* *var* J: Integer := a *to* b *do*...
{ This is normal on languages like C++ and Java }

/*/end;/
*
*What do you think about*?

Am Tue, 10 May 2011 13:26:59 -0300
schrieb "" :

*Good:* fast algorithm testings, code creating *Bad?:* not a standard of the pascal language

Thats a bad idea. It is completely against the basic structure of pascal. Other Languages have other paradigms.

For example C++. There is no distinction between declaration and statement in C++.
The declaration is a statement. But not so in pascal.

If you change this, it is all about to be changed and you get a C++ with pascal-reserved words. Thats ugly.

Thats useless.

Best regards
Jörg

2011/5/10 :

To speed up code creation, use an IDE:
http://wiki.lazarus.freepascal.org/Lazarus_IDE_Tools#Variable_Declaration_Completion

Vincent

Am Tue, 10 May 2011 23:50:29 +0200
schrieb Hans-Peter Diettrich :

The syntax would look like: Block = "BEGIN" [Declarations] {Statement} "END" .

Yea, it looks like C, but it is not. The difference in C like languages is that an declaration is just a kind of statement. Without this, I think it makes no sense. But then you code C-like with pascal keywords.

Jörg

This already help, but what about declaring also after some code?

I like on Java/C++/PHP that I can create a for-loop that creates the counter... sample on PHP:

for(var; condition; step) for($var=0; $var<1000; $var += 1)

This syntaxe is possible on C++, Java (its not equal, but its something very close).

I would like to be able this:
[ some code after begin ]
DoSomething;
var I: Integer;
for I := 0 to 1000 do
DoAnotherThing(I);
[ inside the code ]

I don't see any disadvantage writting a code with /C-like with pascal keywords/, shortcuts are always welcome in order to code faster (also this is the objective of the High-Level Languages, isn't?). I like Pascal and I don't see why to resist against some improvements, the language gets richer and easier. Some small details can also increase the community.

Lets see the OOP, its very helpful and speedup a lot the work and has been added to the Pascal. Same for generics.

Am Tue, 10 May 2011 18:41:35 -0300
schrieb "" :

To decide that a declaration is a statement and can occur everywhere where a statement is required, is not that small you think. This has many consequences, influencing the whole code generation process.

Think about exceptions and stack rewinding.

Think about efficiency of code generating, for many developers a reason for developing in pascal.

Jörg

This could be made compatible with the FPC handling of Body, where e.g. a program or a procedure body is a Body, parsed by tcgprocinfo.parse_body().

The only required parser modification had to treat a For statement as a Body, with an (optional) specialized Var section at its begin, and a Statement after Do.

But this solution would look strange to C coders, which expect variable declarations *after* the begin of an block, while Pascal expects local variables declared *before* the begin of an block. OTOH I don't think that it would be a big deal to allow for Pascal declarations also at the begin of an block. The syntax would look like:

Block = "BEGIN" [Declarations] {Statement} "END" .

DoDi

You mean, just like try/finally blocks? ;)

FWIW, a declaration is not a statement here:

Swap_And_Ignore_Exceptions :
declare
    Temp : Integer;
begin
    Temp := X;
    X := Y;
    Y := Temp;
exception
    when others =>
       null;
end;

Ada compilers can happily handle that since the mid-80s, so I don't see why doing it a quarter of a century later would suddenly be a problem. Apart from that I don't want to see it in Pascal, as it does not make sense there unless you go down the whole way...

Vinzent.

Am Tue, 10 May 2011 18:41:35 -0300
schrieb "" :

Lets see the OOP, its very helpful and speedup a lot the work and has been added to the Pascal. Same for generics.

OOP is an concept. Nobody would say that it would not be helpful if pascal has templates -an other very helpful concept-.

Nobody would say that it is not helpful if somebody implements multi inherited objects for pascal.

The reason for C++ to say a declaration is a statement is coding security. An uninitialized variable is in an undefined state, that`s why the declaration is suspended up to the time you can initialize the data and bring it to a defined state.

The reasons for pascal not doing this:
- overview is better if you have all var declarations together
- the compiling process is easier if all vars are together.

The reason to change the pascal behavior would not be to have a feature add-on, but a thinking in the same direction like C++, what can we do to make it possible that the compiler helps more in fulfilling assertions about variables and objects during their life time.

Sorry the bad English, it is difficult to write about concepts without enough words.

By the way I am not a fpc developer, what I write is my own opinion, not the one of the fpc team.

Jörg

Joerg Schuelke wrote

Nobody would say that it is not helpful if somebody implements multi inherited objects for pascal.

I would. FPC already has interfaces.

There are good reasons why most languages didn't adopt the C++-way of doing MI.

Vinzent.

Am Wed, 11 May 2011 00:23:13 +0200
schrieb Vinzent Höfler :

I would. FPC already has interfaces. There are good reasons why most languages didn't adopt the C++-way of doing MI.

I think we have two concepts

- inheritance
- interface

You can decide for one ore the other, or possibly mix them.

It is a matter of design. Or a matter of capability to implement the concept.

Jörg

In our previous episode, Joerg Schuelke said:

The reason for C++ to say a declaration is a statement is coding security.

I always thought the main reason was because C did it that way, and C++ is C backwards compat.

And C did it because it wanted to save stack space in the minis of the early seventies. The rest is IMHO revisionism.

Am Wed, 11 May 2011 09:30:21 +0200 (CEST)
schrieb (Marco van de Voort):

Ok, not the reason. But coding security is the reason, you should do so, if you can. reason for pascal not to do so,
is what follows from that, a really complicated stack unwinding, for example.

Marco van de Voort wrote

And C did it because it wanted to save stack space in the minis of the early seventies.

Independently from the location a local variable has been declared, the compiler can decide in what section of the code it reserves stack place for it. IMHO the reason is reusing the variable name, which in C can be essential with complex macro declarations. You can reintroduce any variable name in a {-} block without harming the variable with the same name declared outside and used before and after the block .

-Michael

Am Wed, 11 May 2011 09:30:21 +0200 (CEST)
schrieb (Marco van de Voort):

In our previous episode, Joerg Schuelke said: > The reason for C++ to say a declaration is a statement is coding > security.

But all that was not the question, implementing the desired feature is in my eyes a further feature collecting. Language is design too, and implementing concepts rather then features. Without discussion where implementing a feature will led to in the future.

Regards
Jörg

In our previous episode, Joerg Schuelke said:

I've no idea what you mean by that. The need for this in C++ is a heavy use of the RAII paradigm. FPC is much lighter on that, and never runs constructors automatically. It only initializes some pointer values to NIL.

So you'll have to explain that remark in more detail.

Am Wed, 11 May 2011 10:21:45 +0200 (CEST)
schrieb (Marco van de Voort):

Yes, today.

What I mean is that one decision leads to an other.

1. You decide it is nice to declare variables where you need them.

2. You find out that it is better practice to define every variable where you can initialize it, so that every var fulfills the assertions from her type, during the live time .

3. You think about that, and invent standard constructors and destructors.

4. You`ll end with something which looks like C++ with pascal keywords.

Development should not go from a feature to the design. The design should give you the features, which fit in it.

Jörg

That's not good practice, in no programming language.

Better move the loop into a local procedure, where you can declare really local variables.

DoDi

Joerg Schuelke wrote

1. You decide it is nice to declare variables where you need them.

Readability problems might arise regarding the scope of equally named variables. Pascal ovoid much of this.

-Michael

Not really. C allows for variable declarations outside blocks, too, as Pascal does. Otherwise a declaration list is accepted only at the *begin* of a compound statement, not inside a statement list:

compound_stat: '{' [decl_list] [stat_list] '}' ;

DoDi

NACK

Everthing should be expressable in only one way, so that standard patterns can be recognized easily when reading some code. Even if you can #define "begin" and "end" in C, and use it instead of "{" and "}", the resulting code will be unreadable.

It's a very bad idea to "think C, write Pascal", because such a translation will fail for any number of subtle differences between C and Pascal.

DoDi

Right, but a compiler can allocate local variables as appropriate. E.g. managed variables can go into the main variable block, while unmanaged variables can be overlaid.

Think about efficiency of code generating, for many developers a reason for developing in pascal.

Think of JIT compilers, that generate code on the fly, in no noticeable time.

DoDi

Ok, not the reason. But coding security is the reason, you should do so, if you can. reason for pascal not to do so, is what follows from that, a really complicated stack unwinding, for example.

Stack unwinding is not an argument, IMO. C++ and OPL have managed data types, that require proper stack unwinding. But there is no requirement that stack unwinding has to recurse down into local code blocks, since the compiler is free to collect all managed variables into one memory block.

The use of local variables at block level has other consequences:
+ every loop could use "i" for the loop variable
- the user (or IDE) has to figure out the declaration of every "i"

DoDi

IMHO the reason is reusing the variable name, which in C can be essential with complex macro declarations. You can reintroduce any variable name in a {-} block without harming the variable with the same name declared outside and used before and after the block .

ACK.

As the downside a macro can use variables without declarations, so that the coder is responsible for providing according declarations for every such macro expansion. That's also a frequently used feature, that can make C code even more unreadable.

As a midway variables can be passed to C macros, by name, what increases the compile time considerably. FPC macros don't have parameters, for this and other reasons. That's not a hard restriction, because inline procedures can be used instead, in many cases.

DoDi

As Vinzent mentioned, the C++ model of multiple inheritance turned out to be a misfeature. I see no reason for repeating that experiment any more. Similarly Templates and Generics - generics IMO don't suffer from some problems, that turned out after the introduction of templates.

DoDi

Am Wed, 11 May 2011 12:26:09 +0200
schrieb Michael Schnell :

Readability problems might arise regarding the scope of equally named variables. Pascal ovoid much of this.

I agree,

and somebody will then come and suggest:

Lets do it this way.

var a:integer;
begin
  some code using a;
    var a:integer;
    begin
      some code using the inner a;
    end;
  some code using the outer a;
end;

and we are one step closer to C++ with pascal keywords. OK, it could be done. But should it?, I think not.

Jörg

Hans-Peter Diettrich wrote

As the downside a macro can use variables without declarations, so that the coder is responsible for providing according declarations for every such macro expansion.

You need to be very silly to do this :-) .

-Michael

and what about "think Pascal write C" ? Is this not Java GDR :-P .

-Michael

Am Wed, 11 May 2011 13:12:22 +0200
schrieb Hans-Peter Diettrich :

FPC macros don't have parameters, for this and other reasons. That's not a hard restriction, because inline procedures can be used instead, in many cases.

Hmmm, I think about macros for pascal with parameters for some time, and ask you now: where is the debugging macro used inside the whole compiler sources? Nowhere, because it is nearly impossible to write some really useful.
The parameters are not the problem. If you
introduce a macro expansion like:

{$I %macro_name(macro_parametertext)}

the preprocessor knows it is a macro expansion and there is no need to check every identifier.

Am Wed, 11 May 2011 12:28:29 +0200
schrieb Hans-Peter Diettrich :

Otherwise a declaration list is accepted only at the *begin* of a compound statement, not inside a statement list: compound_stat: '{' [decl_list] [stat_list] '}' ;

I thought that <statement> = <decl_statement> | ...

And only the kind of <decl_statement> which is allowed is restricted in some contexts. Is it defining or only declaring.

Only declaring <dec_statements> are restricted to the beginning of the compound statement, but also defining <dec_statements> are allowed.

Jörg

I think the answer is rather "nowhere, because the developers don't have a need for them". I can't remember ever thinking "I wish I could do this with macro support, but unfortunately that's not possible so I have to do it in another and less convenient way" while working on the compiler. This obviously doesn't mean that there are no cases where other people may consider macro support to be quite handy, but I'm personally not missing anything as far as compiler development is concerned.

Jonas

Am Wed, 11 May 2011 14:52:13 +0200
schrieb Jonas Maebe :

but I'm personally not missing anything as far as compiler development is concerned.

You use an IDE? But what without? The language is the one and the IDE is the other. There are plenty of users who do not use an IDE, or not all the time the same.
Jörg

I don't use any kind of automatic code generation/writing functionality of any IDE or editor (and I edit the FPC compiler sources with Lazarus, Text Wrangler, vim and nano depending on what I'm doing or how I'm logged in). At least I guess that's what your reply is referring to, because otherwise I'm not sure how it's related to your earlier statement of "where is the debugging macro used inside the whole compiler sources?"

Jonas

Jonas Maebe wrote

I wish I could do this with macro support, but unfortunately that's not possible so I have to do it in another and less convenient way" while working on the compiler.

Some of the stuff that in ANSI C needs to (and can) be done with macros can be done with Generics. Of course C macros are exceptionally powerful, but they are really hard to use when it comes to a higher level of complexity.

-Michael

Am Wed, 11 May 2011 15:08:45 +0200
schrieb Jonas Maebe :

Sorry Jonas,
thats my bad English. Some days ago I had a macro related question. About the expansion of build-in macros. And it turned out that macro is some kind of step child.
The answer I got was use IDE-macros instead.

Would not it be helpful to leave the debugging code in the source, and let him vanish through a conditional define?

W dniu 2011-05-11 11:39, Joerg Schuelke pisze:

I agree, but in different way. I'd like see pascal more declarative than imperative, and not make statement from declaration. Initialization connected with declaration looks good and we can move then to the declaration section. For example

procedure foo;
var
   t : tMyObject();
begin
   t.myProc;
end;

that can be equivalent to:

procedure foo;
var
   t : tMyObject;
begin
   t:=tMyObject.create();
   try
     t.myProc;
   finally
     t.free;
   end;
end;

This proposition is not only shorter, more security and possible to achieve. There are some things with similar behavior like interfaces, strings: they are initialize before <begin> statement and finalize after <end>. Also some gain of speed can be achieve: this object can be allocate on stack, which is faster. And second: some virtual calls can be resolved and inlining.

Joerg Schuelke wrote

Would not it be helpful to leave the debugging code in the source, and let him vanish through a conditional define?

The compiler has such code, between {$ifdef EXTDEBUG}. Having full- fledged macro support would not really make most of that code simpler, because there are few if any general patterns that appear in many places (and such patterns, at least those in the compiler, could just as easily be isolated into functions if refactoring were required).

Furthermore, most debugging code is always enabled because it's much easier for a user to figure out that something is wrong when the compiler halts with "internalerror 89" instead of silently generating wrong code.

Note: again, I'm only talking about the compiler sources.

Jonas

Jonas Maebe wrote

but I'm personally not missing anything as far as compiler development is concerned.

Me neither. And if I really need output during compilation, I add the needed code manually like

printnode(self);

to get a node tree at a particular place. Having this in macros everywhere makes imo no sense because one would gets an incredible amount of data.

Am Wed, 11 May 2011 16:56:38 +0200
schrieb Florian Klaempfl :

to get a node tree at a particular place. Having this in macros everywhere makes imo no sense because one would gets an incredible amount of data.

OK, to make it concrete, I refer to an level driven debug system commonly used for example in the kernel sources. Lower level messages at procedure entry point, higher level output for complicated stuff.

Switched by DBGLEV:=3 for example. Programming in C I usually have a
stack of debug levels, so I can for example code:
DBGPUSH(4);
  call to whatever;
DBGPOP;

and all that stuff vanishes with -dNODEBUG.

For the compiler itself such things are toggled via command line switches (-vc, -vt, -vu, -vd, -vp, ...).

Jonas

Am Wed, 11 May 2011 17:56:39 +0200
schrieb Jonas Maebe :

For the compiler itself such things are toggled via command line switches (-vc, -vt, -vu, -vd, -vp, ...).

That must be some kind of misunderstanding I know the compiler switches, I spoke about runtime debugging informations, not compile time. And most of the switches generate compile time ones. Am I wrong?

By the way it is not my interest to convince somebody, what he should better do :-)

A little may be. Sorry for that, but in my ears it sounds a little like "I do not need, what I could not have". Sorry again.

Enough about the dirty macros, the point introduced by kingbizugo was to introduce vars in code.

Regards
Jörg

Am Wed, 11 May 2011 19:11:40 +0200
schrieb Hans-Peter Diettrich :

Since that time I don't wonder any more, why a C compiler spends 50% of its time in scanning (and preprocessing) the input.

I would introduce a macro expansion trough a compiler directive. Then there is no need to scan the whole program for macro occurrencies. You "only" have to preprocess the including directive and the macro body.

Doing {$I %macro(p1,p2,..)} instead of simple macro(p1,p2,..) helps much.

It is a clean way, and pascal like. (in my eyes)

Jörg

I'd love that, not for the coding speed argument, but for the maintenance argument: reducing escope thus reducing chances of error. But what I'd like the most is a compilation mode where parameters (or even local variables) are 'const' (or write-once) by default :-) Enforcing explicit declaration of every field, class or global used in a function would be nice too ;-)
But please don't tell to use ADA or the new RedHat language :-D

Best regards,
Flávio

They are :-(

I came across all those nasty problems, when I wrote the preprocessor for ToPas. Since that time I don't wonder any more, why a C compiler spends 50% of its time in scanning (and preprocessing) the input.

DoDi

Or make the loop variable completely implicit and thus 100% local to the loop.

|for i : integer := 0 to 1000 do ...;

Vinzent.

In our previous episode, Joerg Schuelke said:

That must be some kind of misunderstanding I know the compiler switches, I spoke about runtime debugging informations, not compile time. And most of the switches generate compile time ones. Am I wrong?

Well, that's the fun of compiler bootstrapping, it is both at the same time.

I like this idea, but I'm changing my mind,*maybe is better to keep the current way*, its not really needed to declare a variable inside the codes, its nice, I like it but its not really necessary.

But something that has been pointed (by Joerg I belive) is the initialization of variables, what about it? This would be a nice thing and I don't see why not. I prefer to see:

*var

    X: Integer = 0;
    Y: Integer = 100;*

than

*var
   X: Integer;
   Y: Integer;
begin
   X := 0;
   Y := 100;*

This is already supported (and least in Delphi and ObjFPC modes, I'm not sure about the other ones).

Jonas

Joerg Schuelke wrote

I would introduce a macro expansion trough a compiler directive.

What a bout a compiler directive to optionally call the gnu C preprocessor ? I would have wanted used this some time ago for a very special project.

-Michael

You cannot use cpp, because it cannot deal with Pascal comments (as a result it sometimes interprets text inside Pascal comments as the start of a C-style comment, and removes all of the source code coming after it).

gpc -E works better, but
a) it adds "# 1 file.xxx" pseudo-statements that indicate which source file starts at that point (cpp inserts the same ones, so using that one instead would not help)
b) it inlines the constents of {$include xxx} statements (so the compiler-inserted debug information would no longer be correct, unless you teach it to parse those "# 1 file.xxx" statements), and furthermore also leaves the original {$include xxx} statement in the source (so the compiler would process it twice)

I don't think it would be a problem to add support for calling an external preprocessor if someone would write one though.

Jonas

Am Thu, 12 May 2011 09:32:28 +0200
schrieb Michael Schnell :

What a bout a compiler directive to optionally call the gnu C preprocessor ? I would have wanted used this some time ago for a very special project.

Thats a merrily idea: This would mean writing macro definitions to a temporary file and then calling the C preprocessor to process them and then including the result.

As a joy, OK, sounds good.

Jörg

Jonas Maebe wrote

b) it inlines the constents of {$include xxx} statements (so the compiler-inserted debug information would no longer be correct

This is actually a general problem with preprocessed source files: the line information inserted by the compiler will almost certainly no longer correspond to the original source, but to the preprocessed source instead (unless support is added for some kind of line directives, but that's a whole other thing that just supporting calling an external program to preprocess sources).

Jonas

Good reasons to avoid preprocessor support in the compiler. Anyone needing it can perfectly do this manually with makefiles and e.g. m4. Lazarus has support for it as well, so this should not stop anyone.

I prefer a smaller "mean and lean" compiler to a "bloatware and slow" compiler.

One day, we'll end up adding email support to the compiler.

Michael.

What a bout a compiler directive to optionally call the gnu C preprocessor ? I would have wanted used this some time ago for a very special project.

IMO you can do that with build macros. But note that you'll have to use the C macro syntax (#define...), for such stuff.

You also can use the preprocessor of ToPas, to preprocess source files, optionally with your own macro syntax - if you implement it.

DoDi

Am Thu, 12 May 2011 09:32:28 +0200
schrieb Michael Schnell :

> I would introduce a macro expansion trough a compiler directive. What a bout a compiler directive to optionally call the gnu C preprocessor ? I would have wanted used this some time ago for a very special project.

Yesterday I thought this would be jocular, today, that I misunderstood your suggestion. If it is for some circumstances not possible to have the preprocessor integrated in the compiler this is an possibility to do automatic preprocessing.

I thought of preprocessing the definitions and expansions of macros by compiler switches yesterday and thats why my answer.

If you call a preprocessor as an hook of the compiler by compiler directive then including the result in the usual way, you only have to get rid of the rest of the source file, I mean the original one which is processed by the compiler right bevor preprocessor hook call.

This sounds not that ridiculous.

It would be the second chance if it is impossible to incorporate an preprocessor in the compiler. But,..., there is so much work done twice this way, the whole scanning process is doubled..., that would be a pity.

Regards
Jörg