Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 13:01:39 +0300 schrieb ik ido...@gmail.com: Why not to create something like: *macro* Macro_Name(Param) *begin* *end*; The Pascal way ? It's more readable. But then what do you gain with that Macro ? -Doing it this way would not be acceptable by any developer, therefor tactical reason to suggest it like I did, remember even Florian wrote, he could live with that - and that is a big plus -! -The way to write it is almost only syntactical sugar (feel free to implement a concept as you like and can) -The comment parenthesis for all low level pascal behavior changing things is commonly accepted -I did not try to extend pascal - new tokens, grammar all that -The kind of writing you suggest (ironically) lets pretend a macro is like a pascal procedure, but it is not. Macro works so completely different from pascal, that it makes no clue for me, to let it look like an procedure. Last days where much rumor, so I did not find the time to answer that special question, here it is. The gains are always the same: To do some things which could not be done that easy in an other way! Lets purpose you have an idea to extend the pascal syntax and you want to check out, how it works, which problems it brings... Maybe you decide to implement it with a macro and play around with it. Then if you are ready with it you ask development: Look it works pretty as a macro, if we incorporate it (into the language) this way there will be no harm. You can have two or three different approaches this way, without even touching the compiler. But I am not that crazy, to bring that argument by myself, because this is the most common fear, to bring up the possibility to change the language and so ... Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 15:35:24 +0100
schrieb Martin f...@mfriebe.de:
{$EXPAND ProcFoo(1)}
// the code in thr try finally block
{$EXPAND ProcFooEnd}
I can see that happen very easy?
And there we are, Pascal would be down to where C is now.
There is no answer for that, you know. But you can always decide not to
accept any code inside rtl, packages,tools, whatever which contains
macros. Easy. If it compiles with warning, back to sender.
You are willing to take the risk, to get the power.
I am not willing to be exposed to the risk, so you can get the power.
= see my other mail, about them being used n 3rdparty open source,
add ons, etc = if they exist, I (and everyone) will be confronted
with them.
Discussion about that, or stated? and end of the line. Will not bore.
Want not to waste my time, too.
A point which is possibly worth thinking about:
If you have a feature request you can let them try it out,
different approaches welcome, do try it with a macro. Easier
then changing the compiler for my own playground. Generics,
fine. Templates (unit approach for generics), too.
Lets try, this way. And lets try thats way.
Easy done.
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Tue, 17 May 2011 12:59:57 +0100 schrieb Martin f...@mfriebe.de: Based on this. The question is does the benefits really outweigh the cost ? Of course not. The much writing shows there is only Hans-Peter possibly for a try. I thought that some of the reasons where only educational ;-) Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing (pre-processor)
Am Tue, 17 May 2011 13:38:35 +0100 schrieb Martin f...@mfriebe.de: Going for educational.. or theoretical... You understand, it is not even easy for someone to have a need ore a valid use for an macro, after 30 years without? Then crutch macro support that fpc has, makes that not better. It makes people preventing them, even if they could be helpful. That was meant by educational. There is another idea = which would still make some of this possible. I know. The main pitfall in my eyes is the replication of the scanner, a mass of handwritten code, which I am not willing to hold in sync. But there is a package too. Or writing a table driven. I´ll look at it. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sun, 15 May 2011 13:26:03 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Feel free to come up with examples and convince us. They need to be
examples of code that is much more awkward to write without macro's.
We extend the small enumeration example:
Think of it, as a server program with a lot of callback procedures and
associated data
procedure cb_proc1();begin ... end;
procedure cb_proc2();begin ... end;
procedure cb_proc3();begin ... end;
procedure cb_proc4();begin ... end;
procedure cb_proc5();begin ... end;
procedure cb_proc6();begin ... end;
type
callenum=(
proc1,
proc2,
proc3,
proc4,
proc5,
proc6
);
callproc=procedure();
inforec=record
id:callenum;name:string[12];address:callproc
end;
const
infoarr:array[callenum] of inforec={
{id:proc1;name:'proc1';address:@cb_proc1},
{id:proc2;name:'proc2';address:@cb_proc2},
{id:proc3;name:'proc3';address:@cb_proc3},
{id:proc4;name:'proc4';address:@cb_proc4},
{id:proc5;name:'proc5';address:@cb_proc5},
{id:proc6;name:'proc6';address:@cb_proc6}
}
What I possibly would do is:
{$Makro entry(n):={id:proc %% %n%; // concat with parameter
name:'proc' %% % %n%;// concat with str par
address:@cb_proc %% %n% // concat with parameter
}
}
used with the explicit syntax:
infoarr:array[1..6] of inforec={
{$Expand entry(1)},
{$Expand entry(2)},
{$Expand entry(3)},
{$Expand entry(4)},
{$Expand entry(5)},
{$Expand entry(6)},
}
thats nice enough if you have 57 elements in your callenum. Would you
say then, use an IDE instead of? Every time I change the inforec, which
is possibly not that seldom, I only change the macro once. Is this not
nice? Macros simply can help to keep the things together.
Again:
The point is not, to find an example, which is not doable without
macros.
The point is, to show that the concept of automated text changing is
useful.
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sun, 15 May 2011 20:06:02 +0200 schrieb Jonas Maebe jonas.ma...@elis.ugent.be: Those three ways also have data overhead, because you have to store the string representation somewhere. Whether this initialised data is part of a predefined format called RTTI or not does not change that. Good point, but sorry, this is an proof that the macro approach is more general! The RTTI feature can the data only give in one format, say it delivers them as pchar to you. And I have shortstrings in my list. The format the data is retrieved by the rtti decides how I have to store it if you want to prevent the double storage of the data. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 11:16:39 +0300 schrieb ik ido...@gmail.com: So what that I'm trying to say is that Macro in C and C++ are there as a hack to do things you can not do properly in any other way. And I can not find any real reason for using it in Pascal. An macro represents the concept of automated text changing. Nothing else!! The answer was to use a logging facility? Maybe some kind of log server, where a pascal import unit is avail? Thats really very high level for that low level problem ;-( This way you restrict the programmer! My debug system gives me what I want: - FILE info from build-in macro - FUNC info from build-in macro (patched by myself) - LINE info from build-in macro - the additional info I request And now it is time to say that a real discussion is not possible if you always say: Yeah, you should not do that! Sounds like religion for me. I remember: ** An macro represents the concept of automated text changing. Nothing else!! ** If you want to criticize it, do it. And I do that to. Did you see that your argument of macros are a hack to do things which else not can be done in C, is easily turned around? Some things you do the only-true-pascal-way are only dirty hacks, to prevent the use of an macro. Because you do not have one. For example the statement: Use a logging facility instead. If that would be true, the compiler would use one. You would use one. Everybody would use one, everytime. But no, we mess around with that writeln thing and comments. Do not say you did not, you did never. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 08:37:12 +0200 schrieb Florian Klaempfl flor...@freepascal.org: You still need to keep infoarr and callenum in sync so simple macros are only half of a solution in this case. Thats true, I hate macros too. So I did it not the hack way. It was not my object to show how you can do TeX in pascal sources, but that a macro may be useful. And it is. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 11:11:39 +0100 schrieb Martin f...@mfriebe.de: Lots of code is written n teams. ... ... Making the feature available, forces others to deal with it. Yes, I agree. But if you really doing team work, the team should find a common way of coding. Look at some piece of very big code! There are always decisions about formatting and coding too. These decisions of cause are binding for all members. Yes. If it is used. But most true-pascalian say, it would never be used, because it is useless ;-) I think it is not that tragic, the real use cases you will find in bigger projects are rare. Some better debugging, some few other things. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 13:01:39 +0300
schrieb ik ido...@gmail.com:
procedure toLog(const S : String); --
{$IFDEF DEBUG} |
|
{$ENDIF} |
end; |
|
What do you think, is my debug thing? It is this. What you write, but in
an unit and an included file, so I never have to think about again. But
approved to vanish completely.
It's not a hack but a choice to insert things to log.
I can also create something like this:
procedure toLog(debug_level : TDebugLevel; const S : String);
{$IFDEF DEBUG}
if debug_level = current_debug_level then
writeln(debug_to_str(debug_level), ' [', DateTimeToStr(now) ,']
', s); {$ENDIF}
end;
OK, this is a starting point, I think many programmers start with
something like this. After they have done writeln and commenting out a
bit.
What my debug system does, is exactly this, what your example code
does. A little more.
-You can not use the compile time information %LINE% %FILE% ... in your
procedure because they would expand to the information from your
procedure.
-You are forced this way to use run-time information
-Where go the units in the uses clause. Some writing of ifdefs? OK.
-Is the code really vanishing if you switch debug off? In this simple
example, maybe, if inlined.
-How do you retrieve the function name, line number, file name and how
do you give it to the procedure? Really Much Writing?? Not done
therefor.
A macro has the possibility to expand where used, and this way you can
circumvent the Really Much Writing. Thats all.
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 08:37:12 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
You still need to keep infoarr and callenum in sync so simple macros
are only half of a solution in this case.
If it should be done, maybe this way:
But, I have no clue about macro writing
Thats a globally used one, for all lists. Arguments are:
mac the macro which is done on every element
delimthe delimiter of the resulting list
args the macro which expands to the arguments (OK first
attempt ;-)
{$Macro dolist(mac,delim,args):=
{$Macro __tmp:={$Expand %args%}} // temp copy of args
{$Macro _dolist(mac,delim,_arg,_args..):=
{$Expand %mac%(%_arg%)} // do it on the first
{$IFNOT % %_args..%=''} // are there more
% %delim% // tokenization of delim
{$Expand _dolist(%mac%,%_args..%)} // process more
{$ENDIF}
}
{$Expand _dolist(%mac%,%delim%,{$Expand _tmp})} // ?? looks bad
} // the explicit syntax is more annoying then I thought!
It looks bad, I know but I can not think that macro way, There are
other solutions to process a list without recursion, defining macros
with new names like fac_6 fac_5 fac_4 .. and then expanding only once.
There are C programmers who knows how it works.
But if you think you have a need. It is only done once! And then never
touched again. Residing in a general used unit.
// What to do for enum and info
{$Macro en_entry(x):= proc %% %x% }
{$Macro info_entry(x):= { id:proc %% %x%;name:'proc' %% % %x%;address:@cb_proc
%% %x% }}
// The list I process
{$Macro the_list:=1,2,3,4,5,6}
callenum=(
{$Expand dolist(en_entry,',',the_list)}
);
infoarr:array[callenum]of inforec={
{$Expand dolist(info_entry,';',the_list)}
);
Be generous I really hate that macro stuff and have no clue about it.
*
What I really miss sometimes are simple parameters, doing the half of
the work which I really like to have automated, not that expanding
ones.
And correct expanding compile time informations (without the need of
rtti) too!
*
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 11:11:39 +0100
schrieb Martin f...@mfriebe.de:
2) But a macro also weakens the fundamental concept of how a language
is defined. A macro allows you do define a new syntax. To create
something, ...
I do prefer not to make it possible to extend the language, thats why
the explicit syntax:
{$Macro mac(params)} and
{$Expand mac(params)}
I think that completely encapsulates the text manipulation from the
language level.
True, if used the readability will suffer. But at least you see
that it happens (You know there is a hidden piece of whatever, thats
not that far away from looking of a procedure call and not knowing
what that function will do. If you are interested in details, look at
the source. The same with an macro).
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 14:07:54 +0100
schrieb Martin f...@mfriebe.de:
{$MyProc (Name) := procedure %Name%; begin}
...
{$Expand MyProc(Foo)} writeln(1); end;
Thats a point worth thinking about, but you say that it even can be done
today, do you think there is more harm extending the thing? Will think
about.
If the feature was really important, and would be used by many,and
make everyones live so much easier, then yes it is worth it
But if let me quote the real use cases ... are rare, then is it
still worth the risk (Even if the risk is small.
Do you remember all the writeln for debugging purposes? Hours and
hours.
They are the true reason to incorporate // comments. (a theory of me)
This may be a sign that the need would be there, if there is the
possibility.
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 14:36:29 +0100 schrieb Martin f...@mfriebe.de: I have seen that in C, macros generating macros. As the result, even if you knew you where looking at a macro, you had no way to find where it was declared. Because the declaration did not contain it's name (but concatenated it from many pieces). Search for the full name = the declaration is not found. With the above, you could at least define procedures, that can not be found by search. And over time it will happen. With macro support like this, people start building there macro-libraries. And eventually end up with things they never even intended themself. I see that, too. But I do not believe that the interpretation should be that rigoros. Incorporating a macro expander means of course a second level of text processing. So, if you descend in the macro, you have to think macro to read it. (Thats what I am not able to do) It is a language. You have to learn it if you want to use and understand it. And it works contrary to the procedural approach of pascal, it is a token eating and puking machine. Thats the way it is. It is not only the weakness, it is the power too. Will think about. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 14:41:35 +0100 schrieb Martin f...@mfriebe.de: The more support there is for macros, the more likely people will start whole libraries of macros. first just a lort of small harmless helpers. Then combinations there of... it grows, and then it becomes cancer (grows to something not intended...) Intended by whom? Good, me? I do not see the situation that black, if it will turn out to be cancer, why is that C not death. Yes, of course there are some cracks trying to write a program which gives the program back to stdout in reverse order, but who matters? I was not that careful with my writelns (at age 20...). Especially if I was looking for some bug there was a lot of copy and past. Greetings Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 20:46:30 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Inlining is better that doing the same with macro's, so is the use of
str/val better than macro tricks.
Wherever you can!
If I do some low level system work, it is possibly better to do it with
a macro.
If I have a project where rtti is needed anyway, I would be dumb not to
use it instead of a macro, if it fits the needs.
What is the need of rtti: pointer to base classes do not know
to which possibly derived class they point. Thats why *runtime* type
information. All other things which you use in your program do not need
runtime type information, they always know who they are. If I do not
use objects or classes I have therefor no need for runtime type
information.
To get the associated name of an enum? Thats compile time information.
If there is a need for this it should be delivered to me by something
like {$I %enumname%enum%}, I think you would not like to have it this
way. But {$I %color%red%} will hopefully give 'red'. While {$I %color%}
maybe gives then 'red,green,blue' :-)
What is the need of a macro processor:To change the handwritten code in
an automated way. Is this a bad idea? Are there no needs for this?
For example to hold to lists with same entries under all circumstances
in sync. A macro does this in the simplest manner.
If you have an need for changing your handwritten code in an automated
way and you do not have macros, what would you use then? LaTeX? an IDE
tool?, m4? or inventing an compiler feature, but then do not call it
rtti, call it a macro. (thats pretty polemic, don´t worry)
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sun, 15 May 2011 13:26:03 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Feel free to come up with examples and convince us. They need to be
examples of code that is much more awkward to write without macro's.
There are no examples. For one reason. If you program pascal the last
20 years you learn to circumvent all possible use cases for an small
macro. How could I write an example? There are no macros. I can only
give you an example if I switch on a hypothetical macro support for
pascal. Would you then be able to see that it is simple done this way??
Or would you say, Oh this should better be done this way.
Lets try to find it out:
I introduce macro definition by: {$M name(par_list):=mac_text}
and an expansion by {$E name(par_text)} for shortness.
I am a man who likes to have all debugging messages which i ever
introduces in my code to stay there and to simply vanish if I switch
them off by compiler directive. But this is a lot and I do not need it
anytime. Thats why I introduce a nice debugging level. Which will give
me the information I request. Debugging level 1,2,3,... Because this
gives problems with procedures I introduce an stack of that level
values, therefor I can heighten the debugging level right bevor an
procedure call and lower it on return.
This all I put inside a debug unit and an debug include file.
I have a need for an debug print macro and level switching macros and
pushing and poping macros for the debug level stack. Lets look how
they are defined:
{$M _dp(level,fmt,args):=
dbgprint(level,{$E dbgxfmt},{$E dbgxargs},fmt,args)
}
You see from time to time I need extra debug information, which is
conditional defined and goes to the included file, like the above:
{$ifdef EXTRA_INFO}
{$M dbgxfmt:='%s [%s]'}{$M dbgxargs:=[{$I %file%},{$I %line%}]}
{$else}
{$M dbgxfmt:=''}{$M dbgxargs:=[]}
{$endif}
In this include I have too, something like this:
{$ifdef MYDEBUG}
{$M dp(..):=_dp(..)}
{$M dl(..):=_dl(..)}
{$M dpush(..):=_dpush(..)}
{$M dpop(..):=_dpop(..)}
{$else}
{$M dp(..):=}
{$M dl(..):=}
{$M dpush(..):=}
{$M dpop(..):=}
{$endif}
which redirects the real use of the dp, dl, dpush and dpop macros to the
real working ones, or nothing, if switched off.
The dbgprint, dbglevel,dbgpush and dbgpop functions which are called
reside in my debug-unit, string formatting and that stuff, there.
Additional I put:
{$ifdef MYDEBUG}
{$M usesdebug:=use debug;}
{$M usesdebugand:=use debug,}
{$else}
{$M usesdebug:=}
{$M usesdebugand:=use }
{$endif}
into my debug.inc file. All I have to do now is writing a program
where I use it:
{$I debug.inc}
program test001;
{$E usesdebug}
{ or, if I have more used units
{$E usesdebugand}
crt,stack,whatever;
}
procedure testproc;
begin
{$E dp(1,'%s',['testproc called'])}
doing some complex things with more debug output of higher level
end;
begin
{$E dl(1)}
do some things
{$E dl(3)}
testproc;
do some things
end.
If I need more debug info I switch the level of debugging, if I need
high level debug from one function only I push the old level:
{$E dpush(6)}
testproc;
{$E dpop}
and pop it back on return.
And if I am ready, I compile it without -dMYDEBUG. But the source stays
unaffected. A month later I possibly have a need for.
You will say this looks like C programming or the macros are expanded
with bad syntax, thats intentionally, you can reach the same with the
simpler expansion syntax. And I DO USE IT. AND IT WORKS FINE.
This is a real working example from the real world. I use it in my
programs similar defined with the crutch of macros fpc has today!!
And this will never work with inline or whatever you may suggest.
- function with array of const arg not inlined (yet)
- extra debug info needs to be expanded outside a function
- debug level is needed as macro parameter
- the expansion of %FILE% and %LINE% is wrong anyway. I stated this two
weeks ago (patched myself).
You may say thats an really complex use case. It is, true. A full
fledged debug level stack oriented debugging system, which vanishes
completely from the code, if switched off.
Complete source is available, if you do not believe it works.
The misunderstanding you mention is I spoke about the concept
of RTTI, however fpc calls it, typeof is part of this concept.
If you have variants you have a need for RTTI-concept too.
The example with that small enumeration is not that bad, you think. The
overhead is what?, somehow 52 bytes data and maybe hundert of code. You
say its low, I say the example is very small too!
The same can be done with 0 bytes additional data and 0 bytes
additional code. In three ways:
- using compile time information (ugly build-in macro)
- using an macro
- keeping them in sync by hand (thats not the worst)
And thats the point.
It is a question of principal. If I write an program with really many
type definitions, for example 100 enumerated types and I do
Re: [fpc-devel] Macro Processing
Am Sun, 15 May 2011 00:30:38 +0200 schrieb Hans-Peter Diettrich drdiettri...@aol.com: I see this point and it is one reason for me to think very careful about: Is it possible to do it without touching the scanner? Is the rest interesting enough to make it worth a further thinking. If not, trash it. The macro definition and expansion has to be changed. Macro definition has to handle the formal parameter list, and this added code will execute only when a parameter list is present. Macro expansion will have to deal with the actual parameter list, also only when such a macro is used. With proper separation of old and new macro handling (with/out parameters), the new code again only executes when new macros are used in the code. General structure in both cases. This, an first attempt. The explicit case: There are a lot of pros doing it this way. - it is not needed to touch the scanner - the expansion is included with the same mechanism as file includes - macro expansions which leads to compiler directives are possible (macro expanded file inclusion) and processed the normal way. - it does not break the error message generation (the expansion is processed the normal way, but OK, not that good as with complete tokens stored). Maybe this is more a con, with workaround. - the expansion process uses the sort of token we decide to use, not the scanner. I think this improves efficiency. There are some cons too. - the expander has to break the pp_tokens down to chars. This is ineffective, but: It may be encapsulated and sometimes later removed; It does not effect the speed of the scanner in any way if no macros are used. Maybe if the scanner someday is really working context sensitive (producing asm_tokens, pp_tokens, pas_tokens) this can be removed completely. sources | | v v - | | | File Manager |--- | | | - | ^ ^^ | | || |- | || || | | || | Scanner |--- Token | || | | | || - | ||| | ||v | || - | || finclude | Directive| | |---|Interpreter| | || | | |- | | | | | v | |- | | einclude | Macro| | |EXPANDER | DEFINE | --| | | - ^ | | | | | | v - | Macro | | Symbol | |Table | - The implicit case: But I see a lot of problems doing it this way. pros: - some things can be done, which can not be done explicit. (But which??, is there really an example, where it comes to play?) - it is easier to have error messages consistent, because the information is stored in the tokens you process. cons: - you touch the scanner much deeper, introducing new tokens. - the tokens are really big, because of line and file positions and the whole stuff pascal tokens need this moment. (if you incorporate this information for consistent error messages) - you have to process all tokens! There may be pp_operators in the input stream too. So somebody will use them too!! (But you say the efficiency argument may be better achieved the way restricting the pp_operators, I do not believe that (this time). - You can not have (or not build ones) compiler directives inside the expansion!! - You can not have includes in the expansion (Or, if you have one, they are expanded too. But nobody can see this!! You look at the include file and it is completely different worked up inside an macro expansion
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 01:23:08 +0200 schrieb Joerg Schuelke joerg.schue...@gmx.de: A third one. It is a further single and isolated solution to prevent the use of a macro. How many of them are there around? A hundert, a thousand in 5 years? I will explain what is the problem with this. If I have a similar problem, a list of function names and somewhere else in my code a list of their names, would then be the answer to change the compiler, to make him give me the name of a procedure if I do str(proc)? And on and on.. I think nobody would say that, but it sounds a little like this. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 12:14:52 +0200 schrieb Florian Klämpfl flor...@freepascal.org: Because a lot of code in the compiler is very old (remember, it was started in 1993 using TP) and writestr for enums is new compare with this time span. Nobody rewrote the code yet. And it should not been rewritten this way, because this would force the use of RTTI information inside the compiler , which is needless. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 15:12:46 +0200 schrieb Florian Klaempfl flor...@freepascal.org: Since the compiler uses classes, it uses rtti already heavily so I miss the point. OK, you need the RTTI for simple storing and recovering the informations to ppu files or whatever, thats a point to use it. Under normal circumstances I would say, you should not use classes too. Use objects. Or only one of them, classes or objects. And now you have properties inside the compiler, maybe someday interfaces too. Do not misunderstand this! I mean only that the incorporation of features in the compiler is part of the problem and not of the solution. First of all in respect of the bug fixing problem you mention in your answer to Hans-Peter. Thats kind of an unsolvable problem, a discussion may help from time to time. I will not bore you with this I think you will think about that a hundert times, while I do it one times. with regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 14:36:33 +0200 schrieb Florian Klämpfl flor...@freepascal.org: so any new feature makes this worse without more people doing the dirty work of bug fixing. That's why I'am currently very carefull with new featuers. I see this point and it is one reason for me to think very careful about: Is it possible to do it without touching the scanner? Is the rest interesting enough to make it worth a further thinking. If not, trash it. with regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 16:29:15 +0200 (CEST) schrieb Daniël Mantione daniel.manti...@freepascal.org: ... will cause 52 bytes of RTTI data to be inserted in your executable. Any do-it-yourself solution will consume more space. Therefore the RTTI not only helps to keep the source code compact and therefore readable, it would also help to keep the compiler exe compact. So use of RTTI information inside the compiler is most welcome :) I think of this a little different. Maybe more from an other perspective. For me RTTI is a level of language extension. Like OOP, or generics, or inheritance. Macros are very low level (if you have them). It is not that I think that I would use a macro instead under all circumstances. But it should be possible to do it without RTTI which is of higher level in the language. The principle is do not use it if you do not like it. That should not influence the rest of the language. This way I think that it is not that bad to have a small, but powerful macro expander incorporated. 52 bytes of data. And the RTTI code? What if you do not smartlink? I repeat, I have really nothing against RTTI, but I state that it comes from a high level language extension. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 17:04:45 +0200 schrieb Joerg Schuelke joerg.schue...@gmx.de: I repeat, I have really nothing against RTTI, but I state that it comes from a high level language extension. By the way this RTTI thing comes from the argument: Do not use a macro, instead do it this way. But this forces me to use RTTI, which is possibly not what I want. Most of the arguments against macros where of this kind. You can do it an other way, using ... But this way I can show you even OOP is useless :) what I do not believe. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 17:38:27 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
Am 14.05.2011 17:30, schrieb Joerg Schuelke:
Am Sat, 14 May 2011 17:04:45 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
I repeat, I have really nothing against RTTI, but I state that it
comes from a high level language extension.
By the way this RTTI thing comes from the argument: Do not use a
macro, instead do it this way. But this forces me to use RTTI,
which is possibly not what I want.
Then you should use C ;) RTTI is something which makes life easier and
prevents mistakes.
I do not understand this C argument, I swear I am an pascal man! ;(
Again, nothing against RTTI, but I do not like to be forced to use it.
Most of the arguments against macros where of this kind.
You can do it an other way, using ...
But this way I can show you even OOP is useless :) what I do not
believe.
True. But the point is: macros are something rendering code easily
unreadable if used wrong ...
Yea, thats why the explicit expansion of the macros, even the dumbest
can see it is a macro expansion {$expand macro(1,2,3)} the words you
suggests.
By the way the RTTI approach do not solve the problem, if there is one,
we did not see that:
enum(en1,en2,en3,...);
...
strarr:array[...] of shortstring={
str(en1),
str(en2),
...
}
does only half of the work. You have to keep them in sync furthermore,
see the order.
Sometimes we shoot a little to quick, so do I, sorry for that.
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Macro Processing
The thoughts about further improvement of the macro capabilities of the
compiler are now so far along that I can post this paper. But it is not
that short, about three pages.
Why doing it? There are IDE Macros.
People do not use all the same IDE, some do not use any. The
IDE changes much quicker then a language. A strong separation
between language and IDE is needed.
Macros are ugly.
Yes, thats true, but nevertheless they are useful in some
contexts. Debugging macros from the C world are only one
example. Repeated code pieces another.
Macros slow down the compiling process. The expansion is ineffective.
Thats true only if every identifier has to be checked out for
possible macro expansion. Hashing the macro identifiers would
help too.
Thats Delphi inkompatible.
A separate preprocessor run would solve the problem.
So, why not? In the further reading the main thesis.
1. As far as possible simple syntax, which fits into the up to
date implemented language.
2. Maximal implementation of this syntax. No needless
restrictions.
3. Effectiveness in view of the implementation.
4. Effectiveness in view of the compiling process.
5. Features:
A view at the C-preprocessor tells us stringification,
concatenation, variadic macros (I hate C too, but it is a
starting point to make it better)
See:http://gcc.gnu.org/onlinedocs/cpp/
Macro definitions inside a macro definition are possible this
time. For me it would be the export from unit interfaces and
macro parameters.
**
It is better to have a concept fully implemented as far as it do not
collide with major principles. It is better to have one and not to use
it, than not to have one and want to use it. Some of the reasons not
to implement a feature which follows from a concept are in real only
reasons not to use the feature -under normal circumstances- and that
makes a difference.
**
at issue 4.
A construct of the kind {$I mac_id(mac_paramlist)} instead
of the simpler mac_id(mac_paramlist) for the use of an macro
would solve some of the problems. Even in respect of the
separation of true pascal code and preprocessor code it would
be nice.
The parenthesis with %-signs is even introduced, so we reuse it
mac_id:=%id. To prevent the collision with build-in macros
we abandon the closing %-sign.
at issue 3.
The preprocessor has to be able to identify the parameter in a
simple manner. Again par_use:=%id%. In this regard the
closing %, because of the variadic macros later on.
Thats enough to make it possible to write something like this:
{$define fak(x):=
{$if %x%=0}
{$else}
%x%*{$include %fak(%x%-1)}
{$endif}
}
and to use it by:
{$include %fak(6)}
which expands to:
6*5*4*3*2*1
at least if we allow the recursive use --it is an example--.
The ugly syntax of the macro use is intentionally. Refer issues 3 and 4.
To repeat:
The scanner scans for directives, if one encounters he calls
the macro expander / directive interpreter. There is no need
for checking each identifier to be a macro or not!!!
In my eyes this is very pascalian. Effective too. Even the
programmer would profit from this. A macro use is easy recognizable in
the source code. You hopefully think twice before you use a macro.
The use of macros takes place in contexts which are different from those
in ordinary pascal constructs. For example the handing over of a
unknown number of parameters would be helpful. Obviously this leads to
the use of .. as ellipsis.
Issue variadic macros:
{$define dp(x,y..):=
dbgstr(%x%,[%y..%]);
}
On the left side of the definition we have
par_def:= [ ( [ id_list ][ .. ] ) ]
id_list:= id [ , id_list ]
which leads to
no parameters; no ()
() no parameters; () obligatory
(..)variable number of parameters; even none
(id_list) fixed number of parameters
(id_list..) at least so many parameters as in id_list-1
x.. makes x optional
inside the defining text:
par_use:= %id% | %id..% | %..id% | %id1..id2% | %..%
%id%parameter identified by id
%id..% all parameters starting at id
(comma delimited)
%..id% all up to id (dito comma delimited)
%id1..id2% all from id1 to id2 (dito)
%..%all parameters (dito)
Issue Stringification: %
Issue Concatenation:%%
To distinguish these
Re: [fpc-devel] Macro Processing
Am Fri, 13 May 2011 11:25:36 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
In short: No, it is better to keep that particular box of pandora
closed.
None of the more modern languages implement macros, and this is for
good reason.
Pascal has always existed without macros. It keeps code readable:
what you read is what you get.
This is a strength of the language, and should remain that way.
Yes I can live without macros too, i do it for years.
FPC has macros today, and the one of the bad way, which you do not see
in the source!! And the scanner is today checking every identifier for
macro expansion, if you switch {$MACRO ON}.
Try to remove the macro support from the compiler and we will see,
there are people around, which use them, even the ones without
parameters.
The way I suggest for macro parameters make them better:
{$I %name(some text)} makes it clear, thats a macro
expansion. In respect of readability, where is the difference to:
name(param1,param2) in pascal, where you do know
it is a function call. Thats the same.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Fri, 13 May 2011 11:47:54 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
procedure dp(const x : string;y : array of const);inline;
begin
dbgstr(x,y);
end;
Nothing is wrong with that. Except:
- the code will never vanish from the object file. I like it, to have
my debugging code all the time present in the sources with no need
for commenting it out, if I think it is ready done.
With some small macros with parameters you can do that job, having
debugging messages, which completely vanish by doing one
simple {$undefine MYDEBUG}.
- if I try for example to use the %LINE% and %FILE% info inside the
debugging output, which I think is their means, I can not use a
procedure without writing the FILE and LINE thing every time I call
it. With a macro this would be done inside the macro.
macro dp(x,y)
dbgstr(whatever,{$I %FILE%},{$I %LINE%},something else)
The macro expansion than gives the LINE and FILE info without that I
am forced to write it again and again:
dp(x,y) in the code gives
dbgstr(...,{$I %FILE%},{$I %LINE%},...);
which outputs:
MSG: test-003.pas[102] : My debugging Message.
And not only the debugging message vanishes from my programm, the
debugging code too, if I switch it of.
But thats a special use.
The generics,... thats in real an other question.
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Fri, 13 May 2011 13:43:52 +0200 (CEST) schrieb Michael Van Canneyt mich...@freepascal.org: If I had my way, I would remove the existing ones alltogether. The one use case they have in FPC sources could easily be remedied. Thats a clear position. If there is no macro support at all, I would not ask to put parameters there in. And nobody else would do, too. But now you have macros and they are nearly useless and thats the reason, from time to time, somebody comes up with an idea like mine. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Fri, 13 May 2011 12:11:06 +0200 (CEST) schrieb Mattias Gaertner nc-gaert...@netcologne.de: Compiler errors in macros are often confusing/misleading, because the user does not see the expanded code. Same for debugger positions and handling. Macros can confuse other parsers. For example the fcl parser or the ones in IDEs. Especially imported macros from other units and conditional macros are not supported. Code editing functions in IDEs are mislead by macros especially conditional macros. The first point is a reason for me to circumvent the use of macros where ever I can. And I do so, I do not like them. The second point will lead to a situation where you can do nothing on the language without keeping in mind what the IDE will complain about. Then integrating the compiler completely in the IDE and no standalone compiler would be the solution. I fear that.Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Fri, 13 May 2011 14:05:43 +0200 schrieb Florian Klaempfl flor...@freepascal.org: Extending dump_stack is imo a much better approach, it even doesn't duplicated information already available in debugging info. Thats a unit? I`m a small man voting for a small solution. If some kind of macro support is integrated in the language this will never go away, using a unit from outside ... from time to time they all change their interface, or even go away completely. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Fri, 13 May 2011 12:18:48 +0200 (CEST) schrieb mar...@stack.nl (Marco van de Voort): I'm with Michael with this. While I see some valid usecases, I think the way to introduce a solution (macros) is worse than the problem. Also I want to stress again what Florian said, namely that macro support is not a solution for easy header conversion. It might look that way, but won't work. For large scale and/or specialistic use, simply preprocess the sources before compiling. The use cases of macros are spread over a wide field because they represent a concept which is different from the one of a compiled language. It is more like an build-in automagicaly working editor. Maybe we can find an other maybe even better solution for every single use case, is it an reason against the concept? From time to time I think, would be easier done with macro and parameter. OK doing a separate preprocessor run is a solution (m4 not -for me-), if it is not incorporated in the compiler, which would be nicer. Maybe it is the wrong place for discussing this, because I know the reasons against some kind of macro support are all on the side of the designers and implementors. The mean line is IDE and they have their own stuff doing similar things and i am not interested in IDE. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Thu, 12 May 2011 09:32:28 +0200 schrieb Michael Schnell mschn...@lumino.de: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Fri, 13 May 2011 15:00:26 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
A general decision is required: do we *want* explicit or implicit
macro expansion?
Yes, I see this point too, i thought it is better to have a restricted
form of macro processing introduced by means of an compiler directive,
then nothing. The idea of doing it the {$I macname(paramtext)} way was
born as an anticipation of the efficiency objection. Further thinking
brings it out - for me - that it would be not that bad.
Using an macro dp(x,[y,z]) is not so far from {$I %dp(x,[y,z])} if it
prevents the refusal of the whole thing. The efficiency argument is an
other. And some kind of aesthetic to separate pascal from preprocc code.
The point you mention is that it is this way impossible to change the
behavior of the pascal code outside the macro: Thats true you have to
put it in as an parameter. I do not know if this is that bad.
Any example where it makes really a difference?
The same effect can be achieved by an invocation like
dp(x,[y,z]);
just as in Format().
I think only in this special case, because of the ellipsis in that
array of const, which is build-in.
What if you do some other processing, for example something with lists
of names or sets, something where in pascal no ellipsis is allowed?
If that dp takes x and [y,z] for his arguments you will need to do it
this way: dp(x,'[y,z]') and inside the macro text some sort of
tokenization operator because of the comma. Or an other mechanism of
finding the parameters of an macro invocation, which will then be less
effective.
Macros should be stored as tokens, compatible with the scanner's
Record and Replay methods. The preprocesor must not distinguish
between identifiers and reserved words, see the implementation of
context-sensitive directive handling.
You mean the expanded text? That`s clear an internal macro processor
should do so. But the tokens of the macro processor himself are
completely different from pascal ones.
That depends on how it fits in the scanner and the file handling and
error reporting too. I think one possibility would be to break the
tokens down to chars and let the scanner do his work like on an
included file. Less effective, but better then rewriting the scanner.
...The detection of macro
identifiers can be done in the keyword recognition, eventually
resulting a tkMacro token.
Yes, the point was to show how it can be done without even the need for
this kind of recognition. But I see from your first annotation that it
leads to an real restriction. I am not ready with that.
Macro arguments can be stored as identifiers, which then are found
(during macro expansion) in the top-level symbol table. Eventually a
new symbol type MacroArgument has to be introduced, that enforces
argument substition, stringification etc.
The idea was to remove the macro parameter names from the macro text
body to prevent some kind of recursive recreation of macro parameter
names during the expansion of the macro body. Of course are the names
stored in some kind of symbol table entry.
IMO a macro parameter list should follow the language conventions, so
that a procedure identifier can be replaced by a macro identifier,
forcing macro expansion instead of generating an procedure call. I.e.
the preprocessor is a *postprocessor* for scanner tokens.
That's one more reason to position the preprocessor *after* the
scanner, or at the end of the tokenizer to prevent another call level.
Yes in both respects. I prefer the solution without that ugly %, too.
If it is not possible to incorporate it in the compiler, then it would
be a true preprocessor, but all the work of token parsing is done
twice. ;(
As mentioned at the begin, I don't like special syntax for macro
identifiers, invocation and parameters. The worth of your attempt, to
speed up macro processing, must be determined after it has been
implemented. IMO similar effects can be obtained by removing (not
introducing) some of the C preprocessor misfeatures, which have not
been considered yet. Candidates are recursive macro expansion and
(also recursive?) expansion of macro parameters, as well as
concatenation.
I will think about. Recursive expansion is a candidate for not using
it. The question is, influences this feature the efficiency of the
expansion process, even if it is not used? I`m not sure this day.
Thanks a lot for your really helpful thoughts.
Best regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Fri, 13 May 2011 20:29:32 +0200 schrieb Florian Klämpfl flor...@freepascal.org: Or just use an inline function with ifdef as mentioned previously. An inline function with an empty procedure body shouldn't cause any additional code. - I believe to remember that the compiler complains about - inlining not possible with array of const. - I do not see how it helps, to show that you can circumvent the use of macros in nearly all cases. - The question is - in my mind - are there reasons a macro processor is the better and cleaner way to do it, in some contexts. - Macro processing as concept is not useless if someone shows how it can be prevented in special cases. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Fri, 13 May 2011 18:19:24 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
We often have enumerated types, with arrays of strings or other
associated information, that must be kept in sync (array dimension
and content). Macros with parameters would allow to create these
tightly coupled declarations from a single piece of text, acting as
a table from which the enum can be created from column 1, a name
array from column 1 or 2, a list of procedure pointers from column
3, etc.
This is general case for generating source code, not for macros.
Why? It is not distributed throughout the source. This can be
localized in a single includefile which can be generated easily from
whatever coherent source you have, including a designtime solution in
lazarus that allows you to edit it comfortable in table form.
There are two different use cases in the compiler sources:
1.
{ !! Be sure to keep these in sync with ones in rtl/inc/varianth.inc }
varempty = 0;
varnull = 1;
{ keep this in sync with TIntfFlag in rtl/objpas/typinfo.pp }
TCompilerIntfFlag = (ifHasGuid,ifDispInterface,ifDispatch,ifHasStrGUID);
2.
{ possible types for symtable entries }
tsymtyp = (abstractsym,
staticvarsym,localvarsym,paravarsym,fieldvarsym,
SymTypeName : array[tsymtyp] of string[12] = (
'abstractsym','globalvar','localvar','paravar','fieldvar',
{ definition contains the informations about a type }
tdeftyp = (abstractdef,
arraydef,recorddef,pointerdef,orddef,
typName : array[tdeftyp] of string[12] = (
'abstractdef','arraydef','recorddef','pointerdef','orddef',
The first are spread over the source and not well solvable by the
use of macros. An include will do it better.
The second ones and you can believe me there are a planty more of such
examples, are easy solveable by macros. Moreover they are not even
marked to be kept in sync in the compiler sources.
A macro processor is the simplest way to generate such pieces of source
code. If it is that simple doing it another way you say, why can I
find in the compiler sources more then one example of this.
Because of a lack of capability to do it the easy way.
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 00:36:17 +0200 schrieb Jonas Maebe jonas.ma...@elis.ugent.be: 1) the compiler automatically makes you keep them in sync, because adding/removing an element form the enumeration will cause a compilation error for the array if it's not updated 2) the array can actually be removed at some time in the future, because FPC can nowadays convert enumerations to their their name in string representation (via str(), write() and writestr()). There are still some bugs in this functionality in 2.4.x on some platforms though, so it can't be used yet in the compiler 2) This is the solution? Making the compiler to store somewhere a string representation in my object file and then give it back to me if I request it by str(enumerate)??? Thats so completely ... overhead, with a cannon to shoot a sparrow. Since when has an enumeration such kind of name, which lives outside compile time? Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 00:36:17 +0200 schrieb Jonas Maebe jonas.ma...@elis.ugent.be: (via str(), write() and writestr()) Sorry, a misunderstanding, they deliver compile time information to me. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
A third one. It is a further single and isolated solution to prevent the use of a macro. How many of them are there around? A hundert, a thousand in 5 years? Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Thu, 12 May 2011 09:32:28 +0200 schrieb Michael Schnell mschn...@lumino.de: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 09:30:21 +0200 (CEST) schrieb mar...@stack.nl (Marco van de Voort): 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. Ok, not the reason. But coding security is the reason, you should do so, if you can. Look at Stroustrup. The reason for pascal not to do so, is what follows from that, a really complicated stack unwinding, for example. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 09:30:21 +0200 (CEST) schrieb mar...@stack.nl (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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 10:21:45 +0200 (CEST) schrieb mar...@stack.nl (Marco van de Voort): 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. _ 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 12:26:09 +0200 schrieb Michael Schnell mschn...@lumino.de: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 13:12:22 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
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.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 12:28:29 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 14:52:13 +0200 schrieb Jonas Maebe jonas.ma...@elis.ugent.be: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 15:08:45 +0200 schrieb Jonas Maebe jonas.ma...@elis.ugent.be: 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? 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? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 16:56:38 +0200 schrieb Florian Klaempfl flor...@freepascal.org: 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 17:56:39 +0200 schrieb Jonas Maebe jonas.ma...@elis.ugent.be: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 19:11:40 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Can't compile at revision: 17417
Am Tue, 10 May 2011 11:11:22 -0300 schrieb Marcos Douglas m...@delfire.net: PS: BTW, what the difference (at least on Win) to use option install in 'make'? Thats not windows related, make works the same way on all platforms. The arguments for make are: - options for make himself - targets (which parts of code to build) - variable definitions (which may modify the making of the targets) There are some commonly used targets with self explaining names - clean (tries to delete all during the build process generated files) - all (builds all targets -if you have more than one-) - install (installs the former build targets) If you want to know more about how make works, look for documentation. There is a lot of. There is somewhere a doc about the fpc build process, google for fpc build faq. I think that is not development related, if you have more questions it may be better to visit a forum or the general fpc-pascal mailing list. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Tue, 10 May 2011 13:26:59 -0300 schrieb kingbiz...@gmail.com kingbiz...@gmail.com: *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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Macro Patch
This third revision with additional %FUNC% macro and 'unknown' strings
changed to internalerror.
Regards
Jörg
Index: scanner.pas
===
--- scanner.pas (Revision 17417)
+++ scanner.pas (Arbeitskopie)
@@ -237,7 +237,7 @@
systems,
switches,
symbase,symtable,symtype,symsym,symconst,symdef,defutil,
- fmodule;
+ procinfo,fmodule;
var
{ dictionaries with the supported directives }
@@ -1712,11 +1712,33 @@
hs:=getdatestr
else
if hs='FILE' then
- hs:=current_module.sourcefiles.get_file_name(current_filepos.fileindex)
+ begin
+ hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex));
+ if assigned(hp) then hs:=hp.name^ else internalerror(201105101)
+ end
else
if hs='LINE' then
- hs:=tostr(current_filepos.line)
+ begin
+ hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex));
+ if assigned(hp) then hs:=tostr(hp.saveline_no) else internalerror(201105102)
+ end
else
+ if hs='PATH' then
+begin
+ hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex));
+ if assigned(hp) then hs:=hp.path^ else internalerror(201105103);
+ if hs='' then hs:=CurDirRelPath(target_info)
+end
+ else
+ if hs='FUNC' then
+begin
+ if assigned(current_procinfo) then
+ if assigned(current_procinfo.procdef) then
+if assigned(current_procinfo.procdef.procsym) then
+ hs:=current_procinfo.procdef.procsym.realname
+else internalerror(201105104);
+end
+ else
if hs='FPCVERSION' then
hs:=version_string
else
@@ -3473,7 +3495,7 @@
mac.is_used:=true;
inc(yylexcount);
insertmacro(pattern,mac.buftext,mac.buflen,
- mac.fileinfo.line,mac.fileinfo.fileindex);
+ current_scanner.line_no,current_scanner.inputfile.ref_index);
{ handle empty macros }
if c=#0 then
reload;
Index: fmodule.pas
===
--- fmodule.pas (Revision 17417)
+++ fmodule.pas (Arbeitskopie)
@@ -235,6 +235,7 @@
function get_source_file(moduleindex,fileindex : longint) : tinputfile;
procedure addloadedunit(hp:tmodule);
function find_module_from_symtable(st:tsymtable):tmodule;
+function ascend_from_macros(f:tinputfile) : tinputfile;
implementation
@@ -336,6 +337,13 @@
end;
+function ascend_from_macros(f:tinputfile) : tinputfile;
+ begin
+while assigned(f) and f.is_macro do f:=f.next;
+ascend_from_macros:=f;
+ end;
+
+
procedure addloadedunit(hp:tmodule);
begin
hp.moduleid:=loaded_units.count;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Tue, 10 May 2011 23:50:29 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Tue, 10 May 2011 18:41:35 -0300 schrieb kingbiz...@gmail.com kingbiz...@gmail.com: 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Tue, 10 May 2011 18:41:35 -0300 schrieb kingbiz...@gmail.com kingbiz...@gmail.com: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
Am Wed, 11 May 2011 00:23:13 +0200 schrieb Vinzent Höfler jellyfish.softw...@gmx.net: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Macro Patch
Some days ago I stated that the build-in macros %LINE% and %FILE%, used inside a macro, expand to the wrong (in my opinion) info from the defining context and not to those from the expanding context. That makes them nearly useless, because using them inside a macro for debugging purposes is their main benefit. I wrote two small changes for scanner.pas and fmodule.pas which solve the problem. Maybe the devils are interested in applying it, or something similar. The 'unknown' from my changes are in real Internal-Errors, which should never occur. But changing this let's trying him to find an Environment- Variable with the same name, which gives a Warning. So ... Best regards Jörg Index: compiler/fmodule.pas === --- compiler/fmodule.pas (Revision 17417) +++ compiler/fmodule.pas (Arbeitskopie) @@ -235,6 +235,7 @@ function get_source_file(moduleindex,fileindex : longint) : tinputfile; procedure addloadedunit(hp:tmodule); function find_module_from_symtable(st:tsymtable):tmodule; +function ascend_from_macros(f:tinputfile) : tinputfile; implementation @@ -336,6 +337,13 @@ end; +function ascend_from_macros(f:tinputfile) : tinputfile; + begin +while assigned(f) and f.is_macro do f:=f.next; +ascend_from_macros:=f; + end; + + procedure addloadedunit(hp:tmodule); begin hp.moduleid:=loaded_units.count; Index: compiler/scanner.pas === --- compiler/scanner.pas (Revision 17417) +++ compiler/scanner.pas (Arbeitskopie) @@ -1712,11 +1712,24 @@ hs:=getdatestr else if hs='FILE' then - hs:=current_module.sourcefiles.get_file_name(current_filepos.fileindex) + begin + hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex)); + if assigned(hp) then hs:=hp.name^ else hs:='unknown' + end else if hs='LINE' then - hs:=tostr(current_filepos.line) + begin + hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex)); + if assigned(hp) then hs:=tostr(hp.saveline_no) else hs:='unknown' + end else +if hs='PATH' then + begin + hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex)); + if assigned(hp) then hs:=hp.path^ else hs:='unknown'; + if hs='' then hs:=CurDirRelPath(target_info) + end + else if hs='FPCVERSION' then hs:=version_string else ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Macro Patch
A little further changing is needed to let it work as suspected. Even
if the macro is included via include file. In my first writing I didn't
recognize that the calling of insertmacro for _ID token is done with
mac.fileinfo.line and .fileindex, which is the point of definition.
Changed to current_scanner.line_no and
current_scanner.inputfile.ref_index.
Is this a problem for error recognition?, I think not, because the info
from the defining context is saved in the tmacro class.
Best regards
Jörg
Index: compiler/fmodule.pas
===
--- compiler/fmodule.pas (Revision 17417)
+++ compiler/fmodule.pas (Arbeitskopie)
@@ -235,6 +235,7 @@
function get_source_file(moduleindex,fileindex : longint) : tinputfile;
procedure addloadedunit(hp:tmodule);
function find_module_from_symtable(st:tsymtable):tmodule;
+function ascend_from_macros(f:tinputfile) : tinputfile;
implementation
@@ -336,6 +337,13 @@
end;
+function ascend_from_macros(f:tinputfile) : tinputfile;
+ begin
+while assigned(f) and f.is_macro do f:=f.next;
+ascend_from_macros:=f;
+ end;
+
+
procedure addloadedunit(hp:tmodule);
begin
hp.moduleid:=loaded_units.count;
Index: compiler/scanner.pas
===
--- compiler/scanner.pas (Revision 17417)
+++ compiler/scanner.pas (Arbeitskopie)
@@ -1712,11 +1712,24 @@
hs:=getdatestr
else
if hs='FILE' then
- hs:=current_module.sourcefiles.get_file_name(current_filepos.fileindex)
+ begin
+ hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex));
+ if assigned(hp) then hs:=hp.name^ else hs:='unknown'
+ end
else
if hs='LINE' then
- hs:=tostr(current_filepos.line)
+ begin
+ hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex));
+ if assigned(hp) then hs:=tostr(hp.saveline_no) else hs:='unknown'
+ end
else
+if hs='PATH' then
+ begin
+ hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex));
+ if assigned(hp) then hs:=hp.path^ else hs:='unknown';
+ if hs='' then hs:=CurDirRelPath(target_info)
+ end
+ else
if hs='FPCVERSION' then
hs:=version_string
else
@@ -3473,7 +3486,7 @@
mac.is_used:=true;
inc(yylexcount);
insertmacro(pattern,mac.buftext,mac.buflen,
- mac.fileinfo.line,mac.fileinfo.fileindex);
+ current_scanner.line_no,current_scanner.inputfile.ref_index);
{ handle empty macros }
if c=#0 then
reload;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Can't compile at revision: 17417
Am Mon, 9 May 2011 17:23:30 -0300 schrieb Marcos Douglas m...@delfire.net: I use /fixes_2_4 but I could not to compile (error in first mail). So, I took a look in sources from /trunk. I compared this files (odbcsql) and saw this difference between them (the patch). Did you understand? I think there are two possibilities: 1) During shutdown (shut off) something in your file system went wrong. You should 'svn up' again. Maybe svn can correct the error, or gives you a hint. 2) It is windows related. For me all works fine. But i´m using linux. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] __LINE__ and __FILE__ macros
Am Fri, 29 Apr 2011 09:58:08 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
I use an IDE macro to insert a predefined line, and then I just
change the constants I will log. The advantage of that way is that
you have full intellisense to specify the vars to dump, something
that is always hard with a macro.
Ok, so far. But: if you write code like
{$define _dp:=writeln(stderr,{$I %FILE%}:20,' [',{$I %LINE%},'] ')}
and somewhere else you use the dp macro, I would expect that it prints
out the line number and file name of the place where I used it and not
where I defined it. Yesterday I looked in the sources and found that
this is because insertmacro is always called with line and file
parameters from the defining context.
I think it would be more useful if the {$I %FILE%} and {$I %LINE%}
directives expand to the bottom level file name and line number, not
the one of the mac.text where they are used and even not from where
they may be included.
An other possibility is to make all levels of line and file info
accessible trough a construct like {$I %FILE%nnn%}, where nnn% is an
optional integer level description.
regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc modifiers
First i will note that what i state is not an error or bug in free pascal, but it is somehow unclean implemented. The decision for modifiers like cvar or cdecl to be an identifier token or an modifier token relies on context information. But what is that context? An example: type name=procedure; cdecl=integer; results in an error, but type cdecl=integer; name=procedure; is correct. The procedure type declaration consumes the cdecl token regardless of the following token. There is no need for this. The = token can be used as context switch, but you´ll need a look ahead of 2 tokens. And that conflicts with the LL1 base structure of pascal. What a pity. For some other modifiers you have the same situation var name:typ; cvar:integer; is an error, but var cvar:integer; name:typ; is correct. You may say in most circumstances the required ; token right before the modifier token is the problem. For example for the absolute directive this kind of problem does not arise. The forward directive is another example, would´nt it be better to have forward be an keyword? I think if the compiler allows one construct he should not reject the other. But, i am not the first programmer who complains about that, so put it in the garbage. (Or start discussion) Sorry for my bad English, with best regards Jörg Schülke ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] __LINE__ and __FILE__ macros
Best regards to all developers, is it somehow possible to access the line number and file information during the compilation? This would be nice for debugging purposes. I do not write about the compiled in debug information for gdb. ASSERT can - i read it in the documentation - access this information. Is it without to much work possible to make this information accessible as macro? Are there any plans to extend macro support (parameters?)? Best regards again Jörg Schülke ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] __LINE__ and __FILE__ macros
Am Thu, 28 Apr 2011 18:23:10 +0200 (CEST) schrieb mar...@stack.nl (Marco van de Voort): Look in the manual under preprocessor $i (include) thx, hard to find there. I thought i did read them all, but ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc modifiers
Am Thu, 28 Apr 2011 18:22:38 +0200 (CEST) schrieb mar...@stack.nl (Marco van de Voort): In our previous episode, Marco van de Voort said: No, since modifiers can be in any order, it could be a lot more than two tokens. I think if the compiler reeds the cdecl token he needs a lookup of only one token to decide: is used as a modifier or a identifier token. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] __LINE__ and __FILE__ macros
Am Thu, 28 Apr 2011 18:23:10 +0200 (CEST) schrieb mar...@stack.nl (Marco van de Voort): Look in the manual under preprocessor $i (include) Thats better then nothing, but if you want to include this information in debugging information, and you won't write it again and again you will need an expression which is usable inside an macro. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] __LINE__ and __FILE__ macros
Am Thu, 28 Apr 2011 20:09:59 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
No further explanation needed. Nested comments do it.
I did not know that {$define mx:= ... (*$%LINE%*)} works.
Best regards to Marco
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc modifiers
Am Thu, 28 Apr 2011 23:39:35 +0200 schrieb Hans-Peter Diettrich drdiettri...@aol.com: The bug resides in the dirty Delphi OPL definition. Is it a bug or unspecified behavior? I think it is implemented in the hope it works good enough. If you consume a modifier token as modifier or identifier in respect of the right context of one token, you get rid of this strange behavior and you will get a real superset of the former language. So, why not doing it? Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] {$I %LINE%} and friends
There is one problem with {$I %LINE%} and his friends, which restricts
the use of these directives. They are expanded even inside a macro
immediately, so, if you define a macro for debugging purposes, you
get the line and file info for the place of the definition and not
for the place of the expansion.
I am playing around with the compiler for some weeks, maybe i will send
a patch ( in a couple of weeks, the code is somehow complicated ) if
desired.
But what is the cleaner way? To defer the expansion of {$I %xxx%}
inside macros, or to define c-like macros __LINE__ and __FILE__, maybe
with nicer names?
Best regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
