On Fri, Jun 22, 2018 at 6:47 PM, Sven Barth via fpc-pascal
wrote:
>
>> [...]
>
> Why not simply test it?
>
> That said you can also do this:
>
> === code begin ===
>
> {$macro on}
>
> {$ifdef debug}
> {$define foo := foo_debug}
> {$else}
> {$define foo := foo_run}
> {$endif}
>
> uses
> foo;
Am 23.06.2018 um 04:30 schrieb Ryan Joseph:
On Jun 23, 2018, at 3:13 AM, Florian Klämpfl wrote:
{$macro on}
{$define TypeStr:=specialize _TypeStr}
begin
Writeln(TypeStr);
end.
;)
You have a good sense of humor about it at least. :)
So you can in fact print types, albeit with a more
> On Jun 23, 2018, at 3:13 AM, Florian Klämpfl wrote:
>
> {$macro on}
>
> {$define TypeStr:=specialize _TypeStr}
>
> begin
> Writeln(TypeStr);
> end.
>
>
> ;)
You have a good sense of humor about it at least. :)
So you can in fact print types, albeit with a more verbose syntax and by
Am 22.06.2018 um 23:10 schrieb Marcos Douglas B. Santos:
On Fri, Jun 22, 2018 at 5:13 PM, Florian Klämpfl wrote:
{$macro on}
{$define TypeStr:=specialize _TypeStr}
begin
Writeln(TypeStr);
end.
Can I use the same idea but for units?
Like this:
{$macro on}
uses
{$ifdef debug}
On Fri, Jun 22, 2018 at 5:13 PM, Florian Klämpfl wrote:
>
> {$macro on}
>
> {$define TypeStr:=specialize _TypeStr}
>
> begin
> Writeln(TypeStr);
> end.
Can I use the same idea but for units?
Like this:
{$macro on}
uses
{$ifdef debug}
foo_debug
{$define foo := foo_debug}
{else}
Am 22.06.2018 um 08:01 schrieb Michael Van Canneyt:
On Fri, 22 Jun 2018, Ryan Joseph wrote:
On Jun 22, 2018, at 12:21 PM, Michael Van Canneyt
wrote:
'Nice' is not an argument.
If someone else assumes that assert() works as expected - i.e. throws an exception, then your macro will mess
Am 22.06.2018 um 22:13 schrieb Florian Klämpfl:
Am 22.06.2018 um 22:07 schrieb Sven Barth via fpc-pascal:
Am 22.06.2018 um 10:12 schrieb Ryan Joseph:
On Jun 22, 2018, at 12:24 PM, Sven Barth via fpc-pascal
wrote:
If $Assertions is set to Off the complete Assert() line will be
absent from
Am 22.06.2018 um 22:07 schrieb Sven Barth via fpc-pascal:
Am 22.06.2018 um 10:12 schrieb Ryan Joseph:
On Jun 22, 2018, at 12:24 PM, Sven Barth via fpc-pascal
wrote:
If $Assertions is set to Off the complete Assert() line will be absent from the
compiled code.
Good to know thanks.
Am 22.06.2018 um 10:12 schrieb Ryan Joseph:
On Jun 22, 2018, at 12:24 PM, Sven Barth via fpc-pascal
wrote:
If $Assertions is set to Off the complete Assert() line will be absent from the
compiled code.
Good to know thanks.
Here’s an example of something I’ve seen for debugging. I think
See below the function to convert dynamic value into string value inside
interpreter project I am working at, something similar to *ToStr family in FPC.
It's generated by the macro which expands to corresponding branches for each
value type. "$" prefixes are for passing macro arguments.
On Fri, 22 Jun 2018, denisgolovan wrote:
Do you have examples here?
There are several use-cases I often see.
1. The task is to allow declaration of some container structure (vector, tree,
etc.)
2. Meta declarations for global entities with names/ids/descriptions/etc.
3. Dynamic libraries
> Do you have examples here?
There are several use-cases I often see.
1. The task is to allow declaration of some container structure (vector, tree,
etc.)
The mechanism to create it must have enough flexibility to define/parametrize
at compile-time in one go:
- keys are integers in 0..N-1 only
On Fri, 22 Jun 2018, Sven Barth via fpc-pascal wrote:
A good and just question. We most likely didn't realize the consequences.
Meanwhile we're older, more experienced and we now know what impact
seemingly
good ideas can have...
They were added for MacPascal compatibility:
Michael Van Canneyt schrieb am Fr., 22. Juni 2018,
08:01:
>
>
> On Fri, 22 Jun 2018, Ryan Joseph wrote:
>
> >
> >
> >> On Jun 22, 2018, at 12:21 PM, Michael Van Canneyt <
> mich...@freepascal.org> wrote:
> >>
> >> 'Nice' is not an argument.
> >>
> >> If someone else assumes that assert() works
In our previous episode, Ryan Joseph said:
>
> Here?s an example of something I?ve seen for debugging. I think that was kind
> of cool you could print types like that and I?m not sure how that would work
> in Pascal if at all. Maybe some RTTI magic perhaps.
>
> {$define typestr(t):='#t:
denisgolovan schrieb am Fr., 22. Juni 2018, 10:24:
> Generics are rather limited in that respect.
> At least some construction should exist to instantiate those generics.
> e.g. to create several public structs, interfaces, free functions
> (possibly instancing generics) in one go.
>
Do you
> On Jun 22, 2018, at 12:24 PM, Sven Barth via fpc-pascal
> wrote:
>
> If $Assertions is set to Off the complete Assert() line will be absent from
> the compiled code.
Good to know thanks.
Here’s an example of something I’ve seen for debugging. I think that was kind
of cool you could
> On Jun 22, 2018, at 3:24 PM, denisgolovan wrote:
>
> On the other hand, recent language Rust has macros nicely integrated in
> language itself and they plan to extend them in 2.0 version.
> D language also has mixins. Let alone Lisp-dynamics derivatives.
Please post some examples if you
> C was designed from the ground up with preprocessing. Pascal, and most newly
> designed languages, do not have preprocessing built-in. For good reason.
Well. I can't agree.
C macros are bolted on :). It's too alien for main part of language. No respect
to captured variables, no operator
On Fri, 22 Jun 2018, Ryan Joseph wrote:
On Jun 22, 2018, at 12:21 PM, Michael Van Canneyt
wrote:
'Nice' is not an argument.
If someone else assumes that assert() works as expected - i.e. throws an
exception, then your macro will mess up his code, leading to
unpredictable results.
> On Jun 22, 2018, at 12:21 PM, Michael Van Canneyt
> wrote:
>
> 'Nice' is not an argument.
>
> If someone else assumes that assert() works as expected - i.e. throws an
> exception, then your macro will mess up his code, leading to
> unpredictable results.
>
> From my - admittedly
Am 22.06.2018 um 06:35 schrieb Ryan Joseph:
Here’s a macro I like from C. It captures the assert expression and prints it
back out into the console (it would halt the program also). Can this be done in
Pascal? In C they return the file name and line number also which is really
nice.
{$define
On Fri, 22 Jun 2018, Ryan Joseph wrote:
On Jun 22, 2018, at 3:19 AM, Marc Santhoff wrote:
function HOFFSETP(rectypevar: pointer; fieldvar: pointer): longint; inline;
begin
HOFFSETP := longint(fieldvar - rectypevar);
end;
H5Tinsert(s2_tid, 'c_name', HOFFSETP(@s2[0], @s2[0].c),
> On Jun 22, 2018, at 3:19 AM, Marc Santhoff wrote:
>
> function HOFFSETP(rectypevar: pointer; fieldvar: pointer): longint; inline;
> begin
> HOFFSETP := longint(fieldvar - rectypevar);
> end;
>
> H5Tinsert(s2_tid, 'c_name', HOFFSETP(@s2[0], @s2[0].c), H5T_NATIVE_DOUBLE);
>
On Thu, 2018-06-21 at 22:25 +0700, Ryan Joseph wrote:
> >
> I did a search and found only a few hits on the topic. Since I’ve been
> giving theoretical examples here’s something more practical a user
> attempted. Can you do that without macros? If I had to guess he had some
> funky code and just
Am 21.06.2018 um 17:25 schrieb Ryan Joseph:
On Jun 21, 2018, at 10:08 PM, Sven Barth via fpc-pascal
wrote:
For more questions you can start a thread in fpc-devel. That's the purpose of
that mailing list after all.
Thanks, I’ll post there tomorrow about the technical stuff.
At first
On 6/21/2018 8:08 AM, Sven Barth via fpc-pascal wrote:
Of course you have permission to work on this, after all this is Open
Source software. However whether we'd want to integrate this is a
totally different topic.
I personally am against it, cause I see no real world use in it and
the
> On Jun 21, 2018, at 10:08 PM, Sven Barth via fpc-pascal
> wrote:
>
> For more questions you can start a thread in fpc-devel. That's the purpose of
> that mailing list after all.
>
Thanks, I’ll post there tomorrow about the technical stuff.
At first glance unless I totally underestimate
Ryan Joseph schrieb am Do., 21. Juni 2018,
15:53:
> I’m actually making rapid progress on a macro function syntax where the
> parameters are replaced by the inputs when called:
>
> {$define put(x):='into_x’}
>
> put(100); // replaces to ‘into_100’
>
> Do I have permission to develop this feature
I’m actually making rapid progress on a macro function syntax where the
parameters are replaced by the inputs when called:
{$define put(x):='into_x’}
put(100); // replaces to ‘into_100’
Do I have permission to develop this feature (even if it’s hidden behind a
modeswitch) and if so should I
Ryan Joseph schrieb am Do., 21. Juni 2018,
08:37:
>
>
> > On Jun 21, 2018, at 1:21 PM, Ryan Joseph
> wrote:
> >
> > Thanks Sven. So it was the Lazarus step I was missing! I know about
> using “lazbuild” from the command line but there are many .lpi projects in
> /compiler. Which one is ppc386?
> On Jun 21, 2018, at 1:21 PM, Ryan Joseph wrote:
>
> Thanks Sven. So it was the Lazarus step I was missing! I know about using
> “lazbuild” from the command line but there are many .lpi projects in
> /compiler. Which one is ppc386? I see ppcx64.lpi but not ppc386.
I figured out how to
> On Jun 21, 2018, at 12:51 PM, Sven Barth via fpc-pascal
> wrote:
>
> As long as you don't change code that is related to reading from or writing
> to PPU files it's enough to do a "make clean all" in the top level directory
> once after an "svn up" and then build the compiler inside
Ryan Joseph schrieb am Do., 21. Juni 2018,
05:30:
>
>
> > On Jun 20, 2018, at 10:57 PM, Marc Santhoff wrote:
> >
> > When I looked around it was in
> >
> > scanner.pas
> > symsym.pas
> >
> > Just grep for "macro".
> >
> > If there is more or I'm wrong hopefully one of the "compiler guys" will
>
> On Jun 20, 2018, at 10:57 PM, Marc Santhoff wrote:
>
> When I looked around it was in
>
> scanner.pas
> symsym.pas
>
> Just grep for "macro".
>
> If there is more or I'm wrong hopefully one of the "compiler guys" will help
> out here, please. ;)
Thanks for the tips. One of the first
> On Jun 21, 2018, at 12:21 AM, Marco van de Voort wrote:
>
> That would be C incompatible, which I thought was the main reason to have
> it? It would also replace me in identifiers (like 'varwithme'), which C
> afaik wouldn't without ##
That was just a stupid example but it was meant to
Am 20.06.2018 um 10:33 schrieb Ryan Joseph:
Are there any plans to make a proper preprocessor like #define in C?
No.
1.
From http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html:
> Pascal
>The compiler won't let you shoot yourself in the foot.
2.
The unit concept renders
On 20/06/18 17:30, Marco van de Voort wrote:
That would be C incompatible, which I thought was the main reason to haveit?
I don't believe Ryan said that (and I certainly didn't). It's the
functionality that counts, not slavish adherence to any particular syntax.
--
Mark Morgan Lloyd
In our previous episode, Ryan Joseph said:
> > On Jun 20, 2018, at 10:02 PM, Michael Van Canneyt
> > wrote:
> >
> > Because it is a simple textual token replacement at present. Supporting
> > arguments would mean parsing the macro, parsing whatever comes after it,
> > matching the arguments
Ryan Joseph schrieb am Mi., 20. Juni 2018,
17:41:
>
>
> > On Jun 20, 2018, at 10:02 PM, Michael Van Canneyt <
> mich...@freepascal.org> wrote:
> >
> > Because it is a simple textual token replacement at present. Supporting
> arguments would mean parsing the macro, parsing whatever comes after
Mark Morgan Lloyd schrieb am Mi., 20.
Juni 2018, 18:38:
> On 20/06/18 14:45, Marc Santhoff wrote:
> > But I speak up for another reason:
> > Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in
> compilersource code, the lexer and parser part. IIRC there were some hooks
> for
On 20/06/18 16:00, Marc Santhoff wrote:
On Wed, 2018-06-20 at 22:45 +0700, Ryan Joseph wrote:> > On Jun 20, 2018, at 10:20 PM, Marc Santhoff
wrote:> > > > The spots where resolving single parameter macros is done are pretty easy> > to> > find. Parsing
the macro text and replacement will be
On 20/06/18 14:45, Marc Santhoff wrote:
But I speak up for another reason:
Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in
compilersource code, the lexer and parser part. IIRC there were some hooks for
callinga proprocessor in the code at that time. If they are still there,
On Wed, 2018-06-20 at 22:45 +0700, Ryan Joseph wrote:
> > On Jun 20, 2018, at 10:20 PM, Marc Santhoff wrote:
> >
> > The spots where resolving single parameter macros is done are pretty easy
> > to
> > find. Parsing the macro text and replacement will be the hardest part, as
> > Michael wrote. A
> On Jun 20, 2018, at 10:20 PM, Marc Santhoff wrote:
>
> The spots where resolving single parameter macros is done are pretty easy to
> find. Parsing the macro text and replacement will be the hardest part, as
> Michael wrote. A bit of housekeeping for parameter-type lists, etc...
Easy? I’ve
> On Jun 20, 2018, at 10:02 PM, Michael Van Canneyt
> wrote:
>
> Because it is a simple textual token replacement at present. Supporting
> arguments would mean parsing the macro, parsing whatever comes after it,
> matching the arguments etc. A whole added layer of complexity.
It’s like a
On Wed, 2018-06-20 at 21:34 +0700, Ryan Joseph wrote:
> My impression was it was trivial extension to the current macros system but
> the compiler team was adverse to the idea because it creates “bad code” and
> all the other (very reasonable) reasons to not use macros in code (I read
> some old
> On Jun 20, 2018, at 9:54 PM, Martin Schreiber wrote:
>
> Isn't this obfuscation by
> definition?
Indeed it is. I really do agree 100% but strangely enough it doesn’t matter. :)
Keep in mind often we’re writing code that only ourselves will ever see and we
don’t need any justification to
> On Jun 20, 2018, at 9:06 PM, Michael Van Canneyt
> wrote:
>
> So, it really is not dogma, but a simple weighing of pros and cons.
Thanks for your input guys. If it’s going to mess up PPUs and break things then
that I’m satisfied that’s a good enough reason not to include it.
My
> On Jun 20, 2018, at 9:16 PM, Mark Morgan Lloyd
> wrote:
>
>> How can you integrate a preprocessor without misaligning error messages and
>> debugging information?
>
> I forget the detail but some language implementations have pragmata which
> tell subsequent processing steps that at this
On Wed, 20 Jun 2018, Ryan Joseph wrote:
On Jun 20, 2018, at 9:26 PM, Marc Santhoff wrote:
Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in compiler
source code, the lexer and parser part. IIRC there were some hooks for calling
a proprocessor in the code at that time. If
On Wednesday 20 June 2018 16:38:10 Ryan Joseph wrote:
> > On Jun 20, 2018, at 9:21 PM, Martin Schreiber wrote:
> >
> > Macros are the worst code obfuscating feature ever.
>
> Ironically everyone agrees but back to my original point that’s just dogma
> (sorry I said it!). If I was doing C I
> On Jun 20, 2018, at 9:26 PM, Marc Santhoff wrote:
>
> Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in compiler
> source code, the lexer and parser part. IIRC there were some hooks for calling
> a proprocessor in the code at that time. If they are still there, wouldn't it
>
> On Jun 20, 2018, at 9:21 PM, Martin Schreiber wrote:
>
> Macros are the worst code obfuscating feature ever.
Ironically everyone agrees but back to my original point that’s just dogma
(sorry I said it!). If I was doing C I wouldn’t refuse to use the macros to
solve simple problems because
On Wed, 2018-06-20 at 15:09 +0200, Michael Van Canneyt wrote:
>
> On Wed, 20 Jun 2018, Mark Morgan Lloyd wrote:
>
> > The other alternative would be break the compiler in such a way that it
> > was usable from a standard makefile, but since there isn't separate
> > compilation of definition
On Wed, 20 Jun 2018, Martin Schreiber wrote:
On Wednesday 20 June 2018 16:06:13 Michael Van Canneyt wrote:
Please stop calling it 'dogma'.
As with all features, it is a trade-off between the burden this places on
the compiler (and the people maintaining it) and the expected gain.
And the
On Wednesday 20 June 2018 16:06:13 Michael Van Canneyt wrote:
>
> Please stop calling it 'dogma'.
>
> As with all features, it is a trade-off between the burden this places on
> the compiler (and the people maintaining it) and the expected gain.
>
And the damage it causes on readability of code.
On 20/06/18 13:45, Ryan Joseph wrote:
On Jun 20, 2018, at 8:09 PM, Michael Van Canneyt wrote:> > Nothing stops
people from preprocessing their code if they need really> advanced preprocessing: The toolchain can handle
it already.> > But there is no need to integrate it in the compiler and
In our previous episode, Michael Van Canneyt said:
> Till now, the burden of preprocessing is considered simply too big for the
> gain.
>
> One consequence, for example, is that the ppu files are thrown out of the
> window. The compiler would have to compile every used unit every time again,
>
On Wed, 20 Jun 2018, Ryan Joseph wrote:
On Jun 20, 2018, at 8:09 PM, Michael Van Canneyt wrote:
Nothing stops people from preprocessing their code if they need really
advanced preprocessing: The toolchain can handle it already.
But there is no need to integrate it in the compiler and
In our previous episode, Ryan Joseph said:
> > If the preprocessor really does such extended work, can't one simply keep
> > the intermediate output of the preprocessor as a source file and then
> > relate to that?
>
> Then you have 2 versions of the source code right?
No. One source, and one
In our previous episode, Ryan Joseph said:
> >
> > I've done my fair share of language advocacy in the past and in general am
> > no friend of C, but I suggest that a number of people- on both the "pure"
> > and the "pragmatic" sides of the argument- could very much do with "cooling
> > it".
>
> On Jun 20, 2018, at 5:54 PM, Schindler Karl-Michael
> wrote:
>
> If the preprocessor really does such extended work, can't one simply keep the
> intermediate output of the preprocessor as a source file and then relate to
> that?
Then you have 2 versions of the source code right? I
In our previous episode, Ryan Joseph said:
> > complicating it even more. The consequences of such a step are far-reaching.
> >
> > And till now, no-one has presented the really pressing use cases that would
> > warrant such a step.
>
> How can you integrate a preprocessor without misaligning
> On Jun 20, 2018, at 6:36 PM, Giuliano Colla
> wrote:
>
> A #define makes it possible to compare the two solutions with the same
> efficiency you'll get in the final version. A workaround, such as an extra
> procedure which does the same job, generates some extra code and may not tell
>
> On Jun 20, 2018, at 6:37 PM, Mark Morgan Lloyd
> wrote:
>
> I've done my fair share of language advocacy in the past and in general am no
> friend of C, but I suggest that a number of people- on both the "pure" and
> the "pragmatic" sides of the argument- could very much do with "cooling
> On Jun 20, 2018, at 8:09 PM, Michael Van Canneyt
> wrote:
>
> Nothing stops people from preprocessing their code if they need really
> advanced preprocessing: The toolchain can handle it already.
>
> But there is no need to integrate it in the compiler and thus needlessly
> complicating it
In our previous episode, Michael Van Canneyt said:
>
> Nothing stops people from preprocessing their code if they need really
> advanced preprocessing: The toolchain can handle it already.
>
> But there is no need to integrate it in the compiler and thus needlessly
> complicating it even more.
On Wed, 20 Jun 2018, Mark Morgan Lloyd wrote:
The other alternative would be break the compiler in such a way that it
was usable from a standard makefile, but since there isn't separate
compilation of definition and implementation parts this would probably
impact on type safety. I believe
On 20/06/18 10:00, Ryan Joseph wrote:
On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt wrote:>
> Because it is simply a bad idea ?
Yeah that’s what the programming gurus in ivory towers and professors keep
saying but what about the person actually trying to finish some work? It really
sucks
Il 20/06/2018 12:14, Michael Van Canneyt ha scritto:
If you need a preprocessor, maybe you simply need to rethink your design.
If you could explain your actual problem, maybe we can help solving it
without resorting to preprocessing.
In my experience a preprocessor comes handy mainly during
> Am 20.06.2018 um 12:00 schrieb fpc-pascal-requ...@lists.freepascal.org:
>
> Date: Wed, 20 Jun 2018 16:25:39 +0700
> From: Ryan Joseph
> To: FPC-Pascal users discussions
> Subject: Re: [fpc-pascal] Proper preprocessor?
> Message-ID:
> Content-Type: text/plain;
On Wed, 20 Jun 2018, Ryan Joseph wrote:
On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt wrote:
Because it is simply a bad idea ?
Yeah that’s what the programming gurus in ivory towers and professors keep
saying but what about the person actually trying to finish some work? It
really
On Wed, 20 Jun 2018 16:25:39 +0700
Ryan Joseph wrote:
> > On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt
> > wrote:
> >
> > Because it is simply a bad idea ?
>
> Yeah that’s what the programming gurus in ivory towers and professors keep
> saying but what about the person actually trying
> On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt
> wrote:
>
> Because it is simply a bad idea ?
Yeah that’s what the programming gurus in ivory towers and professors keep
saying but what about the person actually trying to finish some work? It really
sucks trying to fight the compiler
On Wed, 20 Jun 2018, Ryan Joseph wrote:
Are there any plans to make a proper preprocessor like #define in C? I’m
not saying this is good programming practice or anything but I just had a
really annoying copy and paste chore on some temporary code which I could
have easily accomplished if I
Are there any plans to make a proper preprocessor like #define in C? I’m not
saying this is good programming practice or anything but I just had a really
annoying copy and paste chore on some temporary code which I could have easily
accomplished if I had #define like in C. It’s such a trivial
77 matches
Mail list logo
