It's strange, but I'd rather go the other way and define most things that use a name to access a value using the tie interface. Everyone who uses Perl rapidly learns how to use hashes and what methods (exists, each slices etc.) are available to operate upon them.

That means that if I present a tree or trie or Bag or map or whatever using the tied hash interface, then every Perl programmer familiar with hashes instinctively knows how to use (and read) code that uses this new data type with the familair interface.

The alternatives, whether OO or functionally abstracted, require them to ponder the documentation to find out how to use them.

Whilst the tie interface has its limitation, especially with respect to nesting, that (as far as I understand them) are limitations of the implementation rather than the concept, the simplicity of

tie %trie, 'Tie::Trie';

$trie{ fred } = 10;
$trie{ bill } = 20;
$trie{ total } = sum values %trie;
[download]

versus

my $trie = Trie->new();
$trie->add( 'fred', 10 );
$trie->add( 'bill', 20 );
my $temp = sum map{ $trie->lookup( $_ ) } 'fred', 'bill';
$trie->add( 'total', $temp );
[download]

or

my $trie = maketree();
extend-trie( $trie, 'fred', 10 );
extend-trie( $trie, 'bill', 20 );

## Does your lisp stuff define a way of iterating the keys?
my $temp = sum lookup( $trie, 'fred' ), lookup( $trie, 'bill' ); 
extend-trie( $trie, 'total', $temp );
[download]

Is self evident (to me).

If the autovivification of nested tied structures wasn't buggy, I could see myself defining whole OO-style inheritances using this kind of notation. I haven't seen an OO implementation that really worked well with collections of objects rather than individual instances.

$collection->set( 3, $collection->get( 3 ) + 1 );
[download]

Is just no substitute at all for

$collection[ 3 ]++;
[download]