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
On 17/05/2011 12:19, Joerg Schuelke wrote:
Am Mon, 16 May 2011 15:35:24 +0100
schrieb Martinf...@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.
1) The point is, one may not be able to reject it.
If I used a 3rd party package (open source) for a long time, heavily
relaying on it. And the add it, and I need a bug fix, that requires me
to update
2) the example itself is beside the point.
All our examples are beside the point. Mine, yours, any
I think we can easily agree on the following:
1) It is possible to find examples that some people may want to use
(never mind if alternatives exist)
2) It is always possible to find examples of (lack of a better word):
abuse
As for 1, you made yourself a statement: It will be a few people only in
some rare cases. I can try to find your emails.
As for 2, it is mostly there problem, so why bother? Except for if such
code gets into the public domain, as described above
Any way, I feel neither of those 2 statements can be argued (with the
hope of success). I think that can be concluded, after about 85 mails,
trying to find the ultimate example for either side, and no-one any
closer to proving their point...
-
Or at least they can not be argued, unless we answer this question:
Should the compiler protect people from doing potentially dangerous
thinks (knowing this is never a 100% protection anyway)
C obviously doesn't give a damm what people do to themself.
Pascal is supposed to care about it?
If that care is wanted, then the bad examples may gain some importance
--
To me that leaves one other remaining questions. But feel free to add
other points...
Looking at it as a potential feature. How does one evaluate if a feature
should be added.
After all adding features has always been a selective process. this is
not new for this case
1) Is there a need for this feature = We apparently have trouble to
agree on this point. There may be a need for some
2) Does the cost/benefit equation work out
We need to define need (for feature), cost and benefit (benefit is
somewhat coupled to need)
For you as an individual, there is a need, and the benefit is bigger
than the cost.
For me as individual, it is the opposite.
To get a fairer measure we can (in my opinion) only base this on average
values. If you take the entire community, and (in lack of better data
take a guess how many people need it, how many may use it, and how many
may be affected. And assume some averages based on this.
The definition of the terms below, are not solely meant for macro
feature = they apply to every feature (past/future/accepted/rejected)
- every feature shares the same risks, and provides benefits, and for
every feature this cost/benefit can be calculated
need
= The amount of people that want this feature to be implemented (in
this case feature means the extension from what it currently already is)
= It should not matter why they want it (because we tried that
discussionm without success), but only if they want it.
cost
= side-effects of the feature
- This can be the above described undesired exposure to the use of the
feature by others (in the case that use of the code of the other can not
be avoided). Probably low risk.
- this can be any side effect it has on the compiler. (all those are
potential / the may or may not apply, the may pose a very small, or not
so small risk...)
Bugs intruduced (now or in future)
Resource usage, memory, cpu time (potential slow down)
Effects on future features / making it harder to add other features
(which may be wanted by a bigger amount of people, provide greater benefits
Maintenance cost of the code itself
benefit
- objective benefits: like the ability to write code that by some
definition is better/cleaner
- subjective benefits: the ability for some individuals,to use the
feature, for whatever perceived gain
As for the need/benefit = It is not known how many people would be
affected.
But you said yourself several times, probably only a few, and only in
few cases
As for cost, we do not know how many risks will actually turn into
reality (so maintenance cost for example will exist). But if any risk
happens to come true, it affects every one.
Based on this. The question is does the benefits really outweigh the cost ?
___
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)
On 17/05/2011 13:19, Joerg Schuelke wrote: Am Tue, 17 May 2011 12:59:57 +0100 schrieb Martinf...@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 ;-) Going for educational.. or theoretical... There is another idea = which would still make some of this possible. but which I don't know if it would be worth it. ... The macro processing (that has been proposed before) can be done by a pre-processor. The draw-backs may be solvable. (assuming I am correct about point 3) A pre-processor would create temporary files, with the macros expanded. It has to be agreed, that those temp files, are only for the purpose of compilig, and must never be touched/edited by a person (since changes would be lost the next time the pre-processor runs). In fact those temp files should be deleted right after compilation. This does affect: 1) the ability of fpc to check if a ppu needs to be recompiled, because the source file known to fpc doesn't exist 2) the output of line numbers for compile errors and warnings 3) line numbers in debug info 1: would be solved by the pre-processor, that would to the check, and put a new temp file in the place, expected by fpc 2: can be solved easily. The pre-processor has to run fpc, the pre-processor reads the fpc output, and maps line numbers to the correct place 3: Could be solved by compilng to asm. (I assume): fpc must write the info for the assembler how the line numbers map. so they could be corrected. And the assembler can be called once line numbers are corrected It is quite some work though. But you do not need to touch fpc at all. ___ 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 16.05.2011 02:30, schrieb Joerg Schuelke:
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.
You still need to keep infoarr and callenum in sync so simple macros
are only half of a solution in this case.
___
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
On Sun, May 15, 2011 at 21:22, Joerg Schuelke joerg.schue...@gmx.de wrote: 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. Using Macro or even RTTI for the debug example is actually not a good idea or example. Most programming libraries that offer logging tools, provide you with several type of section to log things, and only display the level you wish to display. You can easily create a TEventLog decedent with more debug sections and tell what level of that debug (if any at all) to be saved. One of the thing that I really hate about C is that it's way too low level. You have to take care of so many irrelevant things, that instead of fixing the ideas, you have so many features to help you hack them. C does not support returning content of a variable, so they passes the whole variable content instead. They do not have strings, so you have pointers of char, or array of chars. You can not know if the declaration of char is for bytes or for literal (as real) chars. You do not have inline support, or override of functions, so macros are the way they do it. You can take a symbol in C and make it part of a macro. That's an ugly hack that makes more problems then solve them. I'm unfortunately wrie also in C when I need (and try not to need to do it), and I find it hard to work on code that others create. You find many callbacks decelerations inside the function that use them instead of typeof deceleration and you find a lot of hacks to do stuff. I also program in languages such as PHP, and Ruby, and I find that the Pascal way of variable deceleration much better in understanding, because I know that the variable is declared. On Ruby for example, even if you created the variable inside an if statement, it will be viewable to the entire function unlike C and others. Why do I mention it ? because on C and PHP you see many bugs because of that inline variable feature. On PHP if you write once tomatow and once tomato they both valid, even though that the original variable is tomatow, so you will have null content for it and a big headack on it. On C, the preprocessor will stop you at time. On Ruby, it will be like with Pascal and C, the interpretor will not allow you to work. The Go language of Google for example decided that the Pascal way is more safe then the C way on this. 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. Remember that it's way too easy to missus a feature, you see it all of the time on most programming languages. Pascal is better because it takes readability over hacks. You can still create unreadable with Pascal, but it's harder to do it. Jörg Ido ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ 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
On Mon, May 16, 2011 at 12:23, Joerg Schuelke joerg.schue...@gmx.de wrote:
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!!
On current FPC yes, on C it's more complicated then that.
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 ;-(
It's not high level, it's the same level as you suggested, but already
existed and
not required to implement a new feature. You want to write your own logging
system,
then ok, please do, but why do I have to use Macro for that ? your example
of the
whole new logging system is very complicated and prune to have a lot of
problems
inside.
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
You can have the entire calling stack of an exception as well (without using
a macro) on FPC and I think also on Delphi.
However the FILE, can be used with TObject.UnitName and no Macro.
FUNC, You can get that information (including it's memory address) using
RTTI.
LINE, well using exception that you capture you can get that (remember the
calling stack feature ?).
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 was at Ruby IRC once and someone told people that they wish to use
Hungarian notation with Ruby.
Ruby's variables are all inherited from Kernel class, but can be changed
like Pascal's variant on run-time.
It's silly to use Hungarian notation on such type of variables, even if you
make them immutable.
If that person would recommend that the usage of that notation as a
programming guideline, then it will
have the same reaction like with the Macro discussion. I still do not
understand what are the benefits that
I will have, however I do understand what are the problems I can have (not
all).
Your example is not good enough to make me understand the need for Macro.
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.
In C you can create a callback and any type structure except of records and
unions
inside a function.
It's very unreadable and hard to to maintain or use.
because you are using the include system, you also have a lot of IFDEF that
allow things
to be included only once.
A lot of IFDEF are unmaintainable hacks btw. Not only on C but also with
Pascal.
The way you suggested to create a Macro is not so readable imho.
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 ?
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.
There are unit tests tools, there are BDD based testing tools and more,
however
most of the time, I prefer to write my own tests that check if things are
what they should
or should not have.
I used to use a lot of asserts 10 years ago, now I prefer not to use them.
I used to like Exceptions, now I prefer to return error codes
The thing is that I have a choice. I can do things as I want. but even my
hacks are
maintainable and readable, you just need to understand the logic of the
library and
things are easy to use. With Macro you do not have that. Each macro have
it's own
logic, and it's own idea, and it's own style. See remember the list above ?
you can
have the line, unit etc name without using a Macro.
You can have logging system that you prefer to have without Macro. Even the
one
you suggested.
But no, we mess around with that writeln thing and comments. Do not say
you did not, you did never.
Sure I do, and I use many time something like this:
procedure toLog(const S : String);
{$IFDEF DEBUG}
{$ENDIF}
end;
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}
Re: [fpc-devel] Macro Processing
On 16/05/2011 10:23, Joerg Schuelke wrote: 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. IMHO a discussion on this is limited by the fact that the importance all of the reasones (pro and contra) is very subjective. In short, it is possible to do any of this without (further) macros) That is i believe agreed. It is merely a question of how much extra typing. - The log stuff can be done by inserting $I %FILE in every call to the log; and by using $IFDEF a lot. Though there are tricks to reduce that... - The array of callbacks can be maintained with find-and-replace (does not need an IDE) - worst case some pascal code can be generated by another application/script and be included (the generated file would never be edited directly (like translated header files) 1) Anyway, a macro can save some typing, make some block of code shorter, reduce the need of repeating something (well replace it by repeat the macro) 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, that other do not know how to read. Using a macro *can* be seen as saying, the means provided by the language you choose are not good enough, so you need something else (raises the question why you choose that language). Both lists can be extended. But never mind if each list has 1 or 2, or a hundred entries. You have to decide personally what is more important to you. Those who studied the concept of designing a language (which is apparently a huge topic), may be able to add some (more) objective reasons. But for the rest of us this comparison is a subjective task. Highly influenced by what each individual, wants to do, and is used to do from past experienced. Obviously for you the gains, are more important. But same as obviously for other the losses (readability, compromising language design) are important too. So far each side has repetitively pointed out, that in their opinion, their arguments are more important (that does not make the arguments of the other side wrong, it simple indicates the personal importance of them). As for no one is forced to use it Not entirely true. Only if I write code, that no one else can ever change. Lots of code is written n teams. Lo9ts of code (especially open source) code uses 3rd party packages, and may require to read that code. Once the feature is available, **everyone** who has to read such code, must always look at for it. Making the feature available, forces others to deal with it. ___ 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
On 16/05/2011 13:53, Joerg Schuelke wrote:
Am Mon, 16 May 2011 11:11:39 +0100
schrieb Martinf...@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.fo/fpc-devel
It still allows to do thinks one shouldn't do. It already does today.
Macros can contain structural elements such as begin/end. Therefore a
macro can be used to change the fundamental structure of a language
(never mind if you see, that it is a macro or not)
The example at the end of my mail does compile (fpc trunc).
Yes you will say, no one should or ever would do that. But the think is:
people might (and people do thinks you and I would never dream of)
Even simple tasks like translating begin to anfang are evil enough.
But with params you could change language structure, in ways that
actually are tempting
something like
{$MyProc (Name) := procedure %Name%; begin}
and then code like:
MyProc(Foo) writeln(1); end;
or if you want (no better)
{$Expand MyProc(Foo)} writeln(1); end;
And the argument it shouldn't be used for thinks like this is no good.
Trust me it will.
Example that works with todays fpc already (NEVER do this):
program Project1;
{$mode objfpc}{$H+}
{$MACRO ON}
{$define X := end; function foo: integer; begin}
procedure bar;
begin
X;
end;
begin
writeln(foo);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
On 16/05/2011 11:37, Joerg Schuelke wrote: 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. If use case are so rare, then it raises the bigger question: Based on the knowledge, that any code can contain bugs. And that any code, (even small and simple code) added to a bigger project has a risk (whatever slight) to add bug (either within the code itself, or to modify data-structures relied on, and trigger bugs in existing code The point is adding macros to the compiler, has a risk of bugs. If not now then in future. A point valid for any feature added to any program. The question is as always: Is the gain, worth the risk. 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. Should all suffer, for the very few, or should the very few have to yield for the good of many? ___ 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
On 16/05/2011 01:30, Joerg Schuelke wrote:
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
}
}
And that is exactly where macro turn into red hot iron.
The same could be used to say define a procedure, and the name of the
procedure would be the result of some concatenation.
Or define a macro the name of which is the result of some operation
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.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
On 16/05/2011 14:30, Joerg Schuelke wrote:
Am Mon, 16 May 2011 14:07:54 +0100
schrieb Martinf...@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.
Se my other mail( 30 secs ago)
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...)
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.
I have a few of them in the code I wrote for lazarus.
I put all of them in their own IFDEF.
Making a clear statement at the very place of the writeln, that they are
conditional.
To me it increases readability.
Well and on top, the editor I use can color the IFDEF, just a nice add
on, but not a necessity = not an argument: Because the use (or none
use) of macros can and should not be decided by the cpacibilities of the
editors that individuals use.
___
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
On 16/05/2011 15:18, Joerg Schuelke wrote:
It is not only
the weakness, it is the power too. Will think about.
weakness and power are not necessary opposites, or exclusive.
and btw, allow me the rhetoric (though not as the means of an argument,
since it isn't good style):
you know what they say about power? power corrupts.
Am Mon, 16 May 2011 14:41:35 +0100
schrieb Martinf...@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.
Cancer may not have been a good term, to keep the discussion clean.
But it doesn't have to kill something, just make it harder to live with
it. And often C (if used with lots of macros) is by far harder to read,
than pascal (that doesn't have macros).
Is it so far fetched, that someone who has a lot of procedures that all
look like:
procedure Foo1; // number may change
const
FooNum = 1;
var
Obj1a, Obj1b: TObject; // again number changes
begin
Obj1a := TOPbject.Create;
Obj1b := TOPbject.Create;
try
// now some code that changes
finally
Obj1a.free;
Obj1b.free;
end;
end;
may end up with a macro for the whole opening and the whole end, and
that those macros, are just combining individual other macros.
and then just write
{$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.
-
But as I wrote.
all those Arguments yours and mine are both correct. That is not the
question.
The question is, which one to give the higher importance.
And we will bot apply our subjective view. And this will not be changed
by arguments that easily.
We both know the risks and advantages they have (I do not deny that they
are powerful tools)
The difference is:
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.
___
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
Op Sun, 15 May 2011, schreef Joerg Schuelke:
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.
Even if you have a project where RTTI is not needed, you would be thumb
not to use it instead of a macro. Really. There is no drawback.
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.
You are completely mistaken. This is what C++ uses RTTI for. FPC (nor
Delphi) does not use RTTI for this purpose at all! We have the typeof
function for this, which returns a pointer to the VMT. I even have no idea
wether the RTTI can be used for this purpose at all :)
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.
You are wrong again. Ansistrings/widestrings/variants and so on make use
of RTTI.
To get the associated name of an enum? Thats compile time information.
Then show a practical example where having it at compile time is a real
benefit. Please understand it clear: We are not against new features, but
there must be a benefit.
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)
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.
Daniël___
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
On 15 May 2011, at 17:53, Joerg Schuelke wrote: 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. 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. Additionally, the RTTI's code overhead goes down (percentage-wise) when the examples become bigger, since there is one generic routine for lookups that is reused in all cases. And of course, not using RTTI does not mean that no code has to be generated for the lookups (indexing an array also requires code). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Joerg Schuelke: 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)??? All types (not just enums) have runtime type information that is stored in the object file. Runtime type information is very powerfull and has many applications, for example memory management for automatic types, or the population of a TForm with data entered in the GUI in Lazarus. Converting an enum to a string is another application of runtime type information. Thats so completely ... overhead, with a cannon to shoot a sparrow. There is no overhead because any unused RTTI is removed when smartlinking. Since when has an enumeration such kind of name, which lives outside compile time? RTTI is quite old already, but the compiler can convert between enums and strings since version 2.3. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
On Sat, 14 May 2011, Joerg Schuelke wrote: 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? Since always as soon as you use str() on it, or if it is in RTTI somewhere. How do you think streaming works ? Michael. ___ 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 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
In our previous episode, Joerg Schuelke said: 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, Not really, if the RTTI is too slow for you, simply generate the array once on startup. (disclaimer I actually never have tested RTTI speed) Since when has an enumeration such kind of name, which lives outside compile time? Delphi: afaik always. It is a result of its form loading concept. The object inspector must be able to enumerate the various options for the combobox. FPC: pretty soon after Delphi compat was started; 1998ish. 0.99.10 or 0.99.12 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 14.05.2011 01:23, schrieb Joerg Schuelke: 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? It simply shows that in a modern programming language macros has few real use cases because there are a lot of other constructs which serve a similiar purpose. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Marco van de Voort: 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, Not really, if the RTTI is too slow for you, simply generate the array once on startup. (disclaimer I actually never have tested RTTI speed) It ain't slow at all. I think it beats many quick and dirty manual conversion solutions in speed and/or memory consumption. Maybe if you use it in an inner loop you may want your own code. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 14.05.2011 00:06, schrieb Joerg Schuelke: 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 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Florian Klämpfl schrieb: It simply shows that in a modern programming language macros has few real use cases because there are a lot of other constructs which serve a similiar purpose. ACK Nonetheless I wonder which efforts had to be made, to mimic only some of the many macro usages. While named constants deserve not much compiler code, what about: - overloaded procedures - inline procedures - templates - generics All that could already be implemented by macros, since the invention of C and its preprocessor. How long will we have to wait for further replacements in Pascal? IMO macros with arguments are not so hard to implement like beforementioned features, require no changes to the language syntax, and they will not slow down the compiler (if not used). Now give me any reasonable argument, why it should not be *allowed* to extend the compiler accordingly. The implementation can be provided by the community, as usual. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 14.05.2011 14:43, schrieb Hans-Peter Diettrich: Florian Klämpfl schrieb: It simply shows that in a modern programming language macros has few real use cases because there are a lot of other constructs which serve a similiar purpose. ACK Nonetheless I wonder which efforts had to be made, to mimic only some of the many macro usages. It's only a side effect that it reduces macro use cases. Now give me any reasonable argument, why it should not be *allowed* to extend the compiler accordingly. Look at the bug count graph (important part attached, one gray line is 100 open bugs) and you will see that we're currently even not able due to lacking resources to maintain the current features 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. attachment: 2011-05-14_143259.png___ 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 14.05.2011 15:07, schrieb Joerg Schuelke: Am Sat, 14 May 2011 12:14:52 +0200 schrieb Florian Klämpflflor...@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. Since the compiler uses classes, it uses rtti already heavily so I miss the point. ___ 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
Op Sat, 14 May 2011, schreef Joerg Schuelke: 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. It's not needless, it's usefull :) This code: type colour=(red,green,blue); begin writeln(red); writeln(green); writeln(blue); end; ... 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 :) Daniël___ 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 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. 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 and this is not true for OOP. And remember: pascal should always prevent you from shooting yourself into the foot (e.g. from http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/). ___ 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
Re: [fpc-devel] Macro Processing
Am 14.05.2011 19:02, schrieb Joerg Schuelke:
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.
What's wrong with it?
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.
The idea is to get completly rid of strarr because the typical use case
is like s:=strarr[en]; which can be replaced e.g. by writestr(s,en);
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Joerg Schuelke: 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). RTTI *allows* for language extensions, like str/val for enums. RTTI by itself are just data structures describing Pascal types, emitted automatically by the compiler. Language extensions can use those data structures to provide their functionality. 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. I still don't see why it should be possible to do it without RTTI. But the question is, is the unknown reason that you don't want to use str a justification for adding the can of worms that is called macro's? 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. It's not that bad, but it should make something possible. Until now I haven't seen many bright examples of things that cannot be elegantly without macro's. 52 bytes of data. And the RTTI code? Not much. Converting an enum to a string is a single procedure. It's quickly won back if you use the feature a few times. Actually this is a nice story about the hidden costs of language features. The procedure would be extremely simple (lookup a pointer to the string in an array, return the string), but FPC supports non sequential enums: type colour=(red:=1,green:=10,blue:=100); The majority of the code in the procedure that converts an enum to a string deals with handling this special situation (don't worry: normal enums are still a simple lookup). Often when you add features, it has unforseen consequences and it can be a complicated effort to make everything together well enough. This is why you want to be carefull adding new features. What if you do not smartlink? Then you get so much extra code in your exe that the RTTI is still a small and irrelevant portion. Actually in the past you could disable RTTI generation, but it was too sensitive for bugs. Removing unused code data is the task of the linker, we decided to make the linker do what it is designed for. I repeat, I have really nothing against RTTI, but I state that it comes from a high level language extension. Good. 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. H... For the same reasoning you could say inline functions are ugly and you want not to be forced to use inlining. The point is that every time you can avoid a macro you win on code clarity, compiler speed (no time spent on evaluation expansion), debugability, parsability by IDE's, and so on. Inlining is better that doing the same with macro's, so is the use of str/val better than macro tricks. We don't want to force you to use RTTI, but our point is that there is proper solution to achieve the same benefit that the macro approach gives. But this way I can show you even OOP is useless :) what I do not believe. While I do believe in the merit of OOP, there are many dubious OOP features that you can criticize in a valid way, escpially because few of those features open new possibilities. But unfortunately it's a waste of time; we need this for compatibility. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Joerg Schuelke schrieb: 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. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
On 13.05.2011 15:55, Hans-Peter Diettrich wrote: Traditional Pascal added compiler directives, hidden inside comments. It's only a matter of performance, whether these directives should be handled immediately at detection of a comment, or after a comment has been fully recognized (skipped) by the scanner. Conditional compilation also can be implemented outside the scanner, with optional feedback instructing the scanner to *not* apply special processing to tokens which are skipped by conditional directives. Include directives require more support in the scanner, which then must be capable of switching between multiple input streams. Macros can be implemented in the same way, but it will be more efficient to Record and Replay token streams instead of character streams. This recorder also can be implemented outside the scanner, an according filter will either return a previously recorded token, or else it asks the scanner for the next token. There is already a token recorder/replayer: the one that is used for generics. Regards, Sven ___ 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
On Fri, 13 May 2011, Joerg Schuelke wrote: 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. 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. If you want macros, preprocess your code with m4. Or program in C or C++ Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
I could live with something similiar you proposed, maybe with other preprocessor keywords like $macro and $expand instead so that it's clear it's something new. But I fear this is not what most people being pro macro want: they want something like C and think this will solve all the C header porting problems. But it doesn't because it doesn't fit into the unit concept (a C like solution). Further, it adds another language concept for which I see no need. Writing debugging info isn't, this can be done by a function taking a array of const. What's wrong with procedure dp(const x : string;y : array of const);inline; begin dbgstr(x,y); end; ? Constants? Pascal has native constants, C hadn't. Poor man's templates? Well, we have generics, if they lack something, we should improve them. Repeated code? Pascal has nested functions, most of the time they are enough and they can be marked as inlined. I really thing we should first collect use cases and maybe improve existing solutions if needed instead of opening another can. If the faculty example doesn't generate good code, the inline folding should be improved etc. like the possiblity to use inline functions in constant expressions if the inline function can be evaluated at compile time etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Joerg Schuelke joerg.schue...@gmx.de hat am 13. Mai 2011 um 02:07 geschrieben: 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. 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. Thats Delphi inkompatible. A separate preprocessor run would solve the problem. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
In our previous episode, Joerg Schuelke said: 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. 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. ___ 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: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
On Fri, 13 May 2011, Joerg Schuelke wrote:
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.
But I don't want to encourage their use by making them better or more
visible.
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.
Michael.
___
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
On 13 May 2011, at 13:43, Michael Van Canneyt wrote: 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. They were introduced for Mac Pascal compiler compatibility, and are used quite regularly in that context via command line definitions such as -dSomeMacro:=123 The Mac OS X universal interfaces would also need quite some rewriting to remove all macro usage. While most could probably be changed into either conditional defines or constants, I'm not certain whether that would work for all of them. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
On Fri, 13 May 2011, Jonas Maebe wrote: On 13 May 2011, at 13:43, Michael Van Canneyt wrote: 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. They were introduced for Mac Pascal compiler compatibility, and are used quite regularly in that context via command line definitions such as -dSomeMacro:=123 The Mac OS X universal interfaces would also need quite some rewriting to remove all macro usage. While most could probably be changed into either conditional defines or constants, I'm not certain whether that would work for all of them. I'm sorry, I was not aware they were used for the Mac Pascal dialect. (not having a Mac is my only excuse for not looking into that ;) ) In each case, my case remains: I don't consider them good practise, and certainly wouldn't want to encourage their use by 'improving' them. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
In our previous episode, Michael Van Canneyt said: The Mac OS X universal interfaces would also need quite some rewriting to remove all macro usage. While most could probably be changed into either conditional defines or constants, I'm not certain whether that would work for all of them. I'm sorry, I was not aware they were used for the Mac Pascal dialect. (not having a Mac is my only excuse for not looking into that ;) ) Comfort yourself with the fact that you are not the only one :-) http://bugs.freepascal.org/view.php?id=12935 ___ 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 13.05.2011 13:45, schrieb Joerg Schuelke:
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}.
Ifdef the dbgstr line and the code should vanish when it's inlined. If
not, this should be fixed.
- 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.
Extending dump_stack is imo a much better approach, it even doesn't
duplicated information already available in debugging info.
___
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
On Fri, 13 May 2011, Joerg Schuelke wrote: 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. And from time to time I repeat my position on the matter :) I really don't think the issue merits so much attention. In my opinion, this kind of thing is not what makes a language useful. (if I thought so, I would have switched to something else a long time ago). I consider the available libraries and standard routines are orders of magnitude more important: being able to take on any problem without having to think whether the necessary routines are available. Michael. ___ 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 13.05.2011 14:28, schrieb Joerg Schuelke: 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. dump_stack is a function of the fpc system unit. ___ 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] Macro Processing
Marco van de Voort schrieb: For large scale and/or specialistic use, simply preprocess the sources before compiling. This doesn't help in any way, when it comes to updates of such code :-( Eventual error messages refer to the preprocessed code, but corrections should be applied to the unprocessed file - where? And what about modifications to the preprocessed file - these are lost after the next preprocessor run. Okay, one can take that as an argument against *any* preprocessing, but this doesn't help anybody who has a valid reason for using an preprocessor. Look at the many includes in the cpu declarations, created by external tools... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Mattias Gaertner schrieb: Compiler errors in macros are often confusing/misleading, because the user does not see the expanded code. That's where a compiler listing comes into the play, generated e.g. by the preprocessor option (-m). Same for debugger positions and handling. Not really different from conditional compilation. 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. True, it should be possible to re-create parsers from a common grammar. Code editing functions in IDEs are mislead by macros especially conditional macros. A nowadays IDE already must recognize many conditionals and declarations. It may be worth to spend some time with a consideration, what makes life hard to the coder and the CodeTools, and how this can be simplified. Even if FPC is designed as a highly speed-optimized prodcution compiler, what's that speed gain worth when a coder spends most of its time in reading and updating source code? What about an interactive compiler, that can be created from the same codebase as the production compiler, but which interfaces much better with an IDE and its CodeTools? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Michael Van Canneyt schrieb: In short: No, it is better to keep that particular box of pandora closed. It may be worth a try. None of the more modern languages implement macros, and this is for good reason. Right, preprocessor support can be *added* to every language, introducing macros, directives, conditional compilation etc. The only issue is performance, which led to an integration of preprocessing features into *existing* scanners and parsers, with the most simple and least intrusive placement of an preprocessor between the scanner and parser, as kind of an token filter. The only requirement may be the addition of preprocessor tokens to the scanner, if ever. Traditional Pascal added compiler directives, hidden inside comments. It's only a matter of performance, whether these directives should be handled immediately at detection of a comment, or after a comment has been fully recognized (skipped) by the scanner. Conditional compilation also can be implemented outside the scanner, with optional feedback instructing the scanner to *not* apply special processing to tokens which are skipped by conditional directives. Include directives require more support in the scanner, which then must be capable of switching between multiple input streams. Macros can be implemented in the same way, but it will be more efficient to Record and Replay token streams instead of character streams. This recorder also can be implemented outside the scanner, an according filter will either return a previously recorded token, or else it asks the scanner for the next token. 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. This IMO is no more true, since the introduction of overloaded procedures and virtual methods. How often is the reader of some code lost in an call to an abstract method :-( The current directives can already make the code unreadable, with the ugly $INCLUDE :-( If you want macros, preprocess your code with m4. Or program in C or C++ That's a stupid idea :-( Where would you put the boundary between useful preprocessing (include files, conditional compilation...) and useless preprocessing? For what valid reason? I'd leave that vote to the user. Extended macro support doesn't require many changes to the existing compiler (scanner), so that it can be implemented e.g. in TScannerFile descendants. The only requirement is an agreement, that the scanner interface and preprocessor hooks will not be broken by updates to the scanner class. Then everybody can add its own preprocessor extensions, without affecting the main stream compiler. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Joerg Schuelke schrieb:
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.
[...]
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.
A general decision is required: do we *want* explicit or implicit macro
expansion?
IMO an important use for macros is the ability to modify parts of the
code, without touching the code to be modified. E.g. replacing DebugLn
by a NOP macro allows to remove all debug output from a unit - much
harder to do with $IFDEF.
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..%]);
}
The same effect can be achieved by an invocation like
dp(x,[y,z]);
just as in Format().
Remark: Up to now it is not clear what a token is for the preprocessor.
The simplest is to only recognize the tokens for the preprocessor
himself and to pass on the others unchanged as chars. The advantage of
this: maybe it fits better in the present scanner, maybe efficiency.
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. The detection of macro identifiers
can be done in the keyword recognition, eventually resulting a tkMacro
token.
What about syntactical checks while reading the macro replacement text?
No need for that, only the parameters are recognized and some kind of
mark inserted instead of them.
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.
Detail work:
1. What about , and ) delimiting token in mac_paramlist.
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.
One problem which I can see is the structure of the fpc scanner. His
interface is really fat. Maybe further thinkings brings it out:
It is impossible to do that without rewriting the whole scanner. But I
will do that thinkings.
That's one more reason to position the preprocessor *after* the scanner,
or at the end of the tokenizer to prevent another call level.
Sorry the bad English folks, but it was the harder work for me to
translate it, then it is for you, to read it.
Nice work :-)
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.
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Florian Klaempfl schrieb: I really thing we should first collect use cases and maybe improve existing solutions if needed instead of opening another can. ACK. Here a first example: 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. While much can be done with an array of records, I badly miss a feature to create an enum from such an array. Ever hit an number of elements differ error, with no indication of which of the many enum elements have been added or removed? In the worst case the code will fail, when somebody only reordered the enum or array elements, without any compiler hint :-( Another one: Replacement of $IFs. (Around DebugLn...) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
On 13/05/2011 15:19, Hans-Peter Diettrich wrote:
Replacement of $IFs. (Around DebugLn...)
That one is solved already, with existing macros.
rtl\inc\lnfodwrf.pp
{$MACRO ON}
//{$DEFINE DEBUG_DWARF_PARSER}
{$ifdef DEBUG_DWARF_PARSER}
{$define DEBUG_WRITELN := WriteLn}
{$else}
{$define DEBUG_WRITELN := //}
{$endif}
and then
DEBUG_WRITELN('Skipping directory : ', s);
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
In our previous episode, Hans-Peter Diettrich said: For large scale and/or specialistic use, simply preprocess the sources before compiling. This doesn't help in any way, when it comes to updates of such code :-( Eventual error messages refer to the preprocessed code, but corrections should be applied to the unprocessed file - where? Where the macro is used. If you don't want to get burned, stay away from fire. And what about modifications to the preprocessed file - these are lost after the next preprocessor run. Well, you shouldn't then, obviously. Okay, one can take that as an argument against *any* preprocessing, but this doesn't help anybody who has a valid reason for using an preprocessor. I have used that technique several times. I don't see what is wrong with it. Sure there are downsides, like any solution, but we are talking about a few promille of problems not solved by other means. Look at the many includes in the cpu declarations, created by external tools... ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
In our previous episode, Hans-Peter Diettrich said: I really thing we should first collect use cases and maybe improve existing solutions if needed instead of opening another can. ACK. Here a first example: 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. ___ 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 13.05.2011 20:09, schrieb Joerg Schuelke: 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? Of course not, but what's the use case of this general example? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 13.05.2011 17:41, schrieb Martin:
On 13/05/2011 15:19, Hans-Peter Diettrich wrote:
Replacement of $IFs. (Around DebugLn...)
That one is solved already, with existing macros.
rtl\inc\lnfodwrf.pp
{$MACRO ON}
//{$DEFINE DEBUG_DWARF_PARSER}
{$ifdef DEBUG_DWARF_PARSER}
{$define DEBUG_WRITELN := WriteLn}
{$else}
{$define DEBUG_WRITELN := //}
{$endif}
and then
DEBUG_WRITELN('Skipping directory : ', s);
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.
___
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
On 13/05/2011 19:29, Florian Klämpfl wrote:
Am 13.05.2011 17:41, schrieb Martin:
{$MACRO ON}
//{$DEFINE DEBUG_DWARF_PARSER}
{$ifdef DEBUG_DWARF_PARSER}
{$define DEBUG_WRITELN := WriteLn}
{$else}
{$define DEBUG_WRITELN := //}
{$endif}
and then
DEBUG_WRITELN('Skipping directory : ', s);
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.
First of all, i an *no* friend of the example above, nor do I plan to
ever do something like it. I don't even plan on using macros at all.
But I found it an interesting example how far you can already get with
the current macros.
Personally, I IFDEF my debug code. I see it as an advantage. Since the
IDE can highlight IFDEFs, I can quickly differentiate them from normal code.
About the inline, and no code generated, if the body is empty.
Dose this apply, even if the procedure takes parameters, and some of the
params are function calls ? This is, will fpc skip the function calls,
as their result is not used?
I haven't tested it, just curious.
Martin
___
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
On 14 May 2011, at 00:06, Joerg Schuelke wrote:
{ 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.
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
Jonas___
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
