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?

- --
[email]marc0@autistici.org[/email] [url]http://www.autistici.org/marc0[/url]
(rot13-string "znep0@pelcgberoryf.arg")
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]

marc0 wrote:

>
> 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
--
use Perl;
program
fulfillment

[Stephane G. Titard]

marc0 wrote:

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

>
> - --
> [email]marc0@autistici.org[/email] [url]http://www.autistici.org/marc0[/url]
> (rot13-string "znep0@pelcgberoryf.arg")
> 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-----

[marc0]

marc0 on Wed, 16 Jul 2003 12:41:23 GMT writes:

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

s/for/while/

>
> walk_file (FILE) {
> ...
> }

[David K. Wall]

marc0 <marc0@autistici.org> wrote:

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

--
David Wall

[marc0]

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

David K. Wall on Wed, 16 Jul 2003 13:46:27 -0000 writes:

> marc0 <marc0@autistici.org> wrote:

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

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

- --
[email]marc0@autistici.org[/email] [url]http://www.autistici.org/marc0[/url]
(rot13-string "znep0@pelcgberoryf.arg")
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]

marc0 wrote:

> 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

Jürgen Exner on Wed, 16 Jul 2003 14:37:01 GMT writes:

> marc0 wrote:

>> 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();
> }

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

>> 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;
> }

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

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

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.

- --
[email]marc0@autistici.org[/email] [url]http://www.autistici.org/marc0[/url]
(rot13-string "znep0@pelcgberoryf.arg")
2143 9E77 D5E6 115A 48AD A170 D0EE F736 4E88 99C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/FWaf0O73Nk6ImcIRAvicAKCIQGWCcBm9fF3l3Vj3FfJnWk1C5A CfUMFF
KOv2HocJkgFPR+BedCdg2fU=
=ZAyY
-----END PGP SIGNATURE-----

[Martien Verbruggen]

On Wed, 16 Jul 2003 14:12:48 GMT,
marc0 <marc0@autistici.org> wrote:

>
> David K. Wall on Wed, 16 Jul 2003 13:46:27 -0000 writes:
>

>> marc0 <marc0@autistici.org> wrote:

>>> 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) {
>>> ...
>>>}

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.

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

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
--
|
Martien Verbruggen | +++ Out of Cheese Error +++ Reinstall
Trading Post Australia | Universe and Reboot +++
|

[Bob Walton]

marc0 wrote:

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

....

> How it's possible to write macros in perl?

....

> [email]marc0@autistici.org[/email] [url]http://www.autistici.org/marc0[/url]

....


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.

--
Bob Walton

[marc0]

Bob Walton on Wed, 16 Jul 2003 23:33:24 GMT writes:

> marc0 wrote:

>> How it's possible to write macros in perl?

> 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

--
[email]marc0@autistici.org[/email] (rot13-string "znep0@pelcgberoryf.arg")
2143 9E77 D5E6 115A 48AD A170 D0EE F736 4E88 99C2

[Eric J. Roode]

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

marc0 <marc0@autistici.org> wrote in news:87n0fek5p7.fsf@autistici.org:

> 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/AwUBPxZylGPeouIeTNHoEQLpSwCeIa7wqp6AnDx7X5VaCksVxv lPRo8AnRMf
9OOQKLiduetHu2UmxpdJ/pyh
=lWTL
-----END PGP SIGNATURE-----

[Abigail]

Eric J. Roode (REMOVEsdnCAPS@comcast.net) wrote on MMMDCVII September
MCMXCIII in <URL:news:Xns93BB3C48D4FCDsdn.comcast@206.127.4.25 >:
^^ -----BEGIN PGP SIGNED MESSAGE-----
^^ Hash: SHA1
^^
^^ marc0 <marc0@autistici.org> wrote in news:87n0fek5p7.fsf@autistici.org:
^^
^^ > 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.


And a single observation makes you conclude that macros can't
make the source clearer?

Do you also think that 'Switch.pm' shouldn't be included in the
main distribution? After all, that makes use of a source filter,
which is a source preprocessor just like cpp or m4.

What about modules in general? Should people stop using Socket,
and just learn the goddamn language and use socket() and
bind (), they way some god intended?


Abigail
--
perl -le 's[$,][join$,,(split$,,($!=85))[(q[0006143730380126152532042307].
q[41342211132019313505])=~m[..]g]]e and y[yIbp][HJkP] and print'

[Ted Zlatanov]

On Wed, 16 Jul 2003, [email]marc0@autistici.org[/email] wrote:

> 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
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus}) !JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexi ixesixeseg;y~\n~~dddd;eval

[Uri Guttman]

>>>>> "TvP" == Tassilo v Parseval <tassilo.parseval@rwth-aachen.de> writes:

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

--
Uri Guttman ------ [email]uri@stemsystems.com[/email] -------- [url]http://www.stemsystems.com[/url]
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- [url]http://jobs.perl.org[/url]

[Tassilo v. Parseval]

Also sprach Uri Guttman:

>>>>>> "TvP" == Tassilo v Parseval <tassilo.parseval@rwth-aachen.de> writes:

>
> 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
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus}) !JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexi ixesixeseg;y~\n~~dddd;eval

[Ted Zlatanov]

On 17 Jul 2003, [email]tassilo.parseval@rwth-aachen.de[/email] wrote:

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

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