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 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 : > 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 : 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 : > 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 : > 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 : > >> 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 : > 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 : 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 : > 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 : > >> 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 : > > 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 : > 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 20:27:30 +0200 schrieb Florian Klämpfl : > >> 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? Hans-Peter Diettrich wrote this to show that the ellipsis in macro processing maybe not needed. Whereas I think that this is true only under special circumstances (array of const; sets). The need of an example to show that it is sometimes usefull not to force explicit macro expansion. That was an other question. I do not see the need for that. > >> >> A general decision is required: do we *want* explicit or > >> >> implicit macro expansion? This because he would prefer not to force en explicit expansion by {$I macname(macparamlist)}, he would rather use the simpler macname(macparamlist), which leads to implizit expansion. But however, I see the restriction of doing it explicit, but I have no idea, where it may come to play. Thats why the request for an example. This has nothing to do with the > >>dp(x,[y,z]); example which is of course some kind of debugging macro. regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 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 : > 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 : > (via str(), write() and writestr()) Sorry, a misunderstanding, they deliver compile time information to me. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
A third one. It is a further single and isolated solution to prevent the use of a macro. How many of them are there around? A hundert, a thousand in 5 years? Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] 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 : 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 : > 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. <>___ 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 : > 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ämpfl: 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 : > 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 : > 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 : 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 : > ... 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 : > > 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 : > >> >> 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 : > Am 14.05.2011 17:30, schrieb Joerg Schuelke: > > Am Sat, 14 May 2011 17:04:45 +0200 > > schrieb Joerg Schuelke : > > > >> > >> 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
Florian Klämpfl schrieb: 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. Any thoughts about extending resources? 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
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 20:46:30 +0200 (CEST) schrieb Daniël Mantione : > 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 : 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 : > 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 not need the pseudo runtime
Re: [fpc-devel] Macro Processing
Am Sun, 15 May 2011 00:30:38 +0200 schrieb Hans-Peter Diettrich : > > 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 expans
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
Am Sun, 15 May 2011 13:26:03 +0200 (CEST) schrieb Daniël Mantione : > 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 : > >> 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 : > 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 wrote: > Am Sun, 15 May 2011 20:06:02 +0200 > schrieb Jonas Maebe : > > > 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 : > 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 : > 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 wrote: > Am Mon, 16 May 2011 11:16:39 +0300 > schrieb ik : > > > 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) ,'
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 : > 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 : > 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 : > 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 : > 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 Martin: 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 : >{$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 Martin: {$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 : > 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 : > 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 Martin: 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 Mon, 16 May 2011 13:01:39 +0300 schrieb ik : > 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 : > {$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 Martin: {$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 : > 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 Martin: 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 : > 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