Proper preprocessor?

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

Re: Proper preprocessor?

Florian Klämpfl
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 macros often useless.

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

Such quick and dirty temp. code can be often easily created by the macro functionality of the use editor.
_______________________________________________
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 Marc Santhoff-2


> On Jun 20, 2018, at 10:57 PM, Marc Santhoff <[hidden email]> 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 things that ever stopped me from working on the compiler was doing incremental builds that don’t clean the entire build first and take like 5 minutes to compile.

On Mac this is the first command I use to build. Is there a way to do this but only compile changed files?

make FPC=/usr/local/lib/fpc/$BASEFPCVERSION/ppc386 OPT="-ap" distclean all -j 2

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


> On Jun 21, 2018, at 12:21 AM, Marco van de Voort <[hidden email]> 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 only capture hello(...) syntax. This fact alone makes it not very compatible with FPC’s current macros because it requires () in the identifier instead of a single word.

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?

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
Ryan Joseph <[hidden email]> schrieb am Do., 21. Juni 2018, 05:30:


> On Jun 20, 2018, at 10:57 PM, Marc Santhoff <[hidden email]> 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 things that ever stopped me from working on the compiler was doing incremental builds that don’t clean the entire build first and take like 5 minutes to compile.

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 Lazarus using the corresponding project and you can run it inside the IDE as well as long as you set the parameters and working dir correctly. And for outside building the binary is then located at compiler/<CPU>/pp. 

Regards, 
Sven 

_______________________________________________
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 21, 2018, at 12:51 PM, Sven Barth via fpc-pascal <[hidden email]> 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 Lazarus using the corresponding project and you can run it inside the IDE as well as long as you set the parameters and working dir correctly. And for outside building the binary is then located at compiler/<CPU>/pp.
>

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.

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


> On Jun 21, 2018, at 1:21 PM, Ryan Joseph <[hidden email]> 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 build the “pp” project (not sure if this is the right one) but I’m getting a PPU error now. What do I do about system.ppu?

Ryans-MacBook-Pro:fpc ryanjoseph$ /Developer/ObjectivePascal/fpc/compiler/i386/pp /Users/ryanjoseph/Downloads/macro_test.pas
Free Pascal Compiler version 3.1.1 [2018/06/21] for i386
Copyright (c) 1993-2018 by Florian Klaempfl and others
Target OS: Darwin for i386
Compiling /Users/ryanjoseph/Downloads/macro_test.pas
PPU Loading /usr/local/lib/fpc/3.1.1/units/i386-darwin/rtl/system.ppu
PPU Invalid Version 195
Fatal: Can't find unit system used by macro_test
Fatal: Compilation aborted

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?

Free Pascal - General mailing list
Ryan Joseph <[hidden email]> schrieb am Do., 21. Juni 2018, 08:37:


> On Jun 21, 2018, at 1:21 PM, Ryan Joseph <[hidden email]> 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.

pp.lpi is the i386 one (it was the first one, so no suffix ;)). 


I figured out how to build the “pp” project (not sure if this is the right one) but I’m getting a PPU error now. What do I do about system.ppu?

Ryans-MacBook-Pro:fpc ryanjoseph$ /Developer/ObjectivePascal/fpc/compiler/i386/pp /Users/ryanjoseph/Downloads/macro_test.pas
Free Pascal Compiler version 3.1.1 [2018/06/21] for i386
Copyright (c) 1993-2018 by Florian Klaempfl and others
Target OS: Darwin for i386
Compiling /Users/ryanjoseph/Downloads/macro_test.pas
PPU Loading /usr/local/lib/fpc/3.1.1/units/i386-darwin/rtl/system.ppu
PPU Invalid Version 195
Fatal: Can't find unit system used by macro_test
Fatal: Compilation aborted

You need to pass the correct parameters. I usually pass the following:

-n -Furtl/units/<CPU>-<OS> -viwn - FEtestoutput ./fpctests/mytest.pp

And set the current working directory to the top level directory of the checkout. 

testoutput and fpctests are two directories that I created in the top level directory to keep things clean. 

Regards, 
Sven 


_______________________________________________
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
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 privately contact someone on the compiler team to verify that I’m doing compiler approved things? I have lots of stupid questions like is “array of ansistring” ok and can I use strutils functions etc.. and I don’t want to pollute the list with them.


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?

Free Pascal - General mailing list
Ryan Joseph <[hidden email]> 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 (even if it’s hidden behind a modeswitch) and if so should I privately contact someone on the compiler team to verify that I’m doing compiler approved things? I have lots of stupid questions like is “array of ansistring” ok and can I use strutils functions etc.. and I don’t want to pollute the list with them.

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 usual point of making the code less readable applies as well. 

To answer your further questions: AnsiString should not be used and units that can be used are only those in the rtl directory. Everything inside packages is not available. You could however check the cutils unit for equivalent functionality. 

