[% setvar title Highlander Variable Types %]

This file is part of the Perl 6 Archive

To see what is currently happening visit http://www.perl6.org/

TITLE

Highlander Variable Types

VERSION

  Maintainer: Andy Wardley <abw@kfs.org>
  Date: 1 Aug 2000
  Mailing List: perl6-language@perl.org
  Number: 9
  Version: 1
  Status: Developing

ABSTRACT

Perl5 supports three distinct variable types for any given variable name corresponding to a scalar ($var), array (@var) and hash (%var). This RFC proposes that only one type of variable should be defined for any given name. Where an array or hash is defined (@var or %var), the equivalent scalar value ($var) would be an implicit reference to that array or hash array. This would permit the rationalisation and simplification of the syntax required to access individual elements or slices of arrays and hash arrays, while remaining backwardly compatible with Perl5 syntax. The only semantic difference would be that scripts could no longer rely on $var, %var and @var referencing different variables.

DESCRIPTION

Perl5 supports three distinct variable types for any given variable name corresponding to a scalar ($foo), array (@foo) and hash (%foo). Each of these may be defined and exists independantly of the others (NOTE: sub-routines, formats and I/O handles are outside the scope of this document).

    $foo =   'Hello World';
    @foo = ( 'Hello', 'World' );
    %foo = ( 'Hello' => 'World' );

When accessing variables, and in particular, elements or slices of lists or hash arrays, the funny character prefix is used to denote the multiplicity of the returned value(s); $ = 'the', @ = 'these'. Although it can be argued that this is logical and consistent (it is), it can also cause confusion because the prefix is used to denote what is returned, rather than indicating the variable from which the value(s) are retrieved. For example:

    $foo[2];	           # third element of @foo, no relation to $foo
    @foo{'bar', 'baz'};    # slice of %foo, no relation to @foo

In effect, it is the brackets [] that associate the variable name with the list type @foo and the braces {} that imply the hash type %foo.

This RFC proposes that only one type of variable should be defined for any given name. Where an array or hash is defined, the scalar value of the same name would implicitly contain a reference to that array or hash. Thus there can be no confusion as to which of the variables is being accessed because "there can be only one".

    @bar = ( 3, 5, 7 );    # $bar is implicitly \@bar
    $bar = [ 3, 5, 7 ];    # same as above
    $bar[2];               # third element of @bar, value 7               
    $bar->[2];		   # same as above

    %baz = ( a => 11 );	   # $baz is implicitly \%baz
    $baz = { a => 11 };    # identical to above
    $baz{ a };		   # 'a' entry of %baz, value 11
    $baz->{ a };	   # same as above

The '->' would become redundant (but optional for backwards compatability), with an implicit dereference associated with every pair of braces or brackets. In Perl 5, there is an implied '->' between every pair of adjacent braces or brackets but not the first, e.g.

    $wiz->[$x][$y][$z]    ===   $wiz->[$x]->[$y]->[$z]
    $waz->{$x}{$y}{$z}    ===   $waz->{$x}->{$y}->{$z}

Under this proposal, the rule would apply to all cases and the above examples could be written as:

    $wiz[$x][$y][$z]
    $waz{$x}{$y}{$z}

Array slices could be specified as either of the following:

    $bar[0..2];
    @bar[0..2];

Similarly for hash slices:

    $baz{'a'..'c'};
    %baz{'a'..'c'};        # for consistency (not sure about this)
    @baz{'a'..'c'};        # for backwards compatability

In effect, all arrays and hashes are stored in $var as references to the same, with @bar and %baz being synonymous for the existing @$bar and %$baz constructs.

IMPLEMENTATION

Everything depends on how the internals are reworked.

ISSUES

Sub-routines would not be affected by these changes, continuing to be referenced as &foo() or foo().

Existing scripts can be automatically converted to preserve multiple variable semantics, e.g.

    $foo -> $foo
    %foo -> $foo__hash
    @foo -> $foo__list

Internal multi-type variables would need renaming, e.g. @INC/%INC

This RFC could do with a better title.

REFERENCES

None yet.