Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
Buddha Buck wrote: > At 05:35 PM 8/31/00 +, David L. Nicol wrote: > >Buddha Buck wrote: > > > > The array > > > > syntax would also be useful in multi-dimensional arrays. > > > > > > That is if multi-dimensional arrays are implemented as lists-of-lists, > > > which they might not be. > > > >Even if they aren't implemented as lol, they may appear as lol to the > >programmer > > The language-data group is working on multi-dimensional array syntax. > > I would like to have (in multidimensional arrays) the various dimensions be > equally easy to access. Using lol syntax imposes a hierarchy on the > dimensions, which makes equal access hard. > Not necessarily. _Allowing_ LOL syntax does *not* rule out provides other syntax which allows direct access to slices of additional dimensions. Providing both approaches means that all the language constructs and modules that already support LOLs will continue to work, while n-dim access works as well. It also avoids creating a new data type. Anyhow, let's keep this discussion to -data from here... RFC 177 should probably make -data its home.
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
At 05:35 PM 8/31/00 +, David L. Nicol wrote:
>Buddha Buck wrote:
> > > The array
> > > syntax would also be useful in multi-dimensional arrays.
> >
> > That is if multi-dimensional arrays are implemented as lists-of-lists,
> > which they might not be.
>
>Even if they aren't implemented as lol, they may appear as lol to the
>programmer
The language-data group is working on multi-dimensional array syntax.
I would like to have (in multidimensional arrays) the various dimensions be
equally easy to access. Using lol syntax imposes a hierarchy on the
dimensions, which makes equal access hard.
For instance, using the syntax I proposed in RFC169, you can take the $ith
row and $jth column of a 2-dimensional array with:
@row = @matrix[$i;..];
@col = @matrix[..;$j];
This can be naturally extended to greater dimensions, if need be.
How does one do this in LOL syntax?
@row = @{$matrix[$i]}; # this is easy!
for my $r (@matrix) {
push @col,$$row[$j];
} # this is easy?
I suppose one could do:
for (my $k = 0;$k < @matrix; $k++) {
push @row, $matrix[$i][$k];
push @col, $matrix[$k][$j];
}
but even that obscures what you really want to do.
>--
> David Nicol 816.235.1187 [EMAIL PROTECTED]
>"My baby done left me,
>she done went to the drive-in movies with somebody else."
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
Perl6 RFC Librarian wrote:
> arsenal. The constructs are:
>
> $ref->[[LIST]]
> $ref->{{LIST}}
>
> The proposed respective meanings:
>
> $ref->[$elem[0]]->[$elem[1]}->[...]->[$elem[-1]]
> $ref->{$elem[0]}->{$elem[1]}->{...}->{$elem[-1]}
why not just use single braces for simplcity, and break
code that expects $container{@fred} to return $container{4}? There
can't be that much of it.
Buddha Buck wrote:
> > The array
> > syntax would also be useful in multi-dimensional arrays.
>
> That is if multi-dimensional arrays are implemented as lists-of-lists,
> which they might not be.
Even if they aren't implemented as lol, they may appear as lol to the programmer
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"My baby done left me,
she done went to the drive-in movies with somebody else."
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
Jarkko Hietaniemi wrote:
> > By saying $hashref->{[LIST]} instead of $hashref->{{LIST}},
> > the only thing you would change is the semantics of the expression,
>
> Huh? Unless I missed something I didn't propose using $hashref->{[]}
> anywhere... I used $ref->{{LIST}} and $ref->[[LIST]].
Right; *I* am proposing $ref->{[LIST]}.
> > not the [il]legality.
>
> ->{{ *is* illegal now.
I'm suggesting a different syntax which isn't illegal, but which has
barfonious semantics. All you'd need to do is change the semantics of
$ref->[[LIST]]
$ref->{[LIST]}
to make them useful in the way you suggest.
But, even if you wanted to use $ref->{{LIST}} (or my alternative,
$ref->{[LIST]}), where would that leave people who want to use
stringized references as hash keys? Or, as proposed for perl6,
the ability to use true references as hash keys?
--
John Porter
We're building the house of the future together.
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
On Wed, Aug 30, 2000 at 11:10:54AM -0400, John Porter wrote:
> > Snatch two syntax constructs away from the jaws of illegal syntax and
> > an unfortunate syntax, and make them useful weapons of the Perl
> > arsenal. The constructs are:
> >
> > $ref->[[LIST]]
> > $ref->{{LIST}}
> >
> > The proposed respective meanings:
> >
> > $ref->[$elem[0]]->[$elem[1]}->[...]->[$elem[-1]]
> > $ref->{$elem[0]}->{$elem[1]}->{...}->{$elem[-1]}
>
> By saying $hashref->{[LIST]} instead of $hashref->{{LIST}},
> the only thing you would change is the semantics of the expression,
Huh? Unless I missed something I didn't propose using $hashref->{[]}
anywhere... I used $ref->{{LIST}} and $ref->[[LIST]].
> not the [il]legality.
->{{ *is* illegal now.
> --
> John Porter
>
> We're building the house of the future together.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
> Snatch two syntax constructs away from the jaws of illegal syntax and
> an unfortunate syntax, and make them useful weapons of the Perl
> arsenal. The constructs are:
>
> $ref->[[LIST]]
> $ref->{{LIST}}
>
> The proposed respective meanings:
>
> $ref->[$elem[0]]->[$elem[1]}->[...]->[$elem[-1]]
> $ref->{$elem[0]}->{$elem[1]}->{...}->{$elem[-1]}
By saying $hashref->{[LIST]} instead of $hashref->{{LIST}},
the only thing you would change is the semantics of the expression,
not the [il]legality.
--
John Porter
We're building the house of the future together.
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
> On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
> > > $r->{{qw(a b c d e f g h)}}
> > > $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
> >
> > $r->{a}{b}{c}{d}{e}{f}{g}{h}
> >
> > which is only one character longer than the proposal...
>
> Except in the case where you don't have the list until run-time.
> So the syntax would be useful; I'm not sure how useful, such deeply nested
> hashes requiring run-time key lookup like that are a rarity. The array
> syntax would also be useful in multi-dimensional arrays.
That is if multi-dimensional arrays are implemented as lists-of-lists,
which they might not be.
On language-data a counter-proposal to my RFC169 has been made,
suggesting the use of array/list references for multidimensional
indices. In the simplest case, assuming list-of-list implementation,
$a[[1,2,3]] would be the same under both proposals (unless this
proposal would require $a[[(1,2,3)]], which is too much syntax for my
taste). But the list-ref idea would also allow @a[$point1,$point2] as
a slice of two elements of the matrix @a, each point being a reference
to a 4-element list of integers.
>
>
> Michael
> --
> Administrator www.shoebox.net
> Programmer, System Administrator www.gallanttech.com
> --
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
> > $r->{{qw(a b c d e f g h)}}
> > $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
>
> $r->{a}{b}{c}{d}{e}{f}{g}{h}
>
> which is only one character longer than the proposal...
Except in the case where you don't have the list until run-time. I made a
class once that emulated the hierarchical structure of a filesystem using a
deep hash of hashes. It had an accessor something like:
$obj->file(qw(usr local bin gpg));
or
$obj->file("/usr/local/bin/gpg"); # which would get split
(I'm paraphrasing and changing syntax, because I don't actually recall the
actual syntax I came up with.)
The accessor would traverse down the internal hash of hashes to retrieve the
information about /usr/local/bin/gpg. With current syntax this is rather
awkward, resulting in code something along the lines of:
my $cur = $hoh;
foreach my $file (@_) {
if (exists $$cur{$file}) {
$cur = $$cur{$file};
} else {
# error
}
}
So the syntax would be useful; I'm not sure how useful, such deeply nested
hashes requiring run-time key lookup like that are a rarity. The array
syntax would also be useful in multi-dimensional arrays.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
>Having the
>indices in one place saves a lot of characters. Compare
>
> $r->{{qw(a b c d e f g h)}}
>
>versus
>
> $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
But I would compare it to
$r->{a}{b}{c}{d}{e}{f}{g}{h}
which is only one character longer than the proposal...
--
Peter Scott
Pacific Systems Design Technologies
RFC 177 (v1) A Natural Syntax Extension For Chained References
(aka Multidimensional Arrays/Hashes)
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
A Natural Syntax Extension For Chained References
(aka Multidimensional Arrays/Hashes)
=head1 VERSION
Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 177
Status: Developing
=head1 ABSTRACT
In this RFC an extension to existing Perl syntax is proposed. The
syntax doesn't conflict with anything existing (in fact it corrects a
bug of sorts), it is natural (naturalness being naturally in the eye
of the proposer), and it gives concise way to express a complex data
structure access.
=head1 DESCRIPTION
Snatch two syntax constructs away from the jaws of illegal syntax and
an unfortunate syntax, and make them useful weapons of the Perl
arsenal. The constructs are:
$ref->[[LIST]]
$ref->{{LIST}}
The proposed respective meanings:
$ref->[$elem[0]]->[$elem[1]}->[...]->[$elem[-1]]
$ref->{$elem[0]}->{$elem[1]}->{...}->{$elem[-1]}
That is, the lists are being expanded as the indices for a chain of
references, the arrays could be called index lists. Having the
indices in one place saves a lot of characters. Compare
$r->{{qw(a b c d e f g h)}}
versus
$r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
An example using an array may be even more enticing
$r->[[@a]]
versus
$r->[$a[0]]->[$a[1]]->...
or even
$r->[$a]->[$b]->...
(assuming @a = ($a, $b, ...))
As mentioned earlier, these syntaxes do not do anything useful at the moment.
The first one, ->[[]], is an intermittent cause of segmentation
violations, core dumps, and bug reports because it already does have a
meaning but a rather twisted and faulty one: "access the array at the
offset of stringifying this anonymous list". This offset is usually a
rather large one, resulting in unruly memory access attempts. Reusing
the syntax for something useful cannot be an evil thing.
The second one, ->{{}}, is currently a syntax error, and cannot
therefore broke existin code.
The degenerate case of the list being empty can be defined to be
equivalent to $ref.
=head1 IMPLEMENTATION
Since the exact meaning of the construct depends on the contents of
the index list, the chasing the indices (autovivifying data structures
as needed) cannot be determined in compile time and needs to be
a run-time operation.
=head1 REFERENCES
perlref
perldsc
perllol