For more questions you can start a thread in fpc-devel. That's the purpose of that mailing list after all. 

Regards, 
Sven 

_______________________________________________
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 21, 2018, at 10:08 PM, Sven Barth via fpc-pascal <[hidden email]> 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 something it appears to be a trivial extension to the define:= syntax but admittedly it’s edge case stuff and probably not widely used.

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 wanted to reduce typing and copy/paste bugs.

{$define HOFFSET(rec,field) := pointer(@rec.field) - pointer(@rec)}

type
        s1_t = record
                a: longint;
                b: single;
                c: double;
        end;
var
        s1: s1_t;
BEGIN
        s1.a := 12345;
        s1.b := 1.000000001;
        s1.c := 1.000000002;

        writeln(HOFFSET(s1, a));
END.

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?

Ralf Quint
In reply to this post by Free Pascal - General mailing list
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 usual point of making the code less readable applies as well.
+1



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
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?

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
Am 21.06.2018 um 17:25 schrieb Ryan Joseph:

>
>> On Jun 21, 2018, at 10:08 PM, Sven Barth via fpc-pascal <[hidden email]> 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 something it appears to be a trivial extension to the define:= syntax but admittedly it’s edge case stuff and probably not widely used.
>
> 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 wanted to reduce typing and copy/paste bugs.
>
> {$define HOFFSET(rec,field) := pointer(@rec.field) - pointer(@rec)}
>
> type
>          s1_t = record
>                  a: longint;
>                  b: single;
>                  c: double;
>          end;
> var
>          s1: s1_t;
> BEGIN
>          s1.a := 12345;
>          s1.b := 1.000000001;
>          s1.c := 1.000000002;
>
>          writeln(HOFFSET(s1, a));
> END.

The officially sanctioned way is this:

@s1_t(nil^).a

Though I do have the idea to extend the Ofs() intrinsic to handle a type
expression as well. E.g. Ofs(s1.a) returns @s1.a, but I'd like
Ofs(s1_t.a) to return @s1_t(nil^).a.

Regards,
Sven
_______________________________________________
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?

Marc Santhoff-2
In reply to this post by Ryan Joseph
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 wanted to reduce typing and copy/paste bugs.
>
> {$define HOFFSET(rec,field) := pointer(@rec.field) - pointer(@rec)}

That funky code is the way some structured elements are defined when using
HDF5 file format library. It's pure C optimized for speed and my goal was to
adapt it to pascal. Using somesuch in C seems to be quite normal, it has an
entry in Wikipedia...

In the end I made the macro an inlined pascal function using the method of
"cruel casting"[tm]. After preprocessing C code should look similar.

<C>
#define HOFFSET(S,M)    (offsetof(S,M)) // offsetof is a standard define

H5Tinsert(s1_tid, "a_name", HOFFSET(s1_t, a), H5T_NATIVE_INT);
H5Tinsert(s1_tid, "c_name", HOFFSET(s1_t, c), H5T_NATIVE_DOUBLE);
</C>

<Pascal>
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);
H5Tinsert(s2_tid, 'a_name', HOFFSETP(@s2[0], @s2[0].a), H5T_NATIVE_INT);
</Pascal>


> type
>         s1_t = record
>                 a: longint;
>                 b: single;
>                 c: double;
>         end;
> var
>         s1: s1_t;
> BEGIN
>         s1.a := 12345;
>         s1.b := 1.000000001;
>         s1.c := 1.000000002;
>
>         writeln(HOFFSET(s1, a));
> END.
>
> Regards,
> Ryan Joseph
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--
Marc Santhoff <[hidden email]>
_______________________________________________
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 22, 2018, at 3:19 AM, Marc Santhoff <[hidden email]> wrote:

> <Pascal>
> 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);
> H5Tinsert(s2_tid, 'a_name', HOFFSETP(@s2[0], @s2[0].a), H5T_NATIVE_INT);
> </Pascal>

So there was a solution but I can see why the C macro version was easier to look at it. Was that not a good reason to use a macro? I like how the macro cleaned that up. Sven’s suggested answer of "@s1_t(nil^).a” is even more obscure imo.

If you guys don’t mind I may try to remember and collect the uses of macros I’ve wanted at random times through out the year and see if there is indeed not practical or good use for them in modern Pascal.

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 assert(x):=if not (x) then writeln('assert: x')}

var
        i: integer = 100;
begin
        assert(i = 101); // assert: i=101
end.


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 Fri, 22 Jun 2018, Ryan Joseph wrote:

