Proper preprocessor?

classic Classic list List threaded Threaded
77 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Proper preprocessor?

Ryan Joseph
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 thing to add I wonder why it was never included in Pascal.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Michael Van Canneyt


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 had #define like in C.  It’s such a trivial
> thing to add I wonder why it was never included in Pascal.

Because it is simply a bad idea ?

Pascal has some trivial macro support. {$define m:=xyz}

If you need more than that, you can use m4 or so. Lazarus has support for
pre-compile commands, so you can always configure it to preprocess your
files if you are so inclined.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Ryan Joseph


> On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt <[hidden email]> 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 sometimes because of engrained dogma.

How does an external preprocessor work if the compiler doesn’t about it? Doesn’t it totally mess up the line numbers for debugging? I’d happily write my own even if it was compatible with the compiler.

>
> Pascal has some trivial macro support. {$define m:=xyz}
>
> If you need more than that, you can use m4 or so. Lazarus has support for
> pre-compile commands, so you can always configure it to preprocess your
> files if you are so inclined.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Mattias Gaertner
On Wed, 20 Jun 2018 16:25:39 +0700
Ryan Joseph <[hidden email]> wrote:

> > On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt <[hidden email]> 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 sometimes because of engrained dogma.

It's your dogma, that only professors dislike macros.

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Michael Van Canneyt
In reply to this post by Ryan Joseph


On Wed, 20 Jun 2018, Ryan Joseph wrote:

>
>
>> On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt <[hidden email]> 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 sometimes because of engrained
> dogma.
There are plenty of languages out there without preprocessor support.
People manage to program without it just fine. No dogma is involved.

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.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Schindler Karl-Michael-2
In reply to this post by Ryan Joseph


> Am 20.06.2018 um 12:00 schrieb [hidden email]:
>
> Date: Wed, 20 Jun 2018 16:25:39 +0700
> From: Ryan Joseph <[hidden email]>
> To: FPC-Pascal users discussions <[hidden email]>
> Subject: Re: [fpc-pascal] Proper preprocessor?
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8
>
> How does an external preprocessor work if the compiler doesn’t about it? Doesn’t it totally mess up the line numbers for debugging?
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?

I did quite some work in transposing C header files to Pascal. Most of the defines could simply be converted into const statements by h2pas.

For more elaborate stuff, like versions of installed C libs and such, the usual tools known C programming (m4, configure, …) can be used (Ultrastar Deluxe has quite some use of them), as already mentioned by Michael Van Canneyt. Due to their complexity, I would avoid them as much as possible.

My 2 cents - MiSchi.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Giuliano Colla
In reply to this post by Michael Van Canneyt
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 the
development of an application. E.g.: you need to evaluate if solution A
is better than solution B, and each solution involves calling a
different procedure with a different number of parameters, in dozens of
points of your code.

This is an example from a C program:

> #define CON_TMAX #ifdef CON_TMAX #define AspettaRisposta(x,y,z) SMD
> aspetta_risp(y,z) #else #define AspettaRisposta(x,y,z) SMD rqwait(x,z)
> #endif

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 you the full story.

It's not matter of rethinking the design, but of picking up the best design.

Just my 2 cents

Giuliano
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Mark Morgan Lloyd-5
In reply to this post by Ryan Joseph
On 20/06/18 10:00, Ryan Joseph wrote:
>> On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt <[hidden email]> 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 sometimes because of engrained dogma.

> How does an external preprocessor work if the compiler doesn’t about it? Doesn’t it totally mess up the line numbers for debugging? I’d happily write my own even if it was compatible with the compiler.

>>> Pascal has some trivial macro support. {$define m:=xyz}> > If you need more than that, you can use m4 or so. Lazarus has support for> pre-compile commands, so you can always configure it to preprocess your> files if you are so inclined.

We've been here before, and not long ago.

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".

I'm pretty sure that the preprocessor issue was discussed a few months
ago with somebody pointing out that the Pascal compiler's macro handling
was deficient in that it had no concept of parameters. I believe that
the consensus was that it might possibly be desirable for the compiler
to be able to invoke an external preprocessor for the main unit and then
for each one that it imported, but that we didn't get as far as
considering its implications for include files etc.

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 that this too has been debated in the
past, and has attracted even less enthusiasm than a hook for an extrnal
preprocessor preprocessor.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Michael Van Canneyt


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 that this too has been debated in the
> past, and has attracted even less enthusiasm than a hook for an extrnal
> preprocessor preprocessor.

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. 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.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Marco van de Voort
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. 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.

(note that external preprocessing also creates an extra level above FPC
preprocessing. There is no conflict between those, because external is
always first.

I agree fully with Michael. It is the usual "if all you have is a hammer"
argument)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Ryan Joseph
In reply to this post by Michael Van Canneyt


> On Jun 20, 2018, at 8:09 PM, Michael Van Canneyt <[hidden email]> 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 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 error messages and debugging information? I would have already done this myself if I thought it was possible. A way to hook into the compiler to run external programs would be very handy and let us craft our own solutions without adding junk into the compiler.

I put this into the category of dogma because we’re being asked to provide “valid” use cases instead of trusting that we have know what’s best for our own code. It’s not possible to know in advance what people may need so providing them good tools as a fail safe is only sensible.

My own case I had just know was hard coded some vertex data from a C program and if I had a good macro syntax I could have finished it much quicker and it would have looked nicer. It doesn’t matter if this was “best practice” or not. I just wanted to finish it so I could move on to more important things.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Ryan Joseph
In reply to this post by Mark Morgan Lloyd-5


