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

[Sam Watkins]

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

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

thanks!


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!

Sam