Re: RFC 234 (v1) Data: overloading via the SECOND operand if needed
This RFC proposes a support of a situation when a more-knowledgable module may steal overloading from a less-knowledgable module or visa versa; What if both modules have this :override bit set at the same time? Does the second one still win? Or does the first one win again? Either way I'm not sure it solves the problem; if each module asserts that *they* are the smarter one then you either wind up with the same situation you have now or even worse contention. Seems like a bandaid for poor module writer collaboration, personally. :-) -Nate
Re: RFC 237 (v1) hashes should interpolate in double-quoted strings
On Sat, Sep 16, 2000 at 03:37:33AM -, Perl6 RFC Librarian wrote:
"%hash" should expand to:
join( $/, map { qq($_$"$hash{$_}) } keys %hash )
So let me get this straight...
%hash = (foo = 42, bar = 13);
print "%hash";
should come out to:
foo 42
bar 13
The idea of interpolating a hash is cool... but is seperating each
pair by $/ really useful? A comma or $" sees to make more sense.
Could you show some examples of practical usage?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in [EMAIL PROTECTED]
RFC 196 (v2) More direct syntax for hashes
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More direct syntax for hashes
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: 5 Sep 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 196
Status: Frozen
=head1 ABSTRACT
Cscalar(%hash) should return what Cscalar(keys %hash) currently
returns.
Creset %hash should reset the hash iterator, instead of calling
Ckeys or Cvalues as is currently the case.
The parser should special-case the variations of Csort %hash so
that it returns the keys and value, calling the comparison function
for keys.
=head1 CHANGES
* Clarified that new reset() syntax doesn't clash with existing
* Fixed braino in description of "sort %hash"
=head1 DESCRIPTION
While Perl has hashes as a built-in data type, the mechanism for
working with hashes is often built on top of list primitives. While
this is acceptable, it's not as convenient as it could be. I'm
arguing for more direct support of hashes in the language.
Proposal 1 is that a hash in scalar context evaluate to the number
of keys in the hash. You can find that out now, but only by using
the Ckeys() function in scalar context.
Currently C%hash in scalar context returns a false value if %hash
is empty, or a string like "4/8" showing how full the hash data
structure is. This string is rarely useful to the programmer.
Mostly it's just used for its true/false value:
if (%hash) { ... }
Proposal 1 would retain that use, but also make:
$count = %hash;
analogous to
$count = @array;
Proposal 2 is that the iterator in a hash be reset through an explicit
call to the Creset() function. In perl5, one must call Ckeys()
or Cvalues() to reset the iterator, an odd overloading of these
functions behaviour. I propose that the Ckeys() and Cvalues()
functions no longer have this side-effect, but instead reset() be
used:
keys %hash; # reset the iterator in perl5
reset %hash; # same but in in perl6
This function more obviously describes what is happening. reset()
also has a meaning, but that functionality does not clash
syntactically with this new meaning. In any event, the move away
from global symbol table actions will probably remove the current
functionality of reset().
Proposal 3 is to have the parser identify Csort %hash and its
variations, and automatically rewrite it.
I'd like to be able to say:
foreach ($k,$v) (sort %hash) { ... }
This would be equivalent to:
foreach ($k,$v) (map { $_ = $hash{$_}
sort
keys %hash)
{ ... }
Similarly one should be able to use a sort comparison function with
a hash. I do not expect this hash knowledge to apply to function
calls or anything else that might return key-value pairs. This is
purely when the data to be sorted is in a hash variable.
This relies on RFC 173's foreach() extensions to be useful.
=head1 IMPLEMENTATION
Proposal 1 simply changes the scalar value of a hash. The old
functionality would have to be available from a module for the perl526
program to be able to translate any program that relied on this
knowledge of the data structure (there are a few, though not many,
that do).
Proposal 2 removes the side-effects from keys() and values(), and
puts it into reset(). The reset() function is going to need a
profound overhaul anyway (given how intensely symbol-table driven
it is) and it is the obvious place for this functionality.
Proposal 3 could be done in the parser as a rewrite of the source
code. However, I suspect it would run faster if a flag on the sort()
op said "you're getting a hash structure" and sort() took care of
it all internally. That'd avoid multiple op dispatches. This is
an implementation decision for better performance, though. At the
bare minimum, source code rewriting would implement the function
with acceptable performance.
=head1 REFERENCES
RFC 173: Allow multiple loop variables in foreach statements
perlfunc manpage for keys(), values() and reset() documentation
perlsyn manpage for foreach() documentation
RFC 237 (v1) hashes should interpolate in double-quoted strings
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
hashes should interpolate in double-quoted strings
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 237
Version: 1
Status: Developing
=head1 ABSTRACT
"%hash" should expand to:
join( $/, map { qq($_$"$hash{$_}) } keys %hash )
=head1 DESCRIPTION
Hashes do not interpolate in double-quote context in perl5. They
should, because (a) scalars and arrays do, (b) it is a useful
thing.
The problem has always been: how to separate the keys and values? I
say use $" (the value that gets put between array elements in
double-quote interpolation) between key and value, and $/ between each
hash record.
A thorn is that $/ is the Binput record separator. It seems wrong
to use it for output. But $\ is not set by default, and it seems
unreasonable to have to set $\ (which affects the end of every print)
just to interpolate hashes. I didn't relish making yet another
special variable just for this, though.
When global variables like $" and $/ go away, I imagine they'll be
replaced with lexically-scoped variations. This will work then, too.
The big problem is that % is heavily used in double-quoted strings
with printf. I don't have a solution to this. In the end, this may
be Bthe definitive reason why hashes do not interpolate. And that's
fine by me.
=head1 IMPLEMENTATION
A simple change to the tokenizer.
The perl526 translator could backslash every % in a double-quoted
string.
=head1 REFERENCES
None.
Update: Wrapping up -data RFCs
Adam Turoff wrote: I didn't use Date::Parse, but I did look for all RFCs still stting at v1 status. Since they're numbered chronologically, I cut off the bottom (anything submitted after 9/7). There are 100 RFCs in the list that follows. Code and data upon request. Thanks Ziggy--very handy! There's only 3 from the list I'm looking after (-data), here's their status: RFC : 148 v1; Developing Title: Add reshape() for multi-dimensional array reshaping Maint: Nathan Wiger [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 24 Aug 2000 Nate is redrafting this as we speak--we're probably just about ready to freeze this. RFC : 191 v1; Developing Title: smart container slicing Maint: David Nicol [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 1 September 2000 There was quite a bit of discussion of various alternatives to this on list. David--could you incorporate these ideas into the RFC and see if we can get concensus. RFC : 196 v1; Developing Title: More direct syntax for hashes Maint: Nathan Torkington [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 5 Sep 2000 Discussion on this one has died down... Nat--could you incorporate the suggestions from the list and see if we can get this frozen? All other -data RFCs are still under active development, but I've asked all maintainers to have them frozen by next Wed (20/9) so that Larry has time to think about them before his release of the draft language spec.
