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
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.
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
Joerg Schuelke joerg.schue...@gmx.de hat am 13. Mai 2011 um 02:07
geschrieben:
The thoughts about further improvement of the macro capabilities of the
compiler are now so far along that I can post this paper. But it is not
that short, about three pages.
Why doing it? There are IDE
On May 10, 2011, at 9:07 AM, dhkblas...@zeelandnet.nl
dhkblas...@zeelandnet.nl wrote:
On Tue, 10 May 2011 08:30:28 +0200 (CEST), Michael Van Canneyt
mich...@freepascal.org wrote:
On Tue, 10 May 2011, Darius Blaszyk wrote:
Hi,
I've created a trivial front end for fppkg (see lazarus
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
On Fri, 13 May 2011, Darius Blaszyk wrote:
All this info is supposed to be output in XML format from fpmake
--manifest. fppkg picks it up and stores it in the repository.
If you want to extend it to include a category and keywords, be my guest.
Thanks, that was the class indeed I was
On May 13, 2011, at 1:01 PM, Michael Van Canneyt wrote:
On Fri, 13 May 2011, Darius Blaszyk wrote:
All this info is supposed to be output in XML format from fpmake
--manifest. fppkg picks it up and stores it in the repository.
If you want to extend it to include a category and
On Fri, 13 May 2011, Darius Blaszyk wrote:
On May 13, 2011, at 1:01 PM, Michael Van Canneyt wrote:
On Fri, 13 May 2011, Darius Blaszyk wrote:
All this info is supposed to be output in XML format from fpmake
--manifest. fppkg picks it up and stores it in the repository.
If you want to
Am Fri, 13 May 2011 11:25:36 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
In short: No, it is better to keep that particular box of pandora
closed.
None of the more modern languages implement macros, and this is for
good reason.
Pascal has always existed without
On Fri, 13 May 2011, Joerg Schuelke wrote:
Am Fri, 13 May 2011 11:25:36 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
In short: No, it is better to keep that particular box of pandora
closed.
None of the more modern languages implement macros, and this is for
good
Am Fri, 13 May 2011 11:47:54 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
procedure dp(const x : string;y : array of const);inline;
begin
dbgstr(x,y);
end;
Nothing is wrong with that. Except:
- the code will never vanish from the object file. I like it, to have
my
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
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
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
Am Fri, 13 May 2011 13:43:52 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
If I had my way, I would remove the existing ones alltogether.
The one use case they have in FPC sources could easily be remedied.
Thats a clear position. If there is no macro support at all, I would
Am 13.05.2011 13:45, schrieb Joerg Schuelke:
Am Fri, 13 May 2011 11:47:54 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
procedure dp(const x : string;y : array of const);inline;
begin
dbgstr(x,y);
end;
Nothing is wrong with that. Except:
- the code will never vanish
Am Fri, 13 May 2011 12:11:06 +0200 (CEST)
schrieb Mattias Gaertner nc-gaert...@netcologne.de:
Compiler errors in macros are often confusing/misleading, because
the user does not see the expanded code. Same for debugger positions
and handling.
Macros can confuse other parsers. For example
On Fri, 13 May 2011, Joerg Schuelke wrote:
Am Fri, 13 May 2011 13:43:52 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
If I had my way, I would remove the existing ones alltogether.
The one use case they have in FPC sources could easily be remedied.
Thats a clear
Am Fri, 13 May 2011 14:05:43 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
Extending dump_stack is imo a much better approach, it even doesn't
duplicated information already available in debugging info.
Thats a unit? I`m a small man voting for a small solution. If some kind
of macro
Am 13.05.2011 14:28, schrieb Joerg Schuelke:
Am Fri, 13 May 2011 14:05:43 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
Extending dump_stack is imo a much better approach, it even doesn't
duplicated information already available in debugging info.
Thats a unit? I`m a small man
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
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
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
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,
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
Am Thu, 12 May 2011 09:32:28 +0200
schrieb Michael Schnell mschn...@lumino.de:
I would introduce a macro expansion trough a compiler directive.
What a bout a compiler directive to optionally call the gnu C
preprocessor ? I would have wanted used this some time ago for a very
special
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
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
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
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
Am Fri, 13 May 2011 15:00:26 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
A general decision is required: do we *want* explicit or implicit
macro expansion?
Yes, I see this point too, i thought it is better to have a restricted
form of macro processing introduced by means of an
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.
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
Am Fri, 13 May 2011 20:29:32 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
Or just use an inline function with ifdef as mentioned previously. An
inline function with an empty procedure body shouldn't cause any
additional code.
- I believe to remember that the compiler complains about
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 : ',
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
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
Am Sat, 14 May 2011 00:36:17 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
1) the compiler automatically makes you keep them in sync, because
adding/removing an element form the enumeration will cause a
compilation error for the array if it's not updated
2) the array can actually be
Am Sat, 14 May 2011 00:36:17 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
(via str(), write() and writestr())
Sorry, a misunderstanding, they deliver compile time information to me.
Jörg
___
fpc-devel maillist -
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
41 matches
Mail list logo
