develooper Front page | | Postings from August 2000

109 (v1): Less line noise - let's get rid of @%

Thread Next
Casey R. Tweten
August 24, 2000 09:51
109 (v1): Less line noise - let's get rid of @%
Message ID:
=head1 TITLE

Less line noise - let's get rid of @%

=head1 VERSION

  Maintainer: Karl Glazebrook <>
  Date: 15 August 2000
  Version: 1
  Mailing List:
  Number: 109


This RFC proposes that C<$x>, C<@x>, and C<%x> be ditched and
replaced with C<$x> for everything.


Back in the days of yore, Larry had a dream of a simple
typeless language. Variables were 'things', they could
hold numbers or strings, and manipulated without much
caring. The only important distinctions were whether they
were lists of things or hashes of things for which was
introduced the compact notation of C<@> and C<%>. Perl4 was
the anti-object-oriented language in an age when there
were Real Computers and Bill Gates was still trying to
flog BASIC.

Those days are gone. Perl 5 introduced the idea of Objects
and now any variable can be one of ten million possible
types all of very different behaviours.

Also in modern programming, lists are not longer simple
lists, neither are hashes, we have multidimensional arrays,
FIFO stacks, LIFO stacks, semi-infinite lists, etc. Basically there
are innumerable ways of containing things and they are usually
represented by objects.

I argue in this Brave New World the distinction between C<$x>, C<@x> and
C<%x> are no longer useful and should be abolished. We might want
to use all kinds of array objects, why should @x be special? Rather
since there are infinitely many kinds of variable let's take the perl6
opportunity to make things simple and just use C<$x> for everything.

A RFC by Andy Wardley proposes `Highlander Variable Types' (`there can
only be one'). This addresses the same fundamental issues, but 
retains C<@x> and C<%x> in the interests of backwards compatibility.

My proposal goes further: there should be NO  C<@x> and C<%x>, only C<$x>. 
This would make for a simplification of the language with extreme prejudice.

=head1 PROPOSAL:

All variables should be C<$x>. They should behave appropriately
according to their object types and methods. ARRAY objects
and HASH objects would provide methods (inline, optimised
of course) to make $x[42] and $x{Fred} do the right thing.
See the pdl-porters RFC on 'default methods' for elegant
ways to do this.

The only distinction left would be between things which are
variables (prefixed by C<$>) and not-variables (subroutines and


Considerable I expect. :)

Overloading should happen everywhere. 

  print $x

Ought to use string overloading and be able to print an array or hash depending
on type.

Similarly accesses such as C<$x[42]> or C<$x{Fred}> should function via
overloaded C<[]> and C<{}> operators.

  $y = $x + 1 

Ought to be able to execute appropriate code whether $x is a scalar, a Perl
array or a PDL array.


PDL RFC on 'Default Methods' - PDL RFCs coming Real Soon Now

RFC 9: Highlander Variable Types

print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'',site=>
''};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce <belg4mit at MIT dot EDU>

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About