$ @ and %
Alexey Trofimenko
more similar in Perl6 than it was in Perl5.
F.e. we have @a and $a = \@a;
the same:
push @a,1,2,3 push $a, 1,2,3
$b = @a $b = $a
(?) say "@a[]" say "$a[]"
(?) myfunc( *@a) myfunc ( *$a)
hm.. i'm not so competent to continue that list.. could anyone kind make a
comparison table?
in all other places where they work different, we could use @$a in place
of @a, right?
so I can consider @ as "threat as container" specificator, and nothing
more.. (in abstract, of course). And we just happen to have arrays with
specificator (@) and name without sigil (a), contrary to scalars which
always have to had "$" in name ($a).
(
I must admit that I like to have three different namespaces for
arrays,hashes and scalars. In Perl5. the _only_ thing I miss is ability to
sub foo (@@) {
(\my @a, \my @b) = \(@_);
...
}
)
but perl6 has somewhat different data model. And we going to use
references much more often and easier than in perl5. And we going to have
much more different container types, not only arrays and hashes. Why to
threat two containers as first class citizens, and all other as mere
scalars with references to objects?
so, yeah, it's way too late to make significant changes, but could
somebody tell me what was wrong with the following models, apart that they
are different from perl5 (and could make it harder to write perl5 to perl6
translators)
I'm talking about unifying namespaces of arrays, hashes and scalars. I
could swear i've seen some RFC about it..
1. all variables are scalars, and as scalars they include $ in their name
2. if scalar $var contains reference to array or hash, we could threat it
as array or hash using @$var and %$var(or maybe just @var and %var, as
shorthands).
With all associated behavior, so @var = ... makes list context to right
side of assignment. We could think of it as of "Array" operator, or macro.
2. my @a is ... does right thing: it creates lexical $a, places reference
to anonimous array in it, and apply all the traits as current perl6 would
do (I'm not sure what differences of traits applying to container and
scalars, though). So "my @a of .." is just a syntactic sugar to "my $a is
Array of ..".
3. subscripts are written as $var{} and $var[], as we have now and always
had before. still @var{...} could be easily recognized as slice.
as far as I can see, we have one thing to lose:
1) one namespace instead of three,
(my $x=$x[$i]; "It's a Perl!" (c))
and several good points:
1) simplicity.
2) eliminating of redundancy. We could write all the code involving named
arrays and hashes using _only_ named scalars with references to arrays and
hashes, so why to have both ways?.
3) no logical separation between CORE and extrnal data containers (yeah,
i know about tying, but why we have separate classes and tyers in perl5?
is there reason to have write that (tied $var)->method.. in my proposal it
would be matter of difference between $var.method and @var.method;
4) using references to containers isn't harder then using containers
theyself, because it's a same.
5) one namespace instead of three.
There's plenty of other classifications of variables which would want to
have separate nonclashing namespaces, (global/private, instance/class
etc.) but we for whateer reason stick with classifing thousands of
different container types as three major.
6) syntax would be much the same as what perl5 programmers used to see.
just try to look on your perl5 code in my way, and it would work! The only
thing that they should keep in mind is that $a and @a is the same..
ah, proposed model could prevent some minor optimizations.. but all thoose
optimizations are gone too if you going to use references to arrays
instead of arrays itself, aren't they? and if not, than there's no
trouble..
P.S Yeah, I see, it looks closer to Certain Other Languages. but why not
if it's simplier and maybe even better? and using @ and % as shorthand to
that clumsy and verbose to "is Array" or "is Hash" is cool, I think, and
it could be a distinctive feature, which could help us to withstand bitter
of being less distinctive.
P.P.S I had never feel enough inner strength in myself to be a
revolutioner. So I suppose I just don't see something important.. so bring
me to Right Way, please..
P.P.P.S. If answer on my "why?" would be "just because!" I would take it
silently.
P.P.P.P.S
open $file, "filename";
print @file;
...
P.P.P.P.P.S. oooh.. sh$t! i forgot about @_ ! :) but maybe $_ is an Args
object? so $_[0] is here, scalar $_ is here for little unprototyped blocks
in map and others, and even $_{...} syntax for named args too, it's only
matter of viewpoint?..
P.P.P.P.P.P.S I'm going to write a grammar to write such a perl dialect
<strike>if</strike> when you'll decline my proposal.
Larry Wall
: I'm talking about unifying namespaces of arrays, hashes and scalars. I
Yes that's RFC 9, which was discussed and rejected long ago in A2.
I just find that I prefer to think of the sigils as part of the name.
That's doubly true now that we have various secondary sigils.
Larry
Alexey Trofimenko
> silently.
yes, answer was as I predicted above. I promised..
..but:
> As far as I understood, arrays and hashes, and references them are much
> more similar in Perl6 than it was in Perl5.
>
> F.e. we have @a and $a = \@a;
> the same:
>
> push @a,1,2,3 push $a, 1,2,3
> $b = @a $b = $a
> (?) say "@a[]" say "$a[]"
> (?) myfunc( *@a) myfunc ( *$a)
>
> ...
were all thoose right?
> hm.. i'm not so competent to continue that list.. could anyone kind make
> a comparison table?
yes, please! I think, answer could be very informative for other readers
too. and even could make it's way to perl6 documentation. So, where's @a
and $a=\@a are the same, and where they aren't?
> in all other places where they work different, we could use @$a in place
> of @a, right?
if @ in @a is a part of name, would @$b work? and what's that @ here,
behind the scenes? operator? macro?
> ...
> P.P.P.P.S
> open $file, "filename";
> print @file;
> ...
..er, in that case:
open $file, "filename";
print @$file;
i mean, what about using objects(files, iterators, etc) as arrays? AFAIK,
we will have custom subscripting defined on our objects, so $file[10]
could be made to work, but what about @$file, or @($file) or $file[] (um,
maybe $file[*], I forgot) would it make any sense?
and, one more question: if we would have both tying (arrays which call
hidden object methods) and objects which could act as array references,
where's a difference between them? could it be THE same? Should it? could
we write
my $a = new ArrayLikeClass;
my @b := @$a;
or
my @b := $a;
(which one is right?)
Larry Wall
: >P.P.P.S. If answer on my "why?" would be "just because!" I would take it
:
: yes, answer was as I predicted above. I promised..
You have a funny idea of what "silently" means. :-)
: ..but:
: >As far as I understood, arrays and hashes, and references them are much
: >more similar in Perl6 than it was in Perl5.
: >
: >F.e. we have @a and $a = \@a;
: >the same:
: >
: > push @a,1,2,3 push $a, 1,2,3
: > $b = @a $b = $a
: >(?) say "@a[]" say "$a[]"
: >(?) myfunc( *@a) myfunc ( *$a)
: >
: >...
:
: were all thoose right?
I think so.
: >hm.. i'm not so competent to continue that list.. could anyone kind make
: >a comparison table?
:
: yes, please! I think, answer could be very informative for other readers
: too. and even could make it's way to perl6 documentation. So, where's @a
: and $a=\@a are the same, and where they aren't?
I think the only place they differ is in list context. @a always
interpolates, and $a never does.
: >in all other places where they work different, we could use @$a in place
: >of @a, right?
:
: if @ in @a is a part of name, would @$b work? and what's that @ here,
: behind the scenes? operator? macro?
Syntactic sugar for $b[], basically.
By the way, I've always wondered about the possibility declaring things like
my bit @$vector;
as a way of specify that @vector and $vector are the same object.
That would let you have your highlander variables when you want them,
without having to figure out whether &foo and $foo are the same.
: >...
: >P.P.P.P.S
: > open $file, "filename";
: > print @file;
: >...
:
: ..er, in that case:
: open $file, "filename";
: print @$file;
In any case, the open function doesn't take a filehandle as its first
argument anymore. It returns the new filehandle.
: i mean, what about using objects(files, iterators, etc) as arrays? AFAIK,
: we will have custom subscripting defined on our objects, so $file[10]
: could be made to work, but what about @$file, or @($file) or $file[] (um,
: maybe $file[*], I forgot) would it make any sense?
Any object that mixes in the ArrayIndex role can be indexed as an array.
Any object that mixes in the HashIndex role can be indexed as a hash.
Though it's probable that any object will act like a hash if you force
it, in which case $obj{'key'} ends up trying to call $obj.key, just so
that people can write in the Perl 5 object attribute idiom, and have it
really using accessors underneath. But we may yet decide that's a bad
idea as a default. Maybe it's just turned on by the p5-to-p6 translator.
: and, one more question: if we would have both tying (arrays which call
: hidden object methods) and objects which could act as array references,
: where's a difference between them? could it be THE same? Should it? could
: we write
: my $a = new ArrayLikeClass;
: my @b := @$a;
: or
: my @b := $a;
: (which one is right?)
I don't see a problem with either of them, but I didn't get enough sleep
last night, so I could be completely clueless. In any event, we may
allow
my @$a is ArrayLikeClass;
as a shorthand for the above. Or at least it should be possible via pragma.
Larry