Hi, folks. As has probably been obvious to most of you, I've been
really busy with my O'Reilly day job and haven't had time to attend to
Perl 6 and Parrot business. With no prompting, Allison Randal stepped
forward and has been taking on more and more of the day-to-day running
of the show.
From newsforge:
nile writes, Today, dLoo released the complete architecture of an
extensible peer-to-peer programming language. Unlike traditional languages,
this language is defined on the Internet. Its syntax and semantics can be
extended by posting additional pieces of the language. As
Dan Sugalski writes:
Doing it properly in a module is significantly more of a pain than doing it
in the core. Faking it with a module means a fair amount of (reasonably
slow) perl code, doing it in the core requires a few extra lines of C code
in the method dispatch opcode function.
Anyone seen this? It has a little of the flavour of what we're
going to do.
http://xlang.sourceforge.net/
Nat
Ariel Scolnicov writes:
Am I the only one here who's confused?
How does the printing happen in the correct order? I mean, if I said
my $x = Post order: show($root, $post)\n;
print $x;
then (I hope) we're agreed printing would happen in the *wrong* order
(first the output of
Dave Storrs writes:
at first I was alarmed and a bit appalled at a lot of the
changes...e.g., the 'HASH $tree is rw' parameter declaration.
Jesus, I thought if I wanted a typed languaged, I'd use C++.
The more I read, however, the more I became convinced that these
were actually elegant
Edward Peschko writes:
Ok, question here. Are these exegesises 'blessed'? What is open to
debate on this?
As Simon says, ask whatever questions you want.
print Post order: ; show($root,$post); print \n;
would be better off written as:
print Post order: show($root, $post)\n;
wouldn't
Simon Cozens writes:
On Tue, May 15, 2001 at 03:47:36PM -0700, Mark Koopman wrote:
i think that's the idea...they have similar meanings, so they should do
similar things. hey it's the English language, i'll leave it up to someone
else to come up with the 7 other ways to prove ownership of
Michael G Schwern writes:
$foo has true doesn't flow as well as $foo is true. Dunno quite
what the other expected uses are.
$foo has truth; # :-)
This leads naturally to:
$foo has the_buddha_nature;
$foo has ten_days_to_live;
$foo has meddled_in_my_affairs_one_too_many_times! # !
Larry Wall writes:
wanted, you still get the length. If you're worried about the delayed
operation, you can force numeric context with $x = +@tmp;, just as you
can force string context with a unary ~.
How often are you likely to do this? Speaking as a reader of code,
I've always hated unary
I don't think that extreme positions (minimalist! bloater!)
helps here. I think the important question to ask about any given
feature is: what will it let me do? Features with no good answer to
this question obviously have no place in core. Attempting to align
with one or another
Andy Dougherty wrote:
Yes, precisely. I often have one-liners embedded in larger shell scripts.
Most of those survived the perl4-perl5 transition intact. I'd hope the
same can be said for the perl5-perl6 transition.
This is exactly the situation that Larry mentioned on Wednesday as
an
Not a comment at all on it? Was I accidentally unsubscribed to
perl6-language?
*tap* *tap* is this thing on?
Nat
Peter Scott wrote:
Some of us got to reading Damian's design for Perl 5+i which was announced
at the same time and are suffering from blown minds after learning how fast
he wrote the thing.
Consider how blown his mind is after WRITING it :-)
Oh, and who put him up to that, eh?
I'm sure I'd
Title: http://dev.perl.org/rfc/73.html
[25]RFC 73: All Perl core functions should return objects
[...]
I'm thinking that the solution is better abstract type support
for data values that happen to be represented internally by C
structs. We get bogged down when we try to translate
Glenn Linderman wrote:
New RFC ideas?
Please, dear God, no. :-)
Nat
Larry's approaching perl6 through the Programming Perl book (the Camel).
He's going chapter by chapter through the Camel, writing documents about
the perl6 equivalent concepts. These missives are known as "Apocalypses",
for reasons best known to Larry. :-)
He's churning through the RFCs,
Espen Harlinn writes:
I'm trying to locate information about the Perl 6 Language, i.e. what
changes are proposed to the Perl language and so on.
Can anyone point me in the right direction ???
In case anyone else is wondering:
http://dev.perl.org/
Nat
Jarkko Hietaniemi writes:
True, but you can't do any of all that without knowing the platform
accurately (nontrivial and requires core mod or XS). Once that's
done, the rest is just a matter of extending File::Spec
(trivial and pure Perl).
Trivial? *cough* *snigger*
If it was
John van V writes:
If perl.org is unacceptable for some reason I can easily create a
mailing list on puny.vm.org
Thanks for the offer, but I don't think we'll need it. I think we're
hampered right now by the fact that we don't know much about what
perl6 is going to look like. Until we get
--- start of forwarded message ---
# CFP in English, followed by French (see below) #
Third North American YAPC: First Call for Participation
Yet Another Society
calls for your participation in
John Porter writes:
Perl6 ought to support pluggable sort algorithms, just as Perl
now supports pluggable comparison functions.
By "pluggable" you mean that sort() should be overridable?
Nat
I just got off the phone with Larry. He's been laid up for three
weeks with a trip to Japan followed by a virus from Japan. He's on
his feet again, and continuing to work through the RFCs.
He's changing the way he's doing it. Now he's going to try to find
clusters of RFCs on a particular
Here's the rest of my transcription of Larry's talk. He hasn't had
time to proofread it, so I'm posting it now in the interest of getting
it out. Ask, please add it to your page at dev.perl.org. When you
do, please send mail to pudge and mjd so they can announce the
completed transcription on
Here's a summary of the points that came up in Larry's Atlanta Linux
Showcase talk. I've run this summary past Larry, and he has approved
it as being a fair representation of what he said. Remember that
these are just his current thoughts, not concrete decisions.
This is available on the web
Uri Guttman writes:
overall i agree. but i use objects much more now and don't think about
the runtime cost at all (estimated to be %30)
All the world is not an Uri.
I know a company that had to rewrite most of their OO code because it
was the bottleneck in their application. The rewrite was
David L. Nicol writes:
interim()?
In discussing how to rename "local"
we appear to be trading in the spatial metaphor for the temporal.
How about
fornow
I'd rather not revisit this, or any other, RFC until Larry's had a
chance to *really* comment and put forward his suggestions.
It's time for the XML vs POD discussion to end. The RFCs are in
limbo now, and this conversation is serving no visible purpose.
Thanks,
Nat
It's valid to want to change the cultural makeup of perl6, but the
-language list is not the place for it. Try perl6-meta, and please
make concrete proposals. I see this "p5p sucks, we need something
better" as pointless unless there are definite ideas of what would
be better.
Nat
Chaim Frenkel writes:
What about formating the output as a value that can be used by eval?
%hash = (a = 1, b = 'the world');
print "%{hash}\n";
('a' = 1, 'b'= 'the world')
Interesting.
And as for having to escape % in printf strings. Why not enable the
interpolation if the
Michael G Schwern writes:
RFC 142 may help out existing un/pack users, but does nothing to help
in the understanding of un/pack by native speakers of Perl.
I'm starting to think this is largely a documentation issue.
Yes. Please put this thread out of our collective misery.
Nat
Michael G Schwern writes:
You can do it! While it seems "food" and "supermarket" are critical
to the understanding of a shopping-cart, they're really just
incedental. I'm saying the same thing about un/pack!
If I grok'd the bastards, I'd write the explaination myself.
Please take this
At this point, I think the whole thread on functions throwing
exceptions should either be:
(a) turned into an RFC
or
(b) abandoned.
This discussion is going around and around like a piece of toilet
paper in a weakly-flushing toilet.
Nat
Sven said:
As I mailed to Nathan Torkington several days ago (without getting
a reply), many people use chop() a lot and his perl526 substitute
"s/.\z//s;" will not work because it returns the number of
chars changed, not the char itself like chop() does (as opposed to
chomp()).
Perl6 RFC Librarian writes:
This RFC proposes two-stage autoloading: one stage may be registered
to act when the symbol is encountered at compile time, the other
when the subroutine is called. Autoloading on the second stage does not
Icall the subroutine, only Iloads it.
You have a
My first preference is for overriding constant strings.
My second preference is to provide a user-defined quoting operator mechanism,
possibly as part of a user-defined operator mechanism.
My third preference is for a new operator.
I personally do not want to see q() screwed with.
Nat
Chaim Frenkel writes:
I would like to have an undef returned.
Ah, I see. You want subroutines to return undef if they're given it
for any of their arguments. That'd break the lazy programmer practice
of passing undef expecting it to become "" or 0. They don't have
warnings on, of course.
Piers Cawley writes:
TBH, I'm not sure I want to go too far down that road in this RFC. And
tbh they seem more like internals issues to me. The runtime behaviour
this change grants is good enough for me and I don't want to see the
proposal bogged down in flamage about strict types. Of course,
Michael G Schwern writes:
I have misgivings. I like single-quote context *because* you don't
have to worry about anything magical (except ' and \).
Genericise it.
Alter the overloaded string constant behaviour of perl5 so that
when you say:
use MagicInterpolativeStrings;
$foo = '$bar
Damian Conway writes:
Either you give up interface polymorphism (a grievous loss) or you give
up static type-checking.
Blech, you're right.
Actually, it's inheritance polymorphism that proliferates pretend classes
like Pet.
I meant that. Sorry, you're so in tune with Perl that I'm
Randal L. Schwartz writes:
This proposal makes length() an un-prototypable (and therefore
unoverridable). Do you have a proposal for how to handle that?
Do we really want everything in Perl to be overridable? What
use is an overridden length()?
Nat
Nathan Wiger writes:
Brainstorming off the top of my head:
sub length (($|@)) {
}
That is, use a regex-like "(x|y)" - or maybe [$@%] ?? - for alternative
context coercions.
The only RFC on prototype extensions we have is Andy Wardley's #57.
I suggest you ask him to add this
Casey R. Tweten writes:
Ok, consider allowing:
$a = length @b;
to DWIM, however, when running with warnings, warn the user that Cscalar is
what they really want.
Just thowing that out there.
Good idea, but I think it's a bad move to turn warnings into style
guides. Warnings should
Perl6 RFC Librarian writes:
An inconsistency between "Cprint" and "" bugs me: "Cprint;" means
"Cprint $_;" so it seems like "" should mean "C$_ = ".
I can't yet think of code that this extension would break.
I assume you mean that in void context should assign to $_?
Any code that has set
Chaim Frenkel writes:
Removing -1 as a valid result, could be a breakage (if someone is
doing something weird with a negative result)
I don't care, so long as the perl526 translator can wrap perl6's
index/rindex. And I gave sample code for it to do that.
Would it be reasonable to ask that
Chaim Frenkel writes:
Somehow I find
if (40 == ($foo = substr($bar, index($bar, 'xyz' {
}
I don't understand your hypothetical code. substr() returns the
substring of $bar from the position retutned by index, onward.
When would this be 40, if index is going to return the
Sorry, I can't help but read the subject as an abbreviation of
post Hugo, ergo propter Hugo
and then I wonder why you're naming an RFC after a logical fallacy
involving a perl5-porter. I am seeking treatment, though :-)
Nat
Michael G Schwern writes:
Creset %hash should reset the hash iterator, instead of calling
Ckeys or Cvalues as is currently the case.
Sounds good, except the name. reset() already does something.
Currently, reset() is for clearing large swaths of global variables (a
dubious feature) and
Michael G Schwern writes:
Okay, the example says on thing and the text of the proposal says
another.
Sorry, I thought you were talking about a different section of code.
I'll resubmit tomorrow.
So you're proposing that Csort %hash act like Cmap { $_ =
$hash{$_} } sort keys %hash? I can
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Nat
Eric Roode writes:
Useful functions all, no doubt. But I would lobby heavily for a new
set of names -- ones that can be remembered! Quick -- which trims
leading spaces, champ, chump, or chimp?
My favourite: chafe().
Nat
Karl Glazebrook writes:
Yes. And for the record I also think the current approach of lets generate
ten million RFCs and Uncle Larry knows best is nuts. There are already
too many RFCs on this topic alone to grasp coherently.
Do you have a better suggestion?
Nat
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
Nat
(I'm going to RFC these if nobody presents any killer complaints about
them, it's just that writing RFCs is more work than I want to go through
for tiny little changes like these, especially if they turn out to be
dumb).
%hash in scalar context should return what scalar(keys(%hash))
currently
Tom Christiansen writes:
So code that says
chop($k,$v)
will need to say
for ($k,$v) { s/.\z//s }
or else something like:
for ($k, $v) { substr($_, length() - 1) = '' }
I don't think chop() is an operation that's done often enough for
either of the things above to be
Tom Christiansen writes:
But %hash-BUCKET_USE() should return what's currently there.
Do you really use this information? Really? I have no objection
to supplying a way to discover it, but this might even be in an
external module rather than built into the language given how rarely
it's used.
Tom Hughes writes:
I must admit it had never occurred to me that somebody might
deliberately use keys or values to achieve that, but I guess
somebody might be relying on it without realising it.
while (($k,$v) = each %foo) {
last if ...;
}
keys %foo;# reset the iterator
It's probably worth reading through the Python Enhancement Proposals
(PEPs) to see if there's anything that makes sense to steal:
http://python.sourceforge.net/peps/
Nat
Michael Maraist writes:
Compatibility is going to have to be maintained somehow. And we can either
have some sort of perl6 designator (such as the pragma) to designate
incompatible (and otherwise ambiguous) code, or we're going to have to
continue tacking on syntactic sugar to legacy code.
Matt Youell writes:
As I think about this, however, I can imagine that some might want to force
it's use. Perhaps that requirement could be built into a strict pragma, like
'use StrictTypes' ?? I seem to recall an RFC along those lines.
My idea for
use strict 'types';
is that Perl
Dan Sugalski writes:
Sure, it's handwaving, but it's handwaving with a purpose. What I don't
want is for people to get bogged down by the limits of what perl 5
provides, or what looks to be some sort of reasonable extrapolation
of those features.
If a fully working tie's what you need,
Tom Christiansen writes:
Also, there are many array operations (push, pop, etc) still not
supported by tie.
Eh? Either that's no longer true, or we're doing the time warp again.
Right you are. I'm still living in the 20th century :-)
Nat
Tom Christiansen writes:
If the goal is to make Perl parsable by emacs, might as well just
say that.
That's not my goal.
Damian's Text::Balanced does a pretty good job of tokenizing Perl
as it is. / by itself requires a lot of lookahead, and it's still
a guess.
Being able to have any
Tom Christiansen writes:
There are unsolvable problems here, though.
Unsolvable without knowledge of the Perl language, yes. As
always, easy tasks will be easy and there'll be a continuum of
difficulty as the task gets harder.
I just want easy filters to be possible!
Nat
Bart Lateur writes:
I don't get it. What makes it so hard? If you see a "/" when you're
expecting an operator, or end of statement, then it's division. If you
were expecting an expression, it's a regex. Ain't it?
We're talking tokenizing vs parsing. If I'm just getting back a
sequence of
David L. Nicol writes:
If we use exceptions of some kind to handle
syntax, encountering an exception of type "unknown-keyword:Cmp" could
result in the subroutine definition getting run to clarify this piece
of code.
I'm nervous about this. I'm trying to picture what happens, and
having
We need a way to mix eq, the things to be compared, and the operation
to be done on them before they are compared:
lc{ $foo eq $bar }
$foo eq (lc) $bar
$foo eq{lc} $bar
None of those are like any existing syntax in Perl. The current way:
lc($foo) eq lc($bar)
seems fine in
Dan Sugalski writes:
Personally I think I'm in favor of Nat's suggestion of allowing the
definition of new infix operators and let this be taken care of in a
module, but that's just passing the buck. (Not that it's a bad strategy,
mind... :)
Solve the generic problem, not a specific one.
Bart Lateur writes:
Oh. I would have put my hopes on a better (= more generic) O::Deparse
mechanism to make Perl analyse the source code for you. Rewriting a Perl
in a module seems a bit silly to me.
I don't know enough swear words to say how much I fucking hate the
stupid braindead dumbfuck
On the subject of 'strict', I'm looking forward (once the typing
proposals string out) to having
use strict 'types';
To turn Perl into full BD mode. This will also enable maximum
optimizations.
I'm picturing type-checking at this level:
my hash %a;
my StructuredHash %b;
%b = %a;
David L. Nicol writes:
okay but we still have the hiding issue, in case we want it to
What's the hiding issue? I must have missed that.
$one{two} is $one\two
$$one{two}{three} is $one\two\three
$$$one{two}{three}{four} is $one\two\three\four
Your left
David L. Nicol writes:
Do either of those expressions make sense in terms of
references to something? If not, then syntactically we
are in the clear. They don't, because currently it makes
no sense to butt a reference up to the LHS of anything.
It isn't any less clear than, for instance
John Porter writes:
I suppose that's true. But why would
%( foo = 1, bar = 2 )
be "working harder" than
%{{ foo = 1, bar = 2 }}
??? It's few keystrokes and would be a less tricky concept
to remember.
It's a new syntax, not orthogonal to anything we already have. The
number
John Porter writes:
So? Perl's not like that. Perl is diagonal. And this is just
another corner being cut.
Cut away enough corners, and you have a black hole. Or something :-)
My point is that before you reach to invent new syntax, see if there's
a way to do what you want with the
Steve Fink writes:
My code for doing what I thought Exporter did is:
sub import {
my $p = caller(1);
*{"${p}::E"} = \%{"${p}::E"};
}
but that doesn't run afoul of use strict 'refs'. Can you point me to the
passage in Exporter.pm that uses this?
It does run afoul of use strict
Damian Conway writes:
If domeone is putting this RFC together, please remember to propose
that Ceval and Cdo should handle opcodes as well as source:
host-a:foo.pl: dump SOCKET;
host-b:bar.pl: { local $/; eval SOCKET };
Or:
sub suspend { open $fh, "$_[0]" or die;
Casey R. Tweten writes:
Wow. Now that, that, is lame. You're saying that keys() expects
it's first argument to begin with a %? Why should it care what it's
argumen begins with?
The keys function changes its arguments' data structure. keys resets
the each iterator (see the documentation
Don't forget that the rationale behind the infix dereferencing is
this:
@variable_name
@{variable_name}
@$scalar_containing_variable_name @$scalar_containing_value_ref
@{ code evaluating to variable name } @{ code giving value ref }
Nat
Damian Conway writes:
* Using the pattern returned from some function as part of a regex
/pattern returned from ${\some_function} as part of a regex/
(??{ some_function() }) more generally
* Using an array of "words" as an alternate list as part of a regex
/match any of
Damian Conway writes:
$add = ^a + ^b;
# a thousand lines later...
$incr = $add-(1);
# a thousand lines later...
$x = $incr-($x);
I picture $add-(1) cloning add's optree, filling in the 1 where
appropriate, then returning a reference to the new (cloned) optree.
Steve Fink writes:
And both those examples apply to the underpinnings. Ok, maybe I have an
unusually broad definition of the word "underpinnings". Think "anything
that can't be done with a pure perl module".
I'm not wild about that metric, either. Exporter is pure Perl, but
I'd love to see
Stephen P. Potter writes:
* The match operator, Cm, is always required (bare C// becomes a fatal
error).
I could live with that. Damian's done some work trying to tokenize
Perl and knows what the weird edge cases are. Damian, can you post
your short list?
* Replace Cm//, Ctr///, and
Chaim Frenkel writes:
The other magic variables would simply end up as some funny 8-bit
characters floating around. With one's handy (several thousand page)
translation table one can then interpret the meaning.
That's insane. We're trying to get rid of special variables named
after obscure
Nathan Wiger writes:
Well, this argument makes more sense. However, I still have to disagree.
In fact, I think the opposite: ALL subs *should* be lvaluable by
default. Here's why.
I think I failed to explain Damian's use of the word 'dangerous'.
my $var;
sub routine {
$var;
}
John Porter writes:
foo $= ( bar, quux ); # provide scalar context to both sides
foo @= ( bar, quux ); # provide list context to both sides
This is very harmonious with the provision of two sets of operators
for numeric and string comparisons.
I assume you've dropped this
Piers Cawley writes:
The $a and $b of the sort comparator were A Bad Idea to begin with.
Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1] can't
be used, or even a more standard $1 and $2. Either one makes it more
obvious what's being operated on.
$1 $2 could be
Peter Scott writes:
You're right. If RFC 45 is implemented they would however be inconsistent.
No, || is half-consistent at the moment: the left hand side is forced into
scalar context but the result context propagates down the right hand
side. I challenge anyone to come up with a
Nathan Wiger writes:
Nonetheless, I think a better thing would be to figure out if it's
possible to "fix" this issue. I would *really* like lvalue subs ==
rvalue subs.
I think conflating:
foo(@vals)
and
foo() = @vals
is misleading and going to cause more confusion that it solves.
I
Perl6 RFC Librarian writes:
It is proposed that in a list context, operators are applied
component-wise to their arguments. Furthermore, it is proposed that
this behaviour be extended to functions that do not provide a specific
list context.
I don't mind making Perl's builtins do this.
Dan Sugalski writes:
Unfortunately, I think you're somewhat under-informed as to the inherent
capabilities of people's brains.
Ok, at this point I think all parties have to step away and let the
RFCs fall where they will.
It's obvious that there are two types of people: those who don't mind
Chaim Frenkel writes:
CN Can we please cut down on the traffic to perl-announce, maybe make it
CN moderated? Thanks,
Perhaps, the esteemed Librarian could make the -announce a Bcc?
One of the moderators was a little too approval-happy. I believe
this has been fixed as of a few hours ago.
Karl Glazebrook writes:
Well said!
My take: I like perl, I don't mind it the way it is. But I'd be happier if
it was a lot more like python! (indentation aside)
This begs the question of why you're not using python. If it's just
indentation, that's silly. Surely there are patches to the
Jeremy Howard writes:
@result = @a || @b;
Which applies '||' component-wise to elements of @a and @b, placing the
result in @result.
*Ptui* That's not how *I* want || to behave on lists/arrays.
I want
@result = @a || @b;
to be like:
(@result = @a) or (@result = @b);
That's what
(-internals removed from the CC list)
[EMAIL PROTECTED] writes:
All calendar systems are arbitrary.
Yup. So let's use Larry's birthdate-and-time as the epoch marker.
Seriously, stick with 1970 (if we need an arbitrary marker, no reason
it can't be a familiar one) and extend date/time values
Perl6 RFC Librarian writes:
=head1 TITLE
Less line noise - let's get rid of @%
I have some problems with this RFC:
* you misunderstand the purpose of $ and @, which is to indicate
singular vs plural. You say a $ indicates a string or number,
but really it indicates a single thing.
John Porter writes:
I think as long as equivalent (and better!) functionality is available,
through equivalently terse syntax, who's to care? Why is
$h{'foo'} = 'bar';
instrinsically preferable to
assoc( %h, 'foo', 'bar' );
I'm horrified you have to ask this question.
Peter Scott wrote:
I have often wished that digraphs were not bundled with variables in this
respect, i.e., I wanted to put a string containing \n inside single quotes
just 'cuz it didn't contain variables to be interpolated. Whether there's
a way of improving this behavior or not I don't
Nathan Wiger writes:
So the proposal is: make the dangerous one the default.
I don't think that's a good idea.
You're going to have to explain to me how these differ in their
dangerousness:
Nathan, you misunderstand Damian. What's dangerous is making every
subroutine lvaluable. He's
NOTICE: reply-to set to the -language-datetime list.
Ted Ashton writes:
Well then, why 1970? If we're defining our own, why buy into one
which is scheduled to blow up in 2038? Why not at the very least
start with Jan 1, 2K?
This works, provided epoch seconds are stored in some form of big
(Reply-to set to -datetime list)
Chaim Frenkel writes:
NT Epoch seconds are a convenient representation for dates and times.
NT Varying epochs make it an unreliable representation when data are
NT shared. A consistent epoch would fix this.
Sorry, I don't buy that. Not every program will
1 - 100 of 120 matches
Mail list logo
