macros in perl

[marc0]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I'm new to perl.

How it's possible to write macros in perl?

C-like macros would be OK.

I can find nothing in the perl manual (the one at perldoc.com).

Or macros are just considered a Bad Thing in Perl?

- --
(e-mail address removed) http://www.autistici.org/marc0
(rot13-string "(e-mail address removed)")
2143 9E77 D5E6 115A 48AD A170 D0EE F736 4E88 99C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/FRuM0O73Nk6ImcIRAqD5AKCqm807OlD/6YBiLYN/tOSHsSi1SQCg6zB5
kCIyGlQ2QCl0O9B+3+XPUoc=
=WobI
-----END PGP SIGNATURE-----

 

[John W. Krahn]

I'm new to perl.

How it's possible to write macros in perl?

C-like macros would be OK.

Yes, use the -P command line switch.

perldoc perlrun


John

 

[Stephane G. Titard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I'm new to perl.

How it's possible to write macros in perl?

C-like macros would be OK.

I can find nothing in the perl manual (the one at perldoc.com).

Or macros are just considered a Bad Thing in Perl?

Well, most of the time you don't need them.
you should ask yourself where you want them?
perl data structures grow at need, if you need some global defaults
you might wrap it in a small config module (Like the CPAN's one for
example)

anyway you can use

use constant MAX_LENGTH => 20;

better to put this at the beginning of your code in a BEGIN BLOCK
to protect against some redefinition...
(this defines internally some subroutine which is optimized)

HTH
stephan

 

[marc0]

#define walk_file(FILE) for ($walk_file_line = <FILE>)
s/for/while/


walk_file (FILE) {
...
}

 

[David K. Wall]

In the Perl script I'm working on I would use it to write something
like

#define walk_file(FILE) for ($walk_file_line = <FILE>)

walk_file (FILE) {
...
}

and alike.

That's not necessary but IMHO it helps to make the code more clear.

What's wrong with

while (<FILE>) {
# do stuff with $_ instead of $walk_file_line
}

? It's the usual idiom; using something else seems like obfuscation
to me.

 

[marc0]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What's wrong with

while (<FILE>) {
# do stuff with $_ instead of $walk_file_line
}

? It's the usual idiom; using something else seems like obfuscation
to me.

I was not aware that $_ works with other things than subroutines, good
to know, that's fine, thank you.

IMHO the point in using long and specific names instead of the general
purpose ones is that you can guess what the variable/piece-of-code
contains/does more easily, the code becomes almost self-documenting,
and the code looks better too (but this last is a matter of taste).

- --
(e-mail address removed) http://www.autistici.org/marc0
(rot13-string "(e-mail address removed)")
2143 9E77 D5E6 115A 48AD A170 D0EE F736 4E88 99C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/FVw60O73Nk6ImcIRAh+DAKCGf6ScoFVSmSCU/kaM8XVSdBkTfgCfcftz
P3XMG/UOGnhxfm1Wji/kERg=
=U56N
-----END PGP SIGNATURE-----

 

[Jürgen Exner]

I desire them because I desire to modify the syntax where IMHO makes
sense, for example something like:

#include <stdio.h>

#define loop(n) for (i = 0; i < n; i++)

int main ()
{
unsigned int i;

loop (10)
do_something ();

return 0;
}

Is there anything wrong with the even shorter and more concise existing
form:

for (0..10) {
do_something();
}

In the Perl script I'm working on I would use it to write something
like

#define walk_file(FILE) for ($walk_file_line = <FILE>)

walk_file (FILE) {
...
}

Anything wrong with the idiom

while (<FILE>) {
do_something_with_current_line;
}

and alike.

That's not necessary but IMHO it helps to make the code more clear.

Actually now. It obfuscates your code if you replace well-established idioms
with your own home-cooked solutions.

jue

 

[marc0]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is there anything wrong with the even shorter and more concise existing
form:

for (0..10) {
do_something();
}

But that was in C. Its purpose is to show a correct example.

Anything wrong with the idiom

while (<FILE>) {
do_something_with_current_line;
}

No. Please see the my replies to David K. Wall and A. Sinan Unur.

Actually now. It obfuscates your code if you replace well-established idioms
with your own home-cooked solutions.

This seems the usual opinion. I'm not very persuaded, but I think that
you peoples are right, I simply think that I was not clear: I want not
to replace every single idiom, I want only where this makes things
more explicit, and this would happen every N lines of code, not N
times per line.

- --
(e-mail address removed) http://www.autistici.org/marc0
(rot13-string "(e-mail address removed)")
2143 9E77 D5E6 115A 48AD A170 D0EE F736 4E88 99C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/FWaf0O73Nk6ImcIRAvicAKCIQGWCcBm9fF3l3Vj3FfJnWk1C5ACfUMFF
KOv2HocJkgFPR+BedCdg2fU=
=ZAyY
-----END PGP SIGNATURE-----

 

[Martien Verbruggen]

I would say this is unnecessarily obfuscatory, and will make it harder
for other people to read your code. Even in C these sorts of things
are frowned upon heavily by experienced programmers, especially
those who need to read each others code. Writing idiomatically, in any
language, is an important part of programming. Trying to warp a
language to your tastes of the day (and yes, they will change) is not
a good way to write maintainable code.

If you like to change the way this sort of thing works, then you
should be looking for OO wrappers around the normal Perl operations,
and in the case of file I/O , that already exists (see the IO::*
modules). Perl has many ways to allow a programmer to do things
differently in a structured manner.

I was not aware that $_ works with other things than subroutines, good
to know, that's fine, thank you.

I'm a bit confused about this statement. $_ has nothing at all to do
with subroutines (@_ does, but that's a different beast). Have you
checked the perlvar documentation to find out what $_ is for? It is
used for many, many things in Perl as a default variable, but
subroutines is not one of them.

IMHO the point in using long and specific names instead of the general
purpose ones is that you can guess what the variable/piece-of-code
contains/does more easily, the code becomes almost self-documenting,
and the code looks better too (but this last is a matter of taste).

[snip of unnecessary PGP ballast]

Martien

 

[Bob Walton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
....
How it's possible to write macros in perl? ....


(e-mail address removed) http://www.autistici.org/marc0

....


Have you considered:

use Filter::Simple;

? This will let you write macros for your Perl program in Perl if you
so wish.

It isn't clear from your post if you actually want to "write macros in
Perl" as you state, or if you want to use macros in/on a Perl program.

Note the warnings in "perldoc perlrun" (under the -P switch) about using
a C or C++ macro package on a Perl program.

 

[marc0]

marc0 wrote:

Have you considered:

use Filter::Simple;

? This will let you write macros for your Perl program in Perl if you
so wish.

I will look at it.

It isn't clear from your post if you actually want to "write macros in
Perl" as you state, or if you want to use macros in/on a Perl program.

The latter, but I wanted to avoid using external tools, I wanted to
know if there is a perlish way.

Note the warnings in "perldoc perlrun" (under the -P switch) about
using a C or C++ macro package on a Perl program.

Thanks

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I desire them because I desire to modify the syntax where IMHO makes
sense, for example something like:

#include <stdio.h>

#define loop(n) for (i = 0; i < n; i++)

int main ()
{
unsigned int i;

loop (10)
do_something ();

return 0;
}

In the Perl script I'm working on I would use it to write something
like

#define walk_file(FILE) for ($walk_file_line = <FILE>)

walk_file (FILE) {
...
}

and alike.

That's not necessary but IMHO it helps to make the code more clear.

Another way to do it would be to use the C preprocessor or M4 (likely
better) on the file but this adds complexity.

IMNSHO, learn the goddamn language and use it. I once worked in a
department where some long-gone moron had written macros for making C
look like Pascal:

#define begin {
#define end }
#define or ||
#define not !

And so on. And then these macros were used -- inconsistently --
throughout much of the codebase. Far from making the code more clear, it
obfuscated the hell out of everything.

- --
Eric
$_ = reverse sort qw p ekca lre Js reh ts
p, $/.r, map $_.$", qw e p h tona e; print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPxZylGPeouIeTNHoEQLpSwCeIa7wqp6AnDx7X5VaCksVxvlPRo8AnRMf
9OOQKLiduetHu2UmxpdJ/pyh
=lWTL
-----END PGP SIGNATURE-----

 

[Ted Zlatanov]

IMHO the point in using long and specific names instead of the
general purpose ones is that you can guess what the
variable/piece-of-code contains/does more easily, the code becomes
almost self-documenting, and the code looks better too (but this
last is a matter of taste).

Unfortunately this is not always true. If the code maintainer 5 years
from now has to look up all your long and specific contructs, it's
going to make his job harder, not easier no matter how
self-documenting it looks to you. This is because we imagine that the
code we know intimately is just as clear to everyone else - a very
common pitfall.

Another problem with the sort of macros you imagine is that they don't
really help you, and in fact may prevent you from learning the better
idioms that people have pointed out already. Whereas C can definitely
benefit from macros, Perl is (in my experience) not a repetitive
language because of its rich syntax; if you find yourself repeating
things so you need a macro it's time to write a subroutine.

You may imagine a gain in performance from the inline expansion of
macros vs. the call penalty of subroutines, but remember that
"premature optimization is the root of all evil." Better to write
standard subroutines and later convert them to inline expansion
through Filter::Simple or whatever you want, if the optimization is
necessary. Use the Benchmark module and the profiler to study your
subroutines' performance.

Abigail pointed out a module like Switch, which is certainly useful.
Switch.pm, however, was written after by a Perl expert after many
people requested that functionality over the years. You should learn
the basics of Perl well, and make sure you really need the macros you
think you need, before you spend the time writing them.

Ted

 

[Tassilo v. Parseval]

Also sprach Ted Zlatanov:

Another problem with the sort of macros you imagine is that they don't
really help you, and in fact may prevent you from learning the better
idioms that people have pointed out already. Whereas C can definitely
benefit from macros, Perl is (in my experience) not a repetitive
language because of its rich syntax; if you find yourself repeating
things so you need a macro it's time to write a subroutine.

Functions do not serve the same purpose as macros. If they did, you
wouldn't need macros in C. I often came across a situation in which I
would have liked to have macros in Perl, too. The main difference is
that macros only have a compile-time effect. You don't usually want to
find out the machine's byte-order in order to do some byte-swapping at
run-time. That's a job for a macro because all needed information are
already present at compile-time (actually, even by the time your
processor was layed out by the engineers on their scratch-pad).

Perl6 will have macros, wont it? I think that should give some
indication that they are even useful for such non-repetitive languages
as Perl is.

Tassilo

 

[Uri Guttman]

TvP> Perl6 will have macros, wont it? I think that should give some
TvP> indication that they are even useful for such non-repetitive
TvP> languages as Perl is.

and they will be very cool too. the definition of a macro in perl6 is
that it is just a sub that executes as soon as it is parsed (in the
compile phase). this integrates the macro concept into perl6 in a very
neat way. if the macro returns a string, it replaces the original macro
call. if it returns a code block (all blocks are code refs in perl6), it
inserts that compiled opcode tree at this point in the main tree.

also macros can alter the way they are parsed when called! i won't go
into that as it is confusing to me so far. but i see its possibilities.

uri

 

[Tassilo v. Parseval]

Also sprach Uri Guttman:

TvP> Perl6 will have macros, wont it? I think that should give some
TvP> indication that they are even useful for such non-repetitive
TvP> languages as Perl is.

and they will be very cool too. the definition of a macro in perl6 is
that it is just a sub that executes as soon as it is parsed (in the
compile phase). this integrates the macro concept into perl6 in a very
neat way. if the macro returns a string, it replaces the original macro
call. if it returns a code block (all blocks are code refs in perl6), it
inserts that compiled opcode tree at this point in the main tree.

Hmmh. So if a macro in Perl6 is a function (that might return a string),
I can use Perl's text-manipulation capabilities to generate the
replacement-string. That's more than just "very cool"!

I really should stop hearing about Perl6. The more I hear about its new
features the more I get mad that I have to wait for it. I want it now!

Tassilo

 

[Ted Zlatanov]

Also sprach Ted Zlatanov:


Functions do not serve the same purpose as macros. If they did, you
wouldn't need macros in C.

Absolutely. I was specifically referring to the OP's macros in Perl.
I thought that was clear because I continued the thought in the same
sentence. What I mean is that generally C-style macros (for instance
the byte ordering you mention) are unnecessary in Perl or can be
expressed as subroutines. The need for actual compile-time expansion
in Perl, such as what the Switch module does and Perl 6 will provide,
is very rare.

Ted