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
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
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
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
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
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
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
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 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
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
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
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 i
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
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
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 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 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. I
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
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
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 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,
Am Thu, 12 May 2011 09:32:28 +0200
schrieb Michael Schnell :
> > 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 project.
Yesterda
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 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
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 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
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
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
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
Am Thu, 12 May 2011 09:32:28 +0200
schrieb Michael Schnell :
> 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 project.
Thats a merrily idea: This would mean writing macro definitions to a
temporary
Am Wed, 11 May 2011 19:11:40 +0200
schrieb Hans-Peter Diettrich :
> Since that time I don't wonder any more, why a C compiler
> spends 50% of its time in scanning (and preprocessing) the input.
I would introduce a macro expansion trough a compiler directive. Then
there is no need to scan the who
Am Wed, 11 May 2011 17:56:39 +0200
schrieb Jonas Maebe :
> For the compiler itself such things are toggled via command line
> switches (-vc, -vt, -vu, -vd, -vp, ...).
That must be some kind of misunderstanding I know the compiler
switches, I spoke about runtime debugging informations, not compile
Am Wed, 11 May 2011 16:56:38 +0200
schrieb Florian Klaempfl :
> to get a node tree at a particular place. Having this in macros
> everywhere makes imo no sense because one would gets an incredible
> amount of data.
OK, to make it concrete, I refer to an level driven debug system
commonly used for
Am Wed, 11 May 2011 15:08:45 +0200
schrieb Jonas Maebe :
> I don't use any kind of automatic code generation/writing
> functionality of any IDE or editor (and I edit the FPC compiler
> sources with Lazarus, Text Wrangler, vim and nano depending on what
> I'm doing or how I'm logged in). At l
Am Wed, 11 May 2011 14:52:13 +0200
schrieb Jonas Maebe :
> but I'm
> personally not missing anything as far as compiler development is
> concerned.
You use an IDE? But what without? The language is the one and the IDE
is the other. There are plenty of users who do not use an IDE, or not
all t
Am Wed, 11 May 2011 12:28:29 +0200
schrieb Hans-Peter Diettrich :
> Otherwise a declaration list is accepted only at the
> *begin* of a compound statement, not inside a statement list:
>
> compound_stat: '{' [decl_list] [stat_list] '}' ;
I thought that = | ...
And only the kind of which is
Am Wed, 11 May 2011 13:12:22 +0200
schrieb Hans-Peter Diettrich :
> FPC macros don't have parameters, for
> this and other reasons. That's not a hard restriction, because inline
> procedures can be used instead, in many cases.
Hmmm, I think about macros for pascal with parameters for some time,
Am Wed, 11 May 2011 12:26:09 +0200
schrieb Michael Schnell :
> Readability problems might arise regarding the scope of equally named
> variables. Pascal ovoid much of this.
I agree,
and somebody will then come and suggest:
Lets do it this way.
var a:integer;
begin
some code using a;
var
Am Wed, 11 May 2011 10:21:45 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
> FPC is much lighter on that, and never runs
> constructors automatically. It only initializes some pointer values
> to NIL.
>
> So you'll have to explain that remark in more detail.
> _
Yes, today.
What I
Am Wed, 11 May 2011 09:30:21 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
> In our previous episode, Joerg Schuelke said:
> > The reason for C++ to say a declaration is a statement is coding
> > security.
>
But all that was not the question, implementing the des
Am Wed, 11 May 2011 09:30:21 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
> I always thought the main reason was because C did it that way, and
> C++ is C backwards compat.
>
> And C did it because it wanted to save stack space in the minis of
> the early seventies. The rest is IMHO
Am Wed, 11 May 2011 00:23:13 +0200
schrieb Vinzent Höfler :
> I would. FPC already has interfaces.
>
> There are good reasons why most languages didn't adopt the C++-way
> of doing MI.
I think we have two concepts
- inheritance
- interface
You can decide for one ore the other, or possibly
Am Tue, 10 May 2011 18:41:35 -0300
schrieb "kingbiz...@gmail.com" :
> Lets see the OOP, its very helpful and speedup a lot the work and has
> been added to the Pascal. Same for generics.
OOP is an concept. Nobody would say that it would not be helpful if
pascal has templates -an other very helpf
Am Tue, 10 May 2011 18:41:35 -0300
schrieb "kingbiz...@gmail.com" :
> Some small details can also increase
> the community.
>
> Lets see the OOP, its very helpful and speedup a lot the work and has
> been added to the Pascal. Same for generics.
To decide that a declaration is a statement and c
Am Tue, 10 May 2011 23:50:29 +0200
schrieb Hans-Peter Diettrich :
> The syntax would look like:
>
> Block = "BEGIN" [Declarations] {Statement} "END" .
Yea, it looks like C, but it is not. The difference in C like languages
is that an declaration is just a kind of statement. Without this, I
think
This third revision with additional %FUNC% macro and 'unknown' strings
changed to internalerror.
Regards
Jörg
Index: scanner.pas
===
--- scanner.pas (Revision 17417)
+++ scanner.pas (Arbeitskopie)
@@ -237,7 +237,7 @@
sy
Am Tue, 10 May 2011 13:26:59 -0300
schrieb "kingbiz...@gmail.com" :
> *Good:* fast algorithm testings, code creating
> *Bad?:* not a standard of the pascal language
Thats a bad idea. It is completely against the basic structure of
pascal. Other Languages have other paradigms.
For example C++. Th
Am Tue, 10 May 2011 11:11:22 -0300
schrieb Marcos Douglas :
> PS: BTW, what the difference (at least on Win) to use option "install"
> in 'make'?
Thats not windows related, make works the same way on all platforms.
The arguments for make are:
- options for make himself
- targets (which parts of c
Am Mon, 9 May 2011 17:23:30 -0300
schrieb Marcos Douglas :
> > I use /fixes_2_4 but I could not to compile (error in first mail).
> > So, I took a look in sources from /trunk. I compared this files
> > (odbcsql) and saw this difference between them (the patch).
>
> Did you understand?
I think
A little further changing is needed to let it work as suspected. Even
if the macro is included via include file. In my first writing I didn't
recognize that the calling of insertmacro for _ID token is done with
mac.fileinfo.line and .fileindex, which is the point of definition.
Changed to current_
Some days ago I stated that the build-in macros %LINE% and %FILE%, used
inside a macro, expand to the wrong (in my opinion) info from the
defining context and not to those from the expanding context.
That makes them nearly useless, because using them inside a macro for
debugging purposes is their
Am Fri, 29 Apr 2011 09:58:08 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
> I use an IDE macro to insert a predefined line, and then I just
> change the constants I will log. The advantage of that way is that
> you have full intellisense to specify the vars to dump, something
> that
There is one problem with {$I %LINE%} and his friends, which restricts
the use of these directives. They are expanded even inside a macro
immediately, so, if you define a macro for debugging purposes, you
get the line and file info for the place of the definition and not
for the place of the expans
Am Thu, 28 Apr 2011 23:39:35 +0200
schrieb Hans-Peter Diettrich :
> The bug resides in the dirty Delphi OPL definition.
>
Is it a bug or unspecified behavior? I think it is implemented in the
hope it works good enough.
If you consume a token as or in
respect of the right context of one token,
Am Thu, 28 Apr 2011 20:09:59 +0200
schrieb Joerg Schuelke :
No further explanation needed. Nested comments do it.
I did not know that {$define mx:= ... (*$%LINE%*)} works.
Best regards to Marco
Jörg
___
fpc-devel maillist - fpc-devel
Am Thu, 28 Apr 2011 18:23:10 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
>
> Look in the manual under preprocessor $i (include)
>
Thats better then nothing, but if you want to include this information
in debugging information, and you won't write it again and again you
will need a
Am Thu, 28 Apr 2011 18:22:38 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
> In our previous episode, Marco van de Voort said:
>
> No, since modifiers can be in any order, it could be a lot more than
> two tokens.
>
I think if the compiler reeds the token he needs a lookup of
only
Am Thu, 28 Apr 2011 18:23:10 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
> Look in the manual under preprocessor $i (include)
thx, hard to find there. I thought i did read them all, but ...
___
fpc-devel maillist - fpc-devel@lists.freep
Best regards to all developers,
is it somehow possible to access the line number and file information
during the compilation? This would be nice for debugging purposes.
I do not write about the compiled in debug information for gdb.
ASSERT can - i read it in the documentation - access this infor
First i will note that what i state is not an error or bug in free
pascal, but it is somehow unclean implemented.
The decision for modifiers like cvar or cdecl to be an
token or an token relies on context information. But what is
that context? An example:
type
name=procedure;
cdecl=integer;
71 matches
Mail list logo