>
>
>> On Jun 22, 2018, at 3:19 AM, Marc Santhoff <[hidden email]> wrote:
>
>> <Pascal>
>> 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);
>> H5Tinsert(s2_tid, 'a_name', HOFFSETP(@s2[0], @s2[0].a), H5T_NATIVE_INT);
>> </Pascal>
>
> So there was a solution but I can see why the C macro version was easier to look at it. Was that not a good reason to use a macro? I like how the macro cleaned that up. Sven’s suggested answer of "@s1_t(nil^).a” is even more obscure imo.
The above qualifies IMHO as definite proof that macros are for real corner cases.
It must have been somewhere in 1988 when I last needed such code.

>
> If you guys don’t mind I may try to remember and collect the uses of
> macros I’ve wanted at random times through out the year and see if there
> is indeed not practical or good use for them in modern Pascal.
>
> 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.

'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 subjective - point of view, your examples only serve to demonstrate
why we should definitely not support macros...

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?

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
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 assert(x):=if not (x) then writeln('assert: x')}
>
> var
> i: integer = 100;
> begin
> assert(i = 101); // assert: i=101
> end.
That directly can't be done, but Assert() in Pascal is nice (and quite
powerful) nevertheless:

=== code begin ===

program ttest;

{$Assertions on}

var
   i: LongInt;
begin
   i := 42;
   Assert(i = 21, 'Bla, Blubb');
end.

=== code end ===

This will print:

=== output begin ===

Bla, Blubb (ttest.pp, line 9).

=== output end ===

If $Assertions is set to Off the complete Assert() line will be absent
from the compiled code.

If unit SysUtils is included then a failed assertion results in an
EAssertionError though that can be changed by setting AssertErrorProc in
unit System. If unit System is not included then the line above will be
printed and the program terminated.

Regards,
Sven
_______________________________________________
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 22, 2018, at 12:21 PM, Michael Van Canneyt <[hidden email]> 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 subjective - point of view, your examples only serve to demonstrate why we should definitely not support macros...

For any example I can give it’s easy to extrapolate into some scenario where it would be a disaster. I get that. The reason I ever wanted to make a macro was for personal use to give some project specific meaning to some construct or a quick hack. Frameworks like Apple uses,  often use macros to document parts of code in a way which otherwise isn’t part of the language and no suitable for comments. I’m not saying this is how we all should program. I don’t suggest people go out and start using macros in place of functions.

Btw why was the $define:= syntax ever introduced in the first place? adding a parameter to the syntax is a minor extension but it sounds like Pascal programers here really don’t like it in general.

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 Fri, 22 Jun 2018, Ryan Joseph wrote:

>
>
>> On Jun 22, 2018, at 12:21 PM, Michael Van Canneyt <[hidden email]> 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 subjective - point of view, your examples only serve to demonstrate why we should definitely not support macros...
>
> For any example I can give it’s easy to extrapolate into some scenario where it would be a disaster. I get that. The reason I ever wanted to make a macro was for personal use to give some project specific meaning to some construct or a quick hack. Frameworks like Apple uses,  often use macros to document parts of code in a way which otherwise isn’t part of the language and no suitable for comments. I’m not saying this is how we all should program. I don’t suggest people go out and start using macros in place of functions.
>
> Btw why was the $define:= syntax ever introduced in the first place?
> adding a parameter to the syntax is a minor extension but it sounds like
> Pascal programers here really don’t like it in general.
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...

C was designed from the ground up with preprocessing. Pascal, and most newly
designed languages, do not have preprocessing built-in. For good reason.

Some cans are better left unopened. Or pandora's box is better left
closed... (if you prefer mythological references ;) )

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
In reply to this post by Free Pascal - General mailing list


> On Jun 22, 2018, at 12:24 PM, Sven Barth via fpc-pascal <[hidden email]> 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 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: '+IntToStr(sizeof(#t))}

program macro_test;
uses
        SysUtils;

type
        MyRecord = record
                x, y, z: single;
        end;

begin
        writeln(typestr(MyRecord)); // MyRecord: 12
end.

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?

denisgolovan
In reply to this post by Michael Van Canneyt


> 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 priorities, parsing is hard, etc.
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.
Those macros help a lot in intensive meta programming (read writing interpreters/compilers/introspection heavy applications) and reduce total line count considerably.

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.

My personal way of doing stuff like that is "m4 -> pas/inc" conversion and triggering them in makefiles.
Robust incremental pre-processing is quite affordable for make + m4 combination as well.
Again Rust macros being something in between C defines and m4 in terms of power are really pragmatic at times.

> Some cans are better left unopened. Or pandora's box is better left
> closed... (if you prefer mythological references ;) )

Again, different design philosophies lead to different design decisions.
Better less amount of code + more automatic consistence leading to more cryptic code (have a look at APL/J/... implementation) OR lots of boilerplate + less consistence, but much more readable for non-experts?
What about refactoring price in both scenarios? Open source projects have a variety of opinions on that.

But I generally support FreePascal team in avoiding features they personally don't extensively use :)

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