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
