[Melbourne-pm] returning hashes and arrays, source filters considered harmful?

Tulloh, David david.tulloh at AirservicesAustralia.com
Thu Feb 18 16:49:29 PST 2010

When in doubt benchmark, it's difficult to guess at the internal workings of a interpretted language.  I ran the attached benchmark and found returning @foo was faster than \@foo.

The difference is trivial though and I would suggest using whatever format works best for you and then standardising on it.  I personally use return @foo because I like passing the output into list functions like grep and map (@bar = map {} grep {} my_sub) and it's cleaner without the @{} everywhere.

Directly working with array references is similar to hashes, $ref->[0].


-----Original Message-----
From: melbourne-pm-bounces+david.tulloh=airservices.gov.au at pm.org [mailto:melbourne-pm-bounces+david.tulloh=airservices.gov.au at pm.org] On Behalf Of Sam Watkins
Sent: Friday, 19 February 2010 10:16 AM
To: Melbourne Perlmongers
Subject: [Melbourne-pm] returning hashes and arrays,source filters considered harmful?

A quick question.  Supposing I want to return an array from my_func(), I can do

	  return @foo;

	@foo = my_func();

but I normally do it like this because I feel like it should be more efficient:

	  return \@foo;

	$foo = my_func();

This has the unfortunate effect of converting my array to an array ref.  If I wanted to reverse that, I think I could use:

	@foo = @{my_func()};

which is getting ugly and inefficient too.  The same thing happens when returning hash variables, except that I suppose it is even more inefficient to return it via a list return compared to a reference.

My question is, does perl actually optimize this so it sucks less than I am naively supposing it does?  Also, is there any way to make like an alias @foo for @$foo, so you can treat an array reference as a normal array without writing @$foo all the time?  (and also for hashes)

These concerns make me reluctant to use normal perl @array and %hash types at all.  If I have to pass and return things by reference, and can't alias these back to normal @array and %hash types, I would prefer to use references for everything in order to be consistent and avoid having to rewrite code when I suddenly need to pass some variable to or from a sub.  This would make the @foo %bar syntax useless for anything but the one-liners.  So I'm hoping there is some workaround or optimization, and a way to alias them.


On Tue, Feb 09, 2010 at 09:30:22AM +0000, Drew Taylor wrote:
> I'm not in Melbourne (give me a few years), but I thought I'd put in 
> my €0.02.
> You might also want to look into Moose and/or MooseX::Declare. Mx::D 
> gives you some nice syntax for defining methods and the parameters 
> passed, while Moose gives you a nicer OO interface.

Mx::D looks good.  It still apparently uses $self->{foo} for accessing members though, which is what my filter avoids.  They are orthogonal!

> Regarding source filtering, Just Don't Do It. Ricardo Signes' review 
> of Filter::Simple says it all: "Don't write source filters. They will 
> make your momma cry."

I'm sure my momma would cry, scream and tear her hair out if she experienced even a little of the horror of perl programming.  If a tiny source filter is what it takes to negate some of that horror, I'm happy to use one.

Or a more positive rationale: perl is all about hideous crazy fun hacks, so I'm just fitting in with the scene.

I think a source filter is just a simple translator / compiler module.  If it's done right, it can really improve the language.  They can be written with the aid of proper parsers (although it's doubtful if such a thing exists for perl, Damien's stuff is good enough for non-pathological well-written programs).
I've written plenty of source filters for C (my "brace" project is implemented as a composition of filters) and a couple for perl.

I think it's an elegant thing.  Look at troff for example, it has nice little modules like eqn and tbl for different stuff.  eqn syntax is on a par with TeX for simplicity, it is much simpler than MathML (horror!).  troff syntax might seem a bit ugly but tbl syntax for example is a lot more readable than HTML tables.

Have you read the excellent book "The Practice of Programming" by Kernighan and Pike?  "This book was typeset (grap|pic|tbl|eqn|troff -mpm) in Times and Lucida San Typewriter by the authors."  http://www.troff.org/pubs.html#tpop
Admittedly troff has nowhere near the following of TeX (except for man pages).
I'd like to see the source of that book, and compare it to say "the TeX book".

It's kind of nice to use filters, you can turn them on and off or apply just one filter to test it.  You can pipe them together in whatever order works best, at least if you do it using make or the shell, I think Filter::Simple can stack them too but I didn't try it.  It's a very modular / unixy way to do
things: simple processes communicating via text pipes.  I think this is still the most expressive programming paradigm to date.

An improvement would be to integrate the ideas of make (cache intermediate data in files, compute only what's needed) and the shell (pipelines of processes running in parallel); perhaps with a graphical nodes-and-arcs interface that maps <-> a clear textual format.  To create such a language is an ambition of mine!  Using textual formats may be seen as inefficient: binary formats (e.g.
packet streams of raw structs) may be used as an optimization so long as the textual version can be generated on the fly as needed, for inspection / debugging / portability or whatever.  Something like YAML might serve admirably for that purpose, or even use the format like Debian metadata files, with refs instead of nesting:

  name: Sam
  sex: m

  name: Maria
  sex: f

I should probably do some work now!

Melbourne-pm mailing list
Melbourne-pm at pm.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: array_return_benchmark.pl
Type: application/octet-stream
Size: 304 bytes
Desc: array_return_benchmark.pl
URL: <http://mail.pm.org/pipermail/melbourne-pm/attachments/20100219/fef3c5fc/attachment-0001.obj>

More information about the Melbourne-pm mailing list