Re: [fpc-pascal] Proper preprocessor?
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;
>
> begin
> foo.SomeFunc;
> end.
>
> === code end ===
>
> Though more often than not such things are done by simply using a different
> set of units with the same names in a different unit path.
Because I was on the road, without my laptop, and I didn't want to
forget this :)
And your way is even better, thank you.
Best regards,
Marcos Douglas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 verbose syntax and by using
another meta-programming tactic, e.g. generics.
Nobody said meta-programming is bad. But the right approach should be used.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 using
another meta-programming tactic, e.g. generics.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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}
foo_debug
{$define foo := foo_debug}
{else}
foo_run;
{$define foo := foo_run}
{$enfif}
begin
foo.SomeFunc;
end;
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;
begin
foo.SomeFunc;
end.
=== code end ===
Though more often than not such things are done by simply using a
different set of units with the same names in a different unit path.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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}
foo_run;
{$define foo := foo_run}
{$enfif}
begin
foo.SomeFunc;
end;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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... Well, I think we (the people who decided to implement it) thought about the consequences. The chances to mess around with the currently implemented macro support is far less than with macros with parameters and concat operations. And the impact is limited imo. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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.
In trunk that can be done rather nicely:
=== code begin ===
program ttest;
{$mode objfpc}
uses
TypInfo;
type
TMyRecord = record
x, y, z: Single;
end;
generic function TypeStr: String;
var
ti: PTypeInfo;
begin
ti := PTypeInfo(TypeInfo(T));
WriteStr(Result, ti^.Name, ': ', SizeOf(T));
end;
begin
Writeln(specialize TypeStr);
end.
=== code end ===
Or even
program ttest;
{$mode objfpc}
uses
TypInfo;
type
TMyRecord = record
x, y, z: Single;
end;
generic function _TypeStr: String;
var
ti: PTypeInfo;
begin
ti := PTypeInfo(TypeInfo(T));
WriteStr(Result, ti^.Name, ': ', SizeOf(T));
end;
{$macro on}
{$define TypeStr:=specialize _TypeStr}
begin
Writeln(TypeStr);
end.
;)
Those people can also use mode Delphi if they want :P
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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.
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.
In trunk that can be done rather nicely:
=== code begin ===
program ttest;
{$mode objfpc}
uses
TypInfo;
type
TMyRecord = record
x, y, z: Single;
end;
generic function TypeStr: String;
var
ti: PTypeInfo;
begin
ti := PTypeInfo(TypeInfo(T));
WriteStr(Result, ti^.Name, ': ', SizeOf(T));
end;
begin
Writeln(specialize TypeStr);
end.
=== code end ===
Or even
program ttest;
{$mode objfpc}
uses
TypInfo;
type
TMyRecord = record
x, y, z: Single;
end;
generic function _TypeStr: String;
var
ti: PTypeInfo;
begin
ti := PTypeInfo(TypeInfo(T));
WriteStr(Result, ti^.Name, ': ', SizeOf(T));
end;
{$macro on}
{$define TypeStr:=specialize _TypeStr}
begin
Writeln(TypeStr);
end.
;)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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.
In trunk that can be done rather nicely:
=== code begin ===
program ttest;
{$mode objfpc}
uses
TypInfo;
type
TMyRecord = record
x, y, z: Single;
end;
generic function TypeStr: String;
var
ti: PTypeInfo;
begin
ti := PTypeInfo(TypeInfo(T));
WriteStr(Result, ti^.Name, ': ', SizeOf(T));
end;
begin
Writeln(specialize TypeStr);
end.
=== code end ===
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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. "ident!" is "calling"
other macros, but it's quite obvious I guess.
Last syntax expression is "application" of this macro resulting in actual
function creating and immediate compilation by Rust compiler.
macro_rules! to_string {
($($scalar:tt),*) => {
pub fn to_string(ast: , interpreter: ) -> AST {
match base_tp(ast.tp()) {
$(
$scalar => {
let aco=aco!($scalar, ast, Some(interpreter.alloc()));
let s=ato_str!(aco, aget!(aco, ast), interpreter);
new_string(, interpreter.alloc())
},
)*
$(
to_vec!($scalar) => {
let aco=aco!($scalar, ast, Some(interpreter.alloc()));
let v=ast.array::();
v.iter().map(|x| {
let s=ato_str!(aco, *x, interpreter);
new_string(, interpreter.alloc())
}).enlist(v.len(), interpreter.alloc())
}
)*
$(
to_deq!($scalar) => {
let aco=aco!($scalar, ast, Some(interpreter.alloc()));
let v=ast.vecdeq().head::();
v.iter().map(|x| {
let s=ato_str!(aco, *x, interpreter);
new_string(, interpreter.alloc())
}).enlist(v.len(), interpreter.alloc())
}
)*
x if is_nested(x) => atomic(ast, to_string, "to_string",
interpreter),
VEC_CHAR => (*ast).clone(),
_ => except!(eval_err!("cast: nyi.")),
}
}
}
}
to_string!(
SC_BOOL,
SC_BYTE,
SC_SHORT,
SC_INT,
SC_MONTH,
SC_DATE,
SC_MINUTE,
SC_SECOND,
SC_TIME,
SC_LONG,
SC_TIMESTAMP,
SC_DATETIME,
SC_TIMESPAN,
SC_SINGLE,
SC_DOUBLE,
SC_ENUM,
SC_SYMBOL,
SC_GUID
);
All in all my rough estimate for macro efficiency ratio is something like 12x
currently. That's about 12 times less code to type and support. YMMV, of course.
See
https://danielkeep.github.io/tlborm/book/mbe-min-captures-and-expansion-redux.html
for boring details on Rust macros.
BR,
Denis
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 exports. 4. Published functions/classes/ into interpreted languages That's more or less it. At least those I quickly gathered from real project. All these use cases I also have. But I use code generators for this. The source does not need to be pascal (although it can be). It just needs some structured format, from which Pascal code is then generated. Currently I employ code generators (written in pascal) that start from XML, JSON, IDL, or datasets (and in some limited cases pascal code). They generate the target code, plus unit test testsuites. using fcl-passrc it is really easy to generate bindings for e.g. lua or any other embedded pascal scripting tool. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 or any type supporting equality testing.
That user decision should influence container code and its manual code
optimizations, e.g. special cases like indexing, appending/removing/etc.
- are keys always sorted? => influences insertion, search, etc.
- values are primitive types (not having destruction phase - just dealloc) or
it should call Finalize/Free/"Assign nil" on destroying.
- if values are records - all accessors should return pointers instead to be
able to modify fields without "read, modify, write" ceremonies.
- does structure generate events on insertion/deleting/etc? => influences event
property declarations + actual code to trigger those
- what kind of interface user prefers for the container - class, record,
interface with reference counting or any combination of those?
- all its generic functions like map, filter, destructive map, etc. should be
overloaded functions existing both as structure methods and free form (globals
with additional argument). Their argument should accept all kinds of callbacks
- simple functions, methods ("of object" type), nested ("is nested") and
possibly future "reference" (closure FPC does not support yet).
- grow strategy - user-defined, with given coefficient, etc.
... currently all above is generated using m4 producing entire FPC module.
That's old times philosophy - structures amount is small, functions to work
with them are numerous and coherently named. Something similar to C++ STL, but
without exponential build times and more tailored to users' needs.
2. Meta declarations for global entities with names/ids/descriptions/etc.
The mechanism to create it must have enough flexibility to define/parametrize
at compile-time in one go:
- create Pascal native declarations as enums
- create Pascal functions to convert to/from strings/integers/etc
- create overloaded serialization functions for XML, streams, etc.
- create foreign code declaration (C, Lua, etc.)
- native Pascal foreign code marshalling (e.g. Pascal <-> Lua via Lua stack)
3. Dynamic libraries exports.
The mechanism to create it must have enough flexibility to define/parametrize
at compile-time in one go:
- compile in Pascal "generics" / m4 templates to support other processes /
languages
- exported functions should accessible via specific foreign import (e.g. it
should generate corresponding header files for use in C/C++)
4. Published functions/classes/ into interpreted languages
- just declare which classes and their methods should be accessible e.g. from
Lua and code should generated for make it happen.
- FFI import/export - declare functions / types / names - get boilerplate to
make it happen.
That's more or less it.
At least those I quickly gathered from real project.
--
Regards,
Denis Golovan
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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: http://wiki.freepascal.org/Mode_MacPas Eh, no. I think macros predate macpas mode. But exported macros were indeed introduced for mode macpas. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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... > They were added for MacPascal compatibility: http://wiki.freepascal.org/Mode_MacPas Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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: '+IntToStr(sizeof(#t))}
(highlights not having an open array of byte like syntax that also conveys
size)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 have examples here? Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 have them, I’m curious. :) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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. 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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), H5T_NATIVE_DOUBLE); H5Tinsert(s2_tid, 'a_name', HOFFSETP(@s2[0], @s2[0].a), H5T_NATIVE_INT); 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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);
> H5Tinsert(s2_tid, 'a_name', HOFFSETP(@s2[0], @s2[0].a), H5T_NATIVE_INT);
>
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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.
#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);
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);
> type
> s1_t = record
> a: longint;
> b: single;
> c: double;
> end;
> var
> s1: s1_t;
> BEGIN
> s1.a := 12345;
> s1.b := 1.1;
> s1.c := 1.2;
>
> writeln(HOFFSET(s1, a));
> END.
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--
Marc Santhoff
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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.1;
s1.c := 1.2;
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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.1;
s1.c := 1.2;
writeln(HOFFSET(s1, a));
END.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 (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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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? 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/- -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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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//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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 > 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//pp. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 etc. A whole added layer of complexity.
>
> It?s like a simplified regular expression. Capture anything inside () on the
> left side and replace occurrences on the right side.
>
> {$define hello(me) := writeln(?hello me')}
>
> hello(world) becomes writeln(?hello world?)
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 ##
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 it,
> matching the arguments etc. A whole added layer of complexity.
>
> It’s like a simplified regular expression. Capture anything inside () on
> the left side and replace occurrences on the right side.
>
> {$define hello(me) := writeln(‘hello me')}
>
> hello(world) becomes writeln(‘hello world’)
>
In Pascal you'd use inline functions for this one though of course with
strong typing and not some identifier that both a human and the IDE will
have to guess what it is.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 callinga proprocessor in the code at that time. If they are still > there, wouldn't itbe a solution for both sides? > > The compiler programmers only have to activate (or complete) a way to > call apreprocessor, solving the problem of mangled error messages. > > The preprocessor user could implement whatever is needed on his or her > side? > > My 2 cent,Marc > > Is that what the PREPROCWRITE define is for? > That is merely for the ability to output a preprocessed source file after all the compiler directives and macros have been handled. AFAIK it hasn't worked for a long time... Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 the hardest part, as> > Michael wrote. A bit of housekeeping for parameter-type lists,
etc...> > Easy? I’ve wanted to contribute to the compiler for years but it’s so> daunting finding anything I give up. I’m
curious how the parser works so> please show me where the parser does the $defines. Maybe I can figure it out> this time.
When I looked around it was in
scanner.passymsym.pas
Just grep for "macro".
If there is more or I'm wrong hopefully one of the "compiler guys" will helpout
here, please. ;)
Word of caution: IIRC macros only work properly in comments delimited by
braces {}
--
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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, wouldn't itbe a solution for both sides? The compiler programmers only have to activate (or complete) a way to call apreprocessor, solving the problem of mangled error messages. The preprocessor user could implement whatever is needed on his or her side? My 2 cent,Marc Is that what the PREPROCWRITE define is for? My 1½d :-) -- 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 bit of housekeeping for parameter-type lists, etc... > > Easy? I’ve wanted to contribute to the compiler for years but it’s so > daunting finding anything I give up. I’m curious how the parser works so > please show me where the parser does the $defines. Maybe I can figure it out > this time. 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. ;) -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 wanted to contribute to the compiler for years but it’s so daunting finding anything I give up. I’m curious how the parser works so please show me where the parser does the $defines. Maybe I can figure it out this time. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 simplified regular expression. Capture anything inside () on the
left side and replace occurrences on the right side.
{$define hello(me) := writeln(‘hello me')}
hello(world) becomes writeln(‘hello world’)
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 threads to this effect). It’s hard to understand why the current > macros can’t be extended so I suspect this issue will just keep coming up > over and over again. If it's that important to you, do it yourself. The compiler is open source, pure, readable pascal. 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... -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 do something non-standard or otherwise very stupid. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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 threads to this effect). It’s hard to understand why the current macros can’t be extended so I suspect this issue will just keep coming up over and over again. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 point the source should be
> considered to have come from such-and-such a line number in such-and-such a
> file.
I think you’re right but that’s internal to the compiler and not really
something we can replicate ourselves. In fact that’s what the $include
directive does right? Again correct me if I’m wrong but I think $define:= does
the same thing otherwise column numbers (at least) in error messages would be
misaligned.
If macros took parameters it’s the same as before it just includes some extra
text. I keep saying it but it’s really difficult to understand why this is
compiler breaking stuff.
{$define foo(xx) := DoFoo(xx)}
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 they are still there, wouldn't it be a solution for both sides? I hope that’s not true. :) Marco says otherwise but it’s hard to imagine why the current $define:= couldn’t take an argument. 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. I’m sorry to say for the compiler team this issue is just going to come up over and over because programmers are going to be confused as to why the current macros don’t take parameters. To put things in perspective: in 25 years it came up only a handful of times. So I'm not inclined to perceive it as a pressing problem... Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 wouldn’t refuse to use the macros to > solve simple problems because “there the worst code obfuscating feature > ever”. > > At the end of the day I just want to be happy and productive programming. > If a macro helps me do that then so be it. Life’s too short. > I daily read code from many people. Beleave me, “there the worst code obfuscating feature ever” is one of the most proven in use dogma ever. ;-) That you will not misuse it does not mean nobody will misuse it. The C-example which has been provided looks like a misuse for me. Macros replace text in code with something other which can be anything. Isn't this obfuscation by definition? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 > be a solution for both sides? I hope that’s not true. :) Marco says otherwise but it’s hard to imagine why the current $define:= couldn’t take an argument. I’m sorry to say for the compiler team this issue is just going to come up over and over because programmers are going to be confused as to why the current macros don’t take parameters. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 “there the worst code obfuscating feature ever”. At the end of the day I just want to be happy and productive programming. If a macro helps me do that then so be it. Life’s too short. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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. The only use case for me would be macros having more than one parameter, needed when translating C-code. 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 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 be a solution for both sides? The compiler programmers only have to activate (or complete) a way to call a preprocessor, solving the problem of mangled error messages. The preprocessor user could implement whatever is needed on his or her side? My 2 cent, Marc -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 damage it causes on readability of code. Every new language feature will be used, every new language feature forces all programmers which have to read code from others to learn the new features. This is especially important for languages which are established in open source world. Macros are the worst code obfuscating feature ever. Exactly... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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. Every new language feature will be used, every new language feature forces all programmers which have to read code from others to learn the new features. This is especially important for languages which are established in open source world. Macros are the worst code obfuscating feature ever. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 > 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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; 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. signature.asc Description: Message signed with OpenPGP ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
> 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 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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
