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 preve
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
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
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,
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 deci
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
tact
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
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 no
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 m
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
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;n
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
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
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
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
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
Am Mon, 16 May 2011 13:01:39 +0300
schrieb ik :
> procedure toLog(const S : String); <--
> {$IFDEF DEBUG} |
> |
> {$ENDIF} |
> end; |
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! The
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 i
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
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
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
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 cal
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, th
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 enumeratio
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 o
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
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.
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 le
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 bett
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
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
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 wor
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.
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, lik
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
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 ext
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
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
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 woul
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.
An
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:
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
circumstanc
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
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, becau
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
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
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
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 fo
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
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
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
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
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
t
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.
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.f
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
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',
>
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
>
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 yo
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 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 pos
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}
>
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 bu
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,
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
> associa
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
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 DEBU
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 sy
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 th
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
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 d
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 unproces
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
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 sma
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
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
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
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 ob
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 parame
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
> >
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 a
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 vi
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 tim
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
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 co
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 th
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.
>
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 portin
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.
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 change
91 matches
Mail list logo