> On Jun 20, 2018, at 6:37 PM, Mark Morgan Lloyd <[hidden email]> 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 it".

I don’t understand why there's so must resistance to letting programmers make ugly macro hacks if they want to. Why does anyone care if I have some edge case and I need a solution quickly which macros fulfill? The compiler should be helpful, not force into some programming paradigm and best practices etc.. etc…

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Ryan Joseph
In reply to this post by Giuliano Colla


> On Jun 20, 2018, at 6:36 PM, Giuliano Colla <[hidden email]> 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 you the full story.
>
> It's not matter of rethinking the design, but of picking up the best design.

This is the perfect example! I never thought of doing that myself and neither did other people, who despite that are trying to prevent even the possibility you could try. I don’t get it.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Marco van de Voort
In reply to this post by Ryan Joseph
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 error messages
> and debugging information?

Have the preprocessor generate some form of lineinfo that your IDE can mine?

> I put this into the category of dogma because we?re being asked to provide
> ?valid?  use cases instead of trusting that we have know what?s best for
> our own code.

Then trust us that we know our business with respect to the compiler
internals.

>  It?s not possible to know in advance what people may need
> so providing them good tools as a fail safe is only sensible.

Good and "fail" are horribly subjective here.
 
> My own case I had just know was hard coded some vertex data from a C
> program and if I had a good macro syntax I could have finished it much
> quicker and it would have looked nicer.  It doesn?t matter if this was
> ?best practice?  or not.  I just wanted to finish it so I could move on to
> more important things.

Which is an argument that can be made for every external language feature.
Not really convincing.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Ryan Joseph
In reply to this post by Schindler Karl-Michael-2


> On Jun 20, 2018, at 5:54 PM, Schindler Karl-Michael <[hidden email]> 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 personally would have a very difficult time trying to manage both branches and I guarantee I would make errors all the time where I typed into the wrong file and lost data. The compiler needs to be aware of the insertions so that it can offset the line numbers properly. Please correct me if I’m wrong though.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Marco van de Voort
In reply to this post by Ryan Joseph
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".
>
> I don?t understand why there's so must resistance to letting programmers
> make ugly macro hacks if they want to.

There is no resistance against using macro hacks. Use six layers of
preprocessors if you want to.

There is only resistance against us implementing and maintaining it.  And
fix the zillions of corner cases which will all come with similar reasoning
as yours.

We simply want to avoid spending the time on a major feature that we don't
believe in.

>  Why does anyone care if I have some edge case and I need a solution
> quickly which macros fulfill?  The compiler should be helpful, not force
> into some programming paradigm and best practices etc..  etc?

Why do we have to cater for every hypothetical edge case that you could
encounter? Tomorrow somebody wants space idented blocks to easier borrow
code from Python (and we will also tell him to take a hike).
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Marco van de Voort
In reply to this post by Ryan Joseph
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 temporary preprocessed form for the compiler which
you don't need to store. But there are many such temporary
digested forms, like assembler and .o's in FPC's case

True. Error handling would be a problem, but if you keep the hacky
constructs in separate files that is quite workable.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Michael Van Canneyt
In reply to this post by Ryan Joseph


On Wed, 20 Jun 2018, Ryan Joseph wrote:

>
>
>> On Jun 20, 2018, at 8:09 PM, Michael Van Canneyt <[hidden email]> 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 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 error messages
> and debugging information?  I would have already done this myself if I
> thought it was possible.  A way to hook into the compiler to run external
> programs would be very handy and let us craft our own solutions without
> adding junk into the compiler.
This will not solve your misalignment problem, and see below.

>
> I put this into the category of dogma because we’re being asked to provide
> “valid” use cases instead of trusting that we have know what’s best for
> our own code.  It’s not possible to know in advance what people may need
> so providing them good tools as a fail safe is only sensible.

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.
Gain can only be estimated by giving use case(s).

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,
since it has no idea what the user of the preprocessor can/will/wants to do.
Just as the C compiler is forced to do, by the way.

Second consequence is the generation of debug info: you need to work back to
the original source location. This places a restriction on the preprocessor,
since it somehow needs to communicate back the original source locations to the
compiler. etc.

Same is true for error locations, and so on.

Is there a workaround ? Yes, there is: you can do the preprocessing by
yourself. Lazarus is equipped for it. Use makefiles if you want.

Speed should be mentioned: all this will add another layer on top of the
compiler, which will aversely affect speed. People already complain about
speed...

So, it really is not dogma, but a simple weighing of pros and cons.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Marco van de Voort
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,
> since it has no idea what the user of the preprocessor can/will/wants to do.
> Just as the C compiler is forced to do, by the way.
>
> Second consequence is the generation of debug info: you need to work back to
> the original source location. This places a restriction on the preprocessor,
> since it somehow needs to communicate back the original source locations to the
> compiler. etc.
>
> Same is true for error locations, and so on.

And afaik you need to introduce (more?) line based parsing in the
preprocessor rather than a token stream. Just try to put #line or #define in
the middle of a statement in C.

This is also alien to pascal.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Proper preprocessor?

Mark Morgan Lloyd-5
In reply to this post by Ryan Joseph
On 20/06/18 13:45, Ryan Joseph wrote:
>> On Jun 20, 2018, at 8:09 PM, Michael Van Canneyt <[hidden email]> 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 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 error messages and debugging information?

I forget the detail but some language implementations have pragmata
which tell subsequent processing steps that at this point the source
should be considered to have come from such-and-such a line number in
such-and-such a file.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
1234