Redirected to perl6-language-flow.
At 12:23 PM 8/11/00 +0100, Graham Barr wrote:
On Thu, Aug 10, 2000 at 07:30:53PM -0700, Peter Scott wrote:
If we're really talking about new keywords, we wouldn't need a ; at the
end
of the last block; it's only needed at the moment because eval is a
"NI" == Nick Ing-Simmons [EMAIL PROTECTED] writes:
NI Uri Guttman [EMAIL PROTECTED] writes:
i think we do because a thread can block on a mailbox while it can't on
an array.
NI Why not ? - I see no reason that a "shared" array could not have
NI whatever-it-takes to allow
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Nope. The code that accessses the array needs to support it. Different
DS animal entirely. The ops don't actually need to know.
but still that is overhead code for all arrays and not just the mailbox
ones.
DS s/mailboxes/filehandles/;
At 12:54 PM 8/11/00 -0400, Uri Guttman wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Nope. The code that accessses the array needs to support it. Different
DS animal entirely. The ops don't actually need to know.
but still that is overhead code for all arrays and not just the
I've moved this from perl6-language to perl6-language-flow.
Tony Olekshy wrote:
With the approach proposed in RFC 88 (Structured Exception
Handling Mechanism), you could write that as:
try {
} catch {
switch ($_[0]-name) {
case IO { ... }
I've moved this from perl6-language to perl6-language-flow.
Graham Barr wrote:
eval {
# fragile code
}
else { # catch ALL exceptions
switch ($@) {
case __-isa('IO') { ... }
case __-isa('Socket') { ... }
On Fri, Aug 11, 2000 at 09:36:32AM -0700, Peter Scott wrote:
Redirected to perl6-language-flow.
At 10:39 AM 8/11/00 -0400, John Porter wrote:
Piers Cawley wrote:
The (continue|always|finally|whatever) clause will *always* be
executed, even if one of the catch clauses does a die, so
Peter Scott wrote:
John Porter wrote:
Which makes me think that it would be nice if the continue block
could come before the catch block(s).
I get where you're going with this but it breaks the paradigm too
much. Now you need a 'finally' block again.
Sometimes you want before,
# Open a remote webpage
$http = open http "http://www.perl.com/", GET;
^
1) The URL says that it's a http resource, so why do we have
to tell open to use a http handler?
a) Allows custom handlers:
open myhttp
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Modify open() to support FileObjects and Extensibility
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 04 Aug 2000
Last-Modified: 11 Aug 2000
Version: 3
Mailing List: [EMAIL
[cc'ed on internals as FYI]
=item 36 (v1): Structured Internal Representation of Filenames
I think this should be discussed a good amount. I think URIs are cool,
but too much trouble for simple stuff. I don't want to have to write
"file:///etc/motd" everytime I want to address a file. Too
How would this take into account stuff like this:
sysopen(HANDLE, "/etc/motd", O_RDWR|O_CREAT, 0644);
The "O_RDWR|O_CREAT" part is what I'm talking about here. This is a
constant w/o suffix. We'll either have to:
1. Change it to $O_RDWR|$O_CREAT or $O{RDWR}|$O{CREAT}
Maybe for
Perl6 RFC Librarian [EMAIL PROTECTED] writes, for Chaim Frenkel
[EMAIL PROTECTED]:
[...]
=item As a floating point number
The integer part would be the actual identifier. The fractional
part could encode some classification scheme.
Floating point numbers don't work this way. Suppose I
"AS" == Ariel Scolnicov [EMAIL PROTECTED] writes:
AS 2. Error codes as digit strings with decimal point. So "123.4567"
AS(_not_ 123.4567) represents error 4567. People will still try
ASstupid floating-point math tricks to get at the suberror code, but
ASat least we'll know
Graham Barr [EMAIL PROTECTED] writes:
Damian Conway [EMAIL PROTECTED] writes:
Leon Brocard writes:
=head2 $AUTOLOAD
While we're at it, it *may* be a good idea to remove the
global $AUTOLOAD variable and instead pass it as the first
parameter of the AUTOLOAD
=head1 TITLE
Replace = (stringifying comma) with = (pair constructor)
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 10 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 84
I like this a lot, especially the way it deals with subroutine
I think the whole idea of overloading the '' and '||' operators is too
farfetched. It's and incredibly dangerous can of worms, precedence rules
changing, shortcircits not working, etc.
Actually, we don't need it. All we need, is lazy evaluation.
The idea comes from Lisp, where you have a
On 11 Aug 2000 09:30:03 +0300, Ariel Scolnicov wrote (and quoted):
reduce avg $identity, @list
This was my first point regarding Creduce -- not all functions have
an identity element. One should note that in general
(reduce avg $x,@list) != (reduce sum 0,@list)/@list
for Iany value
On Thu, Aug 10, 2000 at 06:43:30PM -0400, Chaim Frenkel wrote:
"GB" == Graham Barr [EMAIL PROTECTED] writes:
GB On Thu, Aug 10, 2000 at 04:34:50PM -0400, Chaim Frenkel wrote:
Nice.
The continue clause, I assume would re-raise an uncaught exception.
But, a big but. How does the
On Thu, Aug 10, 2000 at 07:30:53PM -0700, Peter Scott wrote:
So I'm thinking:
eval { ...
} catch Exception::Foo {
...
} catch Exception::Bar, Exception::Baz {
...
} catch {
... # everything else, but if this block is absent, uncaught exceptions
# head up the call stack
On Thu, Aug 10, 2000 at 07:47:47PM -0600, Tony Olekshy wrote:
With the approach proposed in RFC 88 (Structured Exception
Handling Mechanism), you could write that as:
try {
} catch {
switch ($_[0]-name) {
case IO { ... }
case Socket { ...
On Thu, 10 Aug 2000 17:59:52 -0700, Glenn Linderman wrote:
I find nothing in the documentation that suggests that = is anything other than a
plain comma operator, yet you call it a "first-argument-stringifying comma
operator". In fact, the documentation explicitly claims "=" is a synonym of ","
On Thu, Aug 10, 2000 at 07:22:21PM -0400, Chaim Frenkel wrote:
Okay, then for
reduce avg $identity, @list
What should $identity be?
I would like to see what avg would be, given that each time it
would be passed the previous result (or the first element) and
the next element.
So
On Thu, Aug 10, 2000 at 10:21:37PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace = (stringifying comma) with = (pair constructor)
=head2 Pairs and arrays
When a pair reference is assigned (in)to an
On Fri, Aug 11, 2000 at 11:24:48AM +1000, Damian Conway wrote:
This can be correctly handled. The named parameter's context specifier
would be propagated to the right operand of the =. So:
sub demo ( $name, \%options ) {...}
will accept:
demo(options=%myopts, name='my
Graham Barr [EMAIL PROTECTED] writes:
On Fri, Aug 11, 2000 at 02:52:32AM -0700, Nathan Wiger wrote:
Mike-
Jeremy's got a great explanation of this, which I'll paraphrase, but the
discussion went through lots of iterations. Think of the ^ as a carat or
thumbtack, holding the place for
"Glenn" == Glenn Linderman [EMAIL PROTECTED] writes:
Glenn No, but the documentation for strict is some of what I reread
Glenn before making a fool of myself arguing with Damian, and it says
Glenn nothing about barewords, as far as I could read.
Even this part? ...
strict subs
At 02:29 PM 8/11/00 +1000, Jeremy Howard wrote:
Dan Sugalski wrote:
The syntax is actually:
my type $varname;
This is in perl 5.6.0. Modifiers go as attributes after the colon:
my Dog $spot : constant = new Dog;
Yes. But what about types and attributes within complex types?
On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote:
/^_/
What is that matching ?
We've done this. It's matching a string that begins with '_'. Which is
why, if you want to disambiguate you do /^{_}/ just like you do with
variables.
No that won't work either. That matches
Graham Barr [EMAIL PROTECTED] writes:
On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote:
/^_/
What is that matching ?
We've done this. It's matching a string that begins with '_'. Which is
why, if you want to disambiguate you do /^{_}/ just like you do with
"Graham" == Graham Barr [EMAIL PROTECTED] writes:
Graham No that won't work either. That matches the string {_}
But that's arguably a DWIMmy thing, since {} is in the category of * +
and ?, which always need to be *after* something, and there's no
*something* here. I don't know how much stuff
On Fri, Aug 11, 2000 at 02:03:47PM +0100, Graham Barr wrote:
On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote:
/^_/
What is that matching ?
We've done this. It's matching a string that begins with '_'. Which is
why, if you want to disambiguate you do /^{_}/ just
On Fri, Aug 11, 2000 at 02:52:32AM -0700, Nathan Wiger wrote:
Mike-
Jeremy's got a great explanation of this, which I'll paraphrase, but the
discussion went through lots of iterations. Think of the ^ as a carat or
I only make this annoying and pedantic point because everyone I have
seen
I'm leaning to splitting identifier from the classification.
A pure monotonically increasing integer would ensure the non-reuse.
And the classification scheme could evolve seperately.
Using numbers for the classification scheme would require a translation
table. So why not just use
Piers Cawley wrote:
Graham Barr [EMAIL PROTECTED] writes:
On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote:
/^_/
What is that matching ?
We've done this. It's matching a string that begins with '_'. Which is
why, if you want to disambiguate you do /^{_}/ just
Graham Barr wrote:
If we're really talking about new keywords, we wouldn't need a ; at the end
of the last block; it's only needed at the moment because eval is a
function, not a keyword. I would vote for the keywords only because people
are going to forget the ; otherwise.
That
John Porter [EMAIL PROTECTED] writes:
Piers Cawley wrote:
The (continue|always|finally|whatever) clause will *always* be
executed, even if one of the catch clauses does a die, so you can use
this to roll back the database transaction or whatever else was going
on and restore any
Damian Conway wrote:
More and more I lean towards a scalar-only reduce.
Yep!
Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need
multidimensionals.
Combined with highlander variables, and there ceases to be a problem.
--
John Porter
John Porter [EMAIL PROTECTED] writes:
Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need
multidimensionals.
Combined with highlander variables, and there ceases to be a problem.
Will you stop with the highlander variables?
--
Piers
Someone on this list (TomC?) has supplied a major diatribe against const.
chaim
"JH" == Jeremy Howard [EMAIL PROTECTED] writes:
JH Dan Sugalski wrote:
The syntax is actually:
my type $varname;
This is in perl 5.6.0. Modifiers go as attributes after the colon:
my Dog $spot : constant
Bart Lateur wrote:
I have some reservations about this reduce() thing. Plain and simple
incorporating it into the core language would introduce the chance for
lots of buggy programs, like the example Arial gave. In fact, I think
that *most* programs that use reduce() would be buggy.
On Fri, 11 Aug 2000 11:01:30 -0400 (EDT), Simply Hao wrote:
What about with -w:
read = $value
What warning?
Oh, you're probably using a pre-5.005 Perl. 5.004 (the latest MacPerl,
for example) still had that warning. 5.005 and later, do not, any more.
--
Bart.
"PC" == Piers Cawley [EMAIL PROTECTED] writes:
PC The (continue|always|finally|whatever) clause will *always* be
PC executed, even if one of the catch clauses does a die, so you can use
PC this to roll back the database transaction or whatever else was going
PC on and restore any invariants.
Bart Lateur wrote:
Actually, we don't need it. All we need, is lazy evaluation.
The idea comes from Lisp,
No, that's no good; lazy evaluation was necessitated by functional
programming, which of course perl should avoid like the plague...
--
John Porter
At 10:58 AM 8/11/00 -0400, Chaim Frenkel wrote:
Someone on this list (TomC?) has supplied a major diatribe against const.
Maybe, but I don't see what's wrong with:
my $foo :const = 12;
A nice, named, lexically scoped constant. The optimizer should be able to
make reasonably good use of that.
At 11:13 AM 8/11/00 -0400, John Porter wrote:
Bart Lateur wrote:
Actually, we don't need it. All we need, is lazy evaluation.
The idea comes from Lisp,
No, that's no good; lazy evaluation was necessitated by functional
programming, which of course perl should avoid like the plague...
Why?
Chaim Frenkel [EMAIL PROTECTED] writes:
"PC" == Piers Cawley [EMAIL PROTECTED] writes:
PC The (continue|always|finally|whatever) clause will *always* be
PC executed, even if one of the catch clauses does a die, so you can use
PC this to roll back the database transaction or whatever else
At 10:42 PM 8/10/00 -0400, Chaim Frenkel wrote:
PS Can this be merged with RFC 80, or do they need to live apart?
I believe they do. This portion can independently survive without
an exception mechanism. I'm only addressing the "what error did
I get". You are addressing the error handling
On Thu, Aug 10, 2000 at 05:46:14PM -0400, Bennett Todd wrote:
Today there's no difference. If the proposal under discussion were
to pass, and packages' namespaces were to become local to the
namespace where the "use" occurred, then perhaps main::whatever
could be a common, stable, global
On Fri, Aug 11, 2000 at 03:30:28PM -, Perl6 RFC Librarian wrote:
=head1 ABSTRACT
It is proposed that two new functions, Czip, and Cunzip, be added to
Perl. Czip(\@list1, \@list2, ...) would return a list that interleaved
its arguments. Cunzip($list_size, \@list) would reverse this
On Fri, Aug 11, 2000 at 03:36:21PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: partition
=head1 VERSION
Maintainer: Jeremy Howard [EMAIL PROTECTED]
Date: 11 August 2000
Version: 1
On Fri, Aug 11, 2000 at 04:22:33PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace localtime() and gmtime() with date() and gmtdate()
I think to be politically acceptable to all that should be utcdate()
Replace localtime() and gmtime() with date() and gmtdate()
I think to be politically acceptable to all that should be utcdate()
Me too. Actually, this was my first choice, believe it or not.
The problem is, many people on this list claimed that GMT != UTC, and
that machine time is only in
I know other languages call it zip, but personally I dislike
that name as zip() is commonly used with reference to compression.
Ditto, I really dislike zip() and unzip(). They're PC and even UNIX
commands on several platforms now, increasing confusion.
Here's two names: mix() and unmix().
On Fri, Aug 11, 2000 at 10:06:38AM -0700, Nathan Wiger wrote:
I know other languages call it zip, but personally I dislike
that name as zip() is commonly used with reference to compression.
Ditto, I really dislike zip() and unzip(). They're PC and even UNIX
commands on several platforms
At 10:34 AM 8/11/00 -0400, John Porter wrote:
But I'm against the idea of implicit rethrowing in any case.
Sure, other languages do it, but perl doesn't, and personally I think
it's a better paradigm.
We may have to disagree. If you don't have a clause to catch an exception,
semantically, it
I know other languages call it zip, but personally I dislike that name
as zip() is commonly used with reference to compression. Although
I do not have a good alternative.
fold() and unfold()?
merge() and cleave()?
A
well, if it is only a string, why use . as the separator? use something
else like : and no one will try any fancy math tricks on it.
Agreed. I like :, it's a common separator.
Also, how about just $@-id? Shorter and I would argue the "unique_" is
really redundant (id's are usually unique,
On 11 Aug 2000, Perl6 RFC Librarian wrote:
its arguments. Cunzip($list_size, \@list) would reverse this operation.
[...]
In order to reverse this operation we need an Cunzip function:
@zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6)
@unzipped_list = unzip(3, \@zipped_list); #
Andy Wardley wrote:
cleave()?
Note that cleave is its own antonym! :-)
--
John Porter
On 11 Aug 2000, Perl6 RFC Librarian wrote:
@ARGS is a better choice for several reasons:
1. It's closer to a word and so is faster to read [1]
2. It's easier to explain and remember "Your command-line
args are contained in @ARGS"
3. When you say "$var = $ARGS[2]" it's
On Fri, Aug 11, 2000 at 10:51:45AM -0400, John Porter wrote:
Damian Conway wrote:
More and more I lean towards a scalar-only reduce.
Yep!
Have you stollen my brain :)
Graham.
On Fri, Aug 11, 2000 at 10:26:25AM -0700, Peter Scott wrote:
At 10:34 AM 8/11/00 -0400, John Porter wrote:
But I'm against the idea of implicit rethrowing in any case.
Sure, other languages do it, but perl doesn't, and personally I think
it's a better paradigm.
We may have to disagree.
Spinning off from Larrys syntactic comment and Mike
Pastores example, how about some of the following:
How about any variable created in UPPER case is a constant?
Quite restrictive, and likely to screw many things up, admittedly,
but it's an easy rule to remember and one which is generally
On Fri, Aug 11, 2000 at 06:25:07PM +0100, Andy Wardley wrote:
I know other languages call it zip, but personally I dislike that name
as zip() is commonly used with reference to compression. Although
I do not have a good alternative.
fold() and unfold()?
People would confude that for
On 11 Aug 2000, Perl6 RFC Librarian wrote:
In the past, Perl has provided access to date and time information
through the C library Clocaltime() and Cgmtime() functions.
Unfortunately, these functions have several "really bad things" about
them:
1. some values are 0-indexed while
On Fri, 11 Aug 2000, Andy Wardley wrote:
Spinning off from Larrys syntactic comment and Mike
Pastores example, how about some of the following:
How about any variable created in UPPER case is a constant?
Quite restrictive, and likely to screw many things up, admittedly,
but it's an
Andy Wardley wrote:
I know other languages call it zip, but personally I dislike that name
as zip() is commonly used with reference to compression. Although
I do not have a good alternative.
fold() and unfold()?
merge() and cleave()?
A
collate() and ...?
On 10 Aug 2000 22:26:47 -, Chaim Frenkel [EMAIL PROTECTED] wrote:
=head2 Encodings
I have listed some possiblities. But none of these are ideal.
=head3 A unique number
=item As an integer
=item As a floating point number
=head3 Unique String
=head3 Prefixes for all error strings
On 11 Aug 2000, Perl6 RFC Librarian wrote:
=head1 TITLE
Replace localtime() and gmtime() with date() and gmtdate()
Since GMT is specific to the UK and UTC (Universal Time, Coordinated) is
the global equivalent, shouldn't the names be date() and utcdate()?
=head1 VERSION
Maintainer: Nathan
The difference is how they group:
@unzipped_list= unzip(3, (1,2,3,4,5,6)); # ([1,3,5],[2,4,6])
@partitioned_list = partition(3,(1,2,3,4,5,6)); # ([1,2,3],[4,5,6])
Let me make an observation, having done tons of matrix stuff: We're
going to wind up with 200 functions, all of which
Jarkko Hietaniemi [EMAIL PROTECTED] writes:
s/gmt/ut/
IIRC GMT got obsoleted in the 70s by UT (Universal Time).
Officially called UTC, so utcdate would be a better name I think.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
On Fri, 11 Aug 2000, Nathan Wiger wrote:
Let me make an observation, having done tons of matrix stuff: We're
going to wind up with 200 functions, all of which essentially are doing
special types of matrix operations.
How about a matrix-like set of functions that interleaves and
On Fri, Aug 11, 2000 at 06:36:44PM +0100, Andy Wardley wrote:
How about any variable created in UPPER case is a constant?
This involves Perl dictating style to the user. Very un-Perllike, IMHO.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator
=head2 Date Arithmetic
Date arithmetic has been axed from this proposal. Before you get too
upset, I had discussions with several people and became convinced that
this is something too difficult and bloated to stick in core. An
external module would be much better suited to this. We can
Bart Lateur [EMAIL PROTECTED] writes:
Actually, we don't need it. All we need, is lazy evaluation.
The idea comes from Lisp, where you have a possibility to create
ordinary looking functions (in Lisp, there's no difference between a
function and an operator; the less polite name is "prefix
On Fri, 11 Aug 2000, Nathan Wiger wrote:
Adding support for (modified) Julian Date will be much more
generic and remove dependency on unix epoch with little
extra code.
To me, the real question is which date() should we use:
$date = date $seconds_since_epoch; # uses time()
Buddha Buck [EMAIL PROTECTED] writes:
UT and UTC are different scales, ref:
http://tycho.usno.navy.mil/systime.html
I believe, as reflected on that page, that UT isn't a time scale in and of
itself, but a system of them (including UT0, UT1, and UTC as a weird
step-child based on TAI with
Nice. But you need to discuss the initial condition: I'd guess you need
an
implicit
=begin perl
before line 1 of each script file, so that scripts that don't pod still
work.
How about some extensions, which integrate another old perl5 feature?
Instead of __END__, how about
=begin data
Now
Please, please, please, PLEASE, let us not replicate the debacle that is
C++'s const modifier!
Damian
Damian Conway wrote:
Note that cleave is its own antonym! :-)
I can see it now:
@interspersed = cleave(@list1, @list2, @list3)
@separated= cleave(3,@interspersed);
Now *that's* DWIM! ;-)
In fact, perl really only needs one OP:
@results = dwim $stuff,
Note that cleave is its own antonym! :-)
I can see it now:
@interspersed = cleave(@list1, @list2, @list3)
@separated= cleave(3,@interspersed);
Now *that's* DWIM! ;-)
Damian
I kinda like it. It's... intuitive. It makes named sub arguments rather
straightforward, apart from that prefix thing.
Should (name = 'Bart') really stuff 'Bart' into a lexical variable
$name? That's... odd.
Not really. If (name='Bart') is an arg list, it probably stuffs
@array = ( a=1, b=2, 'c', 3 );
assigns four elements (not six) to @array.
But won't this cause breakage to existing scripts
No. p52p6 will simply translate:
x = 'y'
to
'x', 'y'
Note that these semantics still support the popular:
A better example might be trying to perform join, with reduce eg
reduce __.','.__ $identity, @list
Which would not work for any value of $identity unless you did
reduce __.','.__ shift @list, @list
which is probably a good example why not to require an
Then, we could simply write our own versions of shortcutting AND and OR.
The difference would be that it would look like a function, not like an
operator. Compare:
expr1 expr2
vs.
AND(expr1, expr2)
but at least, there would be no confusion WRT
But... would it be possible to exten this proposal so that, if the right
hand operand is an array or hash variable, it will create a reference to
this variable?
That would allow subroutine calls like:
foo('names' = @names, 'size' = 'A4', 'labels' = %labels)
to do
I like the idea of currying, it seems powerful and Perlish in many
ways. However, I don't like the currying operator chosen, because
of it's ugliness (IMHO), and its potential for ambiguity (human,
not necessarily parser).
It's not an operator, it's a placeholder.
So,
I've started talking about "containers" instead of arrays and hashes
since those both tie directly to implementation details, and containers
are abstractions.
A self-sorting container would be easy enough to tie to, most methods
would inherit from an underlying numbered array, except the
Glenn Linderman wrote:
But you need to discuss the initial condition: I'd guess you need
.
=end all begin perl
I like it!
This would restrict data from containing lines beginning with =, or at
least lines
beginning with =end, =begin, =handle, or =for. Could "escape" with \=
or ==
Peter Scott wrote:
Perl 5.6.0 has [[:lower:]] and [[:upper:]].
Yes, but this one is worth a digraph. Question is, which one? Currently
the free ones are:
\F \h \H \i \I \j \J \k \K \m \M \o \O \q \R \T \v \V \y \Y
\v \V are being debated on p5p currently.
I suggest \i
[EMAIL PROTECTED] writes:
: p52p6 would handle it (by translating all Perl 5 Cx="y"'s to Perl 6
: C'x',"y"'s.
:
: I *must* put this in the RFC!
I think most of the RFCs could use a MIGRATION POLICY section, or
some such.
Larry
Nathan Wiger wrote:
...if the "key" and "value" builtins were the only ways to
get to the data. You should be able to get to the data directly.
How about:
$array[0].k
$array[0].v
--
John Porter
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 10:58 AM 8/11/00 -0400, Chaim Frenkel wrote:
Someone on this list (TomC?) has supplied a major diatribe against const.
DS Maybe, but I don't see what's wrong with:
DS my $foo :const = 12;
DS A nice, named, lexically scoped constant. The
methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
What is a better syntax for this?
tie %thehashinquestion, 'Sorted', flubber(^a,^b);
???
Damian
In fact, perl really only needs one OP:
@results = dwim $stuff, @args, %hey;
(Well, I guess that's two: the assignment is an op also.)
dwim @results, dwim $stuff, @args, %hey;
Can you say 'Lisp'?
Damian
"PC" == Piers Cawley [EMAIL PROTECTED] writes:
PC Good OO programming practice. Use polymorphism to replace switches. Then
PC when you subclass one of your classes you don't have to go 'round
PC rejigging the switch statements.
I haven't used OO in anger. But for me polymorphism is
At 05:09 PM 8/11/00 -0400, Chaim Frenkel wrote:
Hmm, perhaps we should rename the attribute
:read-only
Works, though I like "constant" (or const, that's OK) just as much.
Might be worth having a way to set things to read-only temporarily, too.
Won't help the optimizer, but it could
Damian Conway wrote:
methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
What is a better syntax for this?
tie %thehashinquestion, 'Sorted', flubber(^a,^b);
???
Damian
Compiler will know to pass flubber as ref-to-code instead of
intant eval because
Damian Conway [EMAIL PROTECTED]:
This RFC proposes the introduction of a new data type -- the Ipair -- and
the co-opting of the = operator to act as a pair constructor. Most existing
uses of = would be preserved.
[etc.]
%hash = ( a=1, b=2, 'c', 3 );
does what it does in Perl 5,
1 - 100 of 137 matches
Mail list logo
