Allison Randal is the new Project Manager
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. I'm so impressed with how she's been doing that I'm officially stepping down and handing the reins to her. Best of luck to all! Nat
dLoo releases peer-to-peer programming language
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 developers add to the language it scales in richness and functionality. Programs run in a software browser called BlueBox which dynamically downloads and assembles the parts of the language as needed. For more information and access to the source visit http://www.dloo.org. BlueBox is a community driven project released under the GPL. http://www.dloo.org/
Re: Per-object inheritance in core a red herring?
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. Wouldn't you do it by swapping out the dispatch entry in the vtable? Nat
X/Lang
Anyone seen this? It has a little of the flavour of what we're going to do. http://xlang.sourceforge.net/ Nat
Re: Damian Conway's Exegesis 2
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 show($root, $post), then the value of $x (and $x eq Post order: \n). You're exactly right. I was mislead. So how come `print' gets to mung about with evaluation order? It doesn't. I need to put down the crack bowl and get back to work :-) Thanks for pointing that out. Nat
Re: Damian Conway's Exegesis 2
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 Perlisms...you can have exactly as much freedom as you want, if you carry the responsibility for it. Alternatively, you can have Perl do more of the work for you, if you are willing to live with constraints. Elegant. Perlish. Good. Yes, it's important for everyone to understand that types are OPTIONAL. You use them when you want compile-time type checking or storage efficiency or you need them for something you're doing with an underlying VM, but you can always write untyped code. Nat
Re: Damian Conway's Exegesis 2
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 it? Yes, except that you're relying on show() not returning a value there. If show() was written so that it happened to have a print statement as the last thing in the sub, then you'd get random 1s in your output. That's a style difference, though, not a language capabilities issue. Nat
Re: Damian Conway's Exegesis 2
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 a property :) Personally, I'd rather not deal with a toke.c that knows more of /usr/dict/words than I do. Hmm, plug in WordNet and you've got a *real* DWIM parser! Nat
Re: apo 2
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! # ! as assertion $elvis has left(the building); Nat
Re: Tying Overloading
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 + in that crocky this could be a block or an expression sense. I'd prefer a word operator: $x = numeric @tmp; Of course, beginners might think it was like defined(): if (numeric $x) # is $x a number We know the return value of that meaning of numeric() would always be true. Everything in Perl can be a number if you want it to be. :-) Then they'd want: $x = string @tmp; and we'd have to tell them that string is spelled . Then we could go off on Abbott and Costello crosstalk: 'there isn't one?' 'there is, and it's spelled ' 'you did it again!' 'did what again?' 'left the operator out' 'it is right there!' etc. I feel like I'm in one of those sitcom situations where nervous over-thoughtful boy and girl meet, and one says something like you shouldn't sit beside me. The other asks why, to be told we'd hold hands, and there'd be kissing, more holding, more kissing, and we'd date for a while, get married as we start college, I'd get pregnant, drop out to take care of the baby, you'd have to work three jobs to feed us all, your studies would be left behind, I'd grow increasingly frustrated with the endless pregnancies, turn to drink, spend the glorious years of our lives in a drunken haze, beat our children, beat you, go to jail, come out divorced and with an abused kidney that would require hospitalization for my slow death. Ken, I don't like hospital food! Nat
Re: Larry's Apocalypse 1
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 philosophical camp before pragmatically evaluating the benefits of something seems a waste of everyone's time. Nat
Re: Larry's Apocalypse 1
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 example of Something I Do Not Wish To Break. Nat
Larry's Apocalypse 1
Not a comment at all on it? Was I accidentally unsubscribed to perl6-language? *tap* *tap* is this thing on? Nat
Re: Larry's Apocalypse 1
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 have no vested interest in giving Larry a bunch of consistent interesting suggestions. :-) Nat
[Fwd: http://dev.perl.org/rfc/73.html]
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 a C
struct such a struct tm into an actual hash value. On the
other hand, it's rather efficient to translate a struct tm
to a struct tm, since it's a no-op.
We can make such a struct look like a Perl object, and access it
efficiently with attribute methods as if it were a ``real''
object. And the typology will (hopefully) mostly only impose an
abstract overhead.
Neil Watkiss [EMAIL PROTECTED] and Brian Ingerson [EMAIL PROTECTED] have been roughing out ideas for a Inline::Struct module which sounds similar if not related to the this. It's primary objective is simpilfying passing structured data between Perl and C/C++. It also makes a struct look like a Perl object. There is an unreleased module implementing a C++ interface which works quite well. A C version is planned as well. Others may follow. Right now, it works like this:
use Inline CPP = 'END', STRUCTS = ['Foo'];
struct Foo {
int inum;
double dnum;
char *str;
};
typedef struct Foo Foo;
END
my $o = new Inline::Struct::Foo;
$o-inum(10);
$o-dnum(3.1415);
$o-str('Wazzup?');
my %fields = %{$o-_HASH};
my @keys = @{$o-_KEYS};
my @fields = @{$o-_ARRAY};
package Inline::Struct::Foo;
sub Print {
my $o = shift;
print Foo {\n, (join \n, map { $o-$_() } $o-_KEYS), }\n;
}
__END__
Anything that is typemap'd can be used. I'm hoping Inline::Struct will evolve into the compiled complement to Class::Struct. If Perl 6 could do this without requiring a compiler on hand, it would be the perfect replacement/evolution of Class::Struct.
Garrett
Re: Larry's Apocalypse 1
Glenn Linderman wrote: New RFC ideas? Please, dear God, no. :-) Nat
Apocalypse 1 from Larry
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, looking through them to deeper issues. He hopes to emit Apocalypses more-or-less weekly, although some chapters have fewer RFCs and issues than others. Enjoy! Nat - Apocalypse 1: The Ugly, the Bad, and the Good by Larry Wall Apr. 2, 2001 Table of Contents o RFC 141: This Is The Last Major Revision o RFC 28: Perl should stay Perl o RFC 16: Keep default Perl free of constraints such as warnings and strict o RFC 73: All Perl core functions should return objects o RFC 26: Named operators versus functions People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.) What I will be revealing in these columns will be the design of Perl 6. Or more accurately, the beginnings of that design, since the design process will certainly continue after I've had my initial say in the matter. I'm not omniscient, rumors to the contrary notwithstanding. This job of playing God is a little too big for me. Nevertheless, someone has to do it, so I'll try my best to fake it. And I'll expect all of you to help me out with the process of creating history. We all have to do our bit with free will. "If you look at the history of Perl 6 up to this point, you will see why this column is subtitled The Ugly, the Bad, and the Good. The RFC process of last year was ugly, in a good sense. It was a brainstorming process, and that means it was deliberately ugly-not in the sense of incivility, since the RFC process was in fact surprisingly civil, but in the sense that there was little coherent design to the suggestions in the RFCs. Frankly, the RFCs are all over the map, without actually covering the map. There are contradictory RFCs, and there are missing RFCs. Many of the RFCs propose real problems but go off at funny angles in trying to propose solutions. Many of them patch symptoms without curing the underlying ailments. I also discovered Larry's First Law of Language Redesign: Everyone wants the colon. That was the Ugly part. The Bad part was that I was supposed to take these RFCs and produce a coherent design in two weeks. I starting out thinking I could just classify the RFCs into the good, bad, and ugly categories, but somehow most of them ended up in the ugly category, because the good ones typically had something wrong with them, and the even the bad ones typically indicated a problem that could use some thought, even if the solution was totally bogus. It is now five months later, and I've been mulling over coherence the whole time, for some definition of mulling. Many of you know what happens when the size of your Perl process exceeds the size of your physical memory-you start thrashing. Well, that's basically what happened to me. I couldn't get enough of the problem into my head at once to make good progress, and I'm not actually very good at subdividing problems. My forte is synthesis, not analysis. It didn't help that I had a number of distractions in my life, some of them self-inflicted, and some of them not. I won't go into all that. Save it for my unauthorized autobiography. But now we come to the Good part. (I hope.) After thinking lots and lots about many of the individual RFCs, and not knowing how to start thinking about them as a whole, it occurred to me (finally!) that the proper order to think about things was, more or less, the order of the chapters in the Camel Book. That is, the Camel Book's order is designed to minimize forward references in the explanation of Perl, so considering Perl 6 in roughly the same order will tend to reduce the number of things that I have to decide before I've decided them. So I've merrily classified all the RFCs by chapter number, and they look much more manageable now. (I also restructured my email so that I can look at a slice of all the messages that ever talked about a particular RFC, regardless of which mailing list the message was on. That's also a big help.) I intend to produce one Apocalypse for each Chapter, so Apocalypse 1 corresponds to Chapter 1: An Overview of Perl. (Of course, in the book, the Overview is more like a small tutorial, not really a complete
Re: HELP: Trying to locate information about Perl 6 Language
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
Re: JWZ on s/Java/Perl/
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 trivial, Configure wouldn't need to exist--we could just use hints files. Lots of hints files. One for each configuration, in fact. Hey Jarkko, I have an idea ... :-) Nat
Re: We should have some YAPC talks on Perl 6
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 more specifics from Larry, and Dan helps us all work out the internals some more, there's not much to write about. Any mailing lists we need for documentation can definitely be hosted at perl.org. But we need something to document first :-) Nat
We should have some YAPC talks on Perl 6
--- 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 YAPC 2001 the Third North American Yet Another Perl Conference http://yapc.org/America/ McGill University, Montreal, Quebec Wednesday through Friday June 13-15, 2001 YAPC is a place for people to meet and talk about Perl -- where people who've done interesting things, people who are working on the language itself, people who are using it daily, and people who are looking to learn about it are all within arm's reach. Some of the great authors and coders in the field will be on hand to discuss their work, as well as the nature and direction of Perl itself. Please join us for three days of listening and talking about Perl in Montreal. * Conference registration will be available by Feb. 1, 2001 at http://na-register.yapc.org/ * Dorm rooms will be available at the University (rates TBA); the dorm request information will be on the website and registration form. Registration Cost: CAD$125 (about USD$85) * We are looking for sponsors. Please contact Kevin Lenzo ([EMAIL PROTECTED]) for information about how you can help support the Yet Another society and YAPC. Much of the necessary funding for YAPC comes from the generous donations of our sponsors. * Submitted papers: Submission Deadline: May 1, 2001 All topics are welcome. Here is a short list of subjects that might be presented: XML, CGI/Web, Interprocess Communication, GUIs (GTk, Tk), Natural Language Processing, Interactive Perl, Agents, Perl as Glue, Object-Oriented Perl, Scientific Applications, Guts, Internals, JAPHs, Perl Poetry, System Administration, DBI/DBD, Non-UNIX Perl, Security, Peer-to-Peer Communication, Your Favourite Topic. Please submit your abstracts to [EMAIL PROTECTED]. Authors are requested to limit their abstracts to one or two paragraphs for Lightning Talks, and to 300 words for other talks. This year we will accept a number of types of talks: * Lightning: 5 minutes The lightning talks were instigated by Mark-Jason Dominus last year in Pittsburgh, and were replicated with great success at the European YAPC in London. Participants speak for no more than five minutes, with the use of conventional transparencies. Any use of data projector, etc, is discouraged, but allowed as long as the five minute time limit is maintained (set-up will be done as the clock ticks). The talk ends at the five-minute mark, regardless of whether or not the speaker has finished. Any topic is allowed, and some have been fantastically humourous. Lightning talks are an excellent forum for first-time speakers. * Standard: 20 minutes A 'standard' talk is the preferred format. This is enough time to start a topic, introduce it with some pithy slides, and open up to later conversation. * Long and Extra-Long: 45 minutes, 90 minutes Long talks are reserved for experienced speakers covering large topics. If you have an in-depth topic you would like to present in some detail, perhaps with considerable discussion, a Long or Extra-Long talk may be the format of choice. * Tutorial: 3 hours + break (possibly in two sets) Half-day (or possibly full-day) tutorials. Please submit your abstracts to [EMAIL PROTECTED]! -- Yet Another Society is a non-profit organization for the advancement of collaborative efforts in computer and information sciences. YAS promotes symposia, teaching, and group projects. See http://yetanother.org for more information. -- Troisime YAPC Amrique du Nord: premier appel la participation Yet Another Society vous invite participer YAPC 2001 La troisime Yet Another Perl Conference en Amrique du Nord http://yapc.org/America/ Universit McGill, Montral, Qubec Du mercredi au vendredi 13 au 15 juin, 2001 YAPC est un endroit o se rencontrer et parler de Perl; o sont runis des gens qui ont fait des choses intressantes, qui travaillent sur le langage lui-mme, qui utilisent ce langage tous les jours et qui veulent en apprendre plus. Quelques uns des meilleurs auteurs et codeurs dans le domaine seront prsents pour discuter de leur travail, ainsi que de la nature et de l'avenir du langage Perl lui-mme. Joignez-vous donc nous Montral
Re: [Fwd: Re: [FWP] sorting text in human-order]
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
Larry update
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 topic, decide, and let us know. That way he can release his verdicts bit-by-bit (regexps, objects, etc.) He's also thinking about the way to spec perl6. Take perl5's documentation and modify? Take the Camel and modify? It was good to talk to him again. I had been afraid that he'd given up and begun learning Python :-) Nat
Also, rest of Larry's talk transcribed
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 perl.{com,org}.
Thanks,
Nat
As I look around here, I see a lot of young faces. Almost too young.
I like youth. I always planned to stay young all my life. I've always
been blessed with a face that's younger than my age, so I've tried to
always adopt a young attitude to go with my face.
You can fool some of the people all of the time, but you can't fool
Mom. I think she knows that I'm just a late bloomer (speaking of
procrastination). I'm late for a lot of things, not just blooming.
For instance, I only started writing this talk yesterday. Another one
of these Just In Time talks. I'll probably finish it sometime
tomorrow. Lateness is one of my specialties. Someday I'll be dead,
and when you refer to me as "the Late Larry Wall", people will think
you were joking.
Speaking of my long-lost youth, I remember sometime way back during
the Kennedy administraion, my grade school teacher asked us all to
calculate how old we'd be in the year 2000. I got the unfathomable
answer of 46. I could imagine being 10, maybe. But 46 is a lot closer
to infinity!
Anyway, I couldn't imagine being 46. Now I can. As of last month, I'm
officially in my late 40s. Whoopee! Does this mean I can schedule my
mid-life crisis soon?
Besides my birthday, I recently noticed several things that tell me
I'm not so young any more. The first thing I noticed is that I took
my first child, Heidi, off to college. Believe me, even if you don't
notice your kids while you still have them, you'll definitely notice
them when they go away.
The second thing I noticed is ... I forget what.
The third thing I noticed is that I want to start reminiscing about my
youth. Old people really only have three things to say: how good it
was back then, how bad it is now, and (if you're lucky) how much worse
it will be in the future.
So, I'd like to talk about how good it was back then, how bad it is
now, and how much worse it will be in the future.
Actually, I just said that to be funny. I really do think things are
getting better, and the getting betterness is what I would like to
talk about.
The name of this talk (for the moment, I might change it) is: Camel Lot
#6, The Once and Future Perl.
I going to do a little bit like Ken did last night, and take you
through how bad it used to be and how good it's getting, and on to the
future. A chronological outline is a great way to go. Some of you
may recognise some of these slides. In fact, these are probably about
10 years old, some of them. I put them in more for historical value.
If you look closely, you can see gritchineses--that's an overhead
transparency that I scanned. So this is the real original.
[How It Was Back Then (Sort Of)]
Way back in the dawn of time, this is what Unix looked like. Either you
programmed in C, or you programmed in shell. Of course, those were
two different realms, and it was sort of one or the other. We had
this dichotomy of our thinking, that you had to do one or the other.
[How It Really Was Back Then]
How it really was back then--one day it opened up to me, these were
not opposites, but think of an oyster shell opening up here. Instead
of opposites, they were two different dimensions in space that you
could graph things like this. You could consider sed and awk to be
sort of warts on the shell.
For those of you at the back who can't read this, the left hand axis
(what C is good at) is called "manipulexity" and the horizontal
attitude is called "whipuptitude".
With that realization I realized that there was a big gray area out
there. In biological terms, that's an ecological niche. So I decided
to fill it.
[The Hatching of an Idea]
Perl got hatched, and that's kinda why it's egg-shaped there. From
the beginning it was designed to grow into that space. Perl was
always designed to be an evolving language.
The reason I'm telling you some of this stuff is that, as some of you
know, we've announced Perl 6, and I'm going to be talking about that
later. And one of the very very high level goals of Perl 6 is to keep
Perl capable of evolving. Perl 5 was running into some limits and
we're going to figure out how to get around those limits.
So it appears that there are these two axes of C and shell. And there
could be other dimensions: the Python dimension, the Java dimenson.
But you don't want to think of either/or. It's really easy for people
(especially computer scientists) to get locked into this either-or
thing. Either I use the GPL or I don't. Well, why not use the GPL
*and* some other license? Is that right, Ken? [Ken Coar had been
lamenting the difficulties of the GPL the night before, but didn't
mention dual licensing.] It wasn't
Larry's ALS talk summary
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 through a link at http://dev.perl.org/, along with the full text and a link to mp3s. Nat * He's dividing Perl community's suggestions (the RFCs) into Good, Bad, and Ugly. Ranking each according to the importance of the problem being solved, and the quality of the solution. Some RFCs have identified important problems, but their proposed solutions will need to be replaced with more Perlish forms. * Perl's parser and lexer will be written in Perl, using Perl regular expressions. That's us eating our own dogfood, or whatever the phrase is. * The language will be dynamically extensible, using modules written in Perl. So you can program in a language that looks like Python, Latin, or Java, if you want. In this sense, the Perl compiler and runtime system become a meta-language (extra-lingual?) system that lets you code in your own favourite little (or large) language. Perl would just be one of the languages you could implement. * The flip-side of this is little languages: make it easy for folks to have their own domain-specific "little" language. Make Perl a environment for building domain-specific languages. * The Perl compiler and interpreter systems will be designed so that they can emit C, Java, and C# code. This doesn't mean that perl6 will ship with all three back-ends, but they will be easy to implement. * "Non-critical built-ins", for example sockets and operating system calls, will no longer be operations in the core of Perl. They'll be in dynamically loaded, possibly automatically loaded, modules. * Variables will be treatable as objects. Under the hood we'll use a vtable system, a little like that of C++ but dynamically changable. * Special global variables will be replaced with more appropriate and lexically-scoped alternatives. Some of them will be attached to filehandle objects instead. * Typeglobs will go away. * XS, the system for extending Perl with C or C++, will be replaced with something much easier to use. This will give people very convenient access to existing code libraries, and write C or C++ subroutines that can be called as Perl subroutines from Perl code to take advantage of C's speed and memory flexibility. * Perl will permit function and method signatures (prototypes) to enable certain compile-time optimizations and checks. These will not be mandatory, but if someone wants compile-time type checking then they can have it. * Completely object-oriented exception handling, with a simple string-like interface for those who do not want the power of the full OO system. * True and false in Perl are used to mean "interesting" and "uninteresting". Overloadable logic operators are a possibility, to let you decide what is interesting and uninteresting in your world. * Perl will support many types of low-level programming, letting you specify types for variables, homogeneous arrays, compact arrays, and more. * Perl will also support many types of high-level programming, adding more support for functional programming (the reduce operator), logic programming (???), and the little languages. * There won't be default-loaded site configuration files. Implicitly loaded code is a recipe for un-portable un-debuggable confusion. * Add the ability to declare lexically-scoped Unicode operators for mathematicians. If they want to apply the rho function to sigma, then they can. If they want to map the Arabic letter Farsi "yeh" to the scalar Thai character "tho nangmontho" then they can do that too.
Re: TIL redux (was Re: What will the Perl6 code name be?)
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 enough to move the speed from "too slow" to "acceptable", and all they did was deobjectify the design. Nat
Re: renaming local to fornow (or maybe just now)
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. Otherwise we're just going to get caught in a cycle of pointless revisitation, which Larry will either read (taking time away from reading the real RFCs) or ignore (in which case it's been pointless). Thanks, Nat
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
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
Re: Cya dudes
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
Re: RFC 237 (v1) hashes should interpolate in double-quoted strings
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 %{ is seen?
Too inconsistent. People often write dollar amounts, but we don't
only enable scalar interpolation for ${varname}.
Nat
Re: RFC 246 (v1) - RFC 250 pack/unpack enhancements
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
Re: pack/unpack is damn unperlish. Explain them as Perl.
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 documentation and education discussion off the language list. We get enough traffic already without this. Nat
Re: RFC 213 (v1) rindex and index should return undef on failure
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
Re: RFC 195 (v2) Retire chop().
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()). Dammit, I forgot to fix this. My bad. Thanks for reminding me. Nat
Re: RFC 232 (v1) Replace AUTOLOAD by a more flexible mechanism
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 beautiful mind, Mr Zakharevich. I'd like to frame it on my
wall.
Actually, I think I'd like to see this extended. I'd like to be able
to hook into the parser so that when it sees a function call:
foo()
I can have it call my subroutine.
foo_handler( $token_stream )
foo_handler can access the token stream that may or may not be part of
the argument list, decide what is, and then return the code to be
executed at runtime (normally just a call to foo()):
sub foo_handler {
return sub { foo() }; # *not* an infinite loop, please
}
The anonymous subroutine returned by the foo_handler() is then inlined
into the optree.
This would let us have constants:
sub foo_handler {
return sub { 42 };
}
Context-coercion:
sub foo_handler {
my $token_stream = shift;
my $arg_1 = $token_stream-next;# assuming passed as strings?
return eval "sub { scalar($arg_1) }";
}
This would give us the ability to have things with both compile-time
and run-time behaviours, as well as being able to remove run-time
behaviours if we wanted.
Perhaps this is no longer the point at which we think of it as
autoloading, but rather as part of the compilation process. Just as
we can intercept strings and regexes with overloaded strings and
regexes, this would let us intercept functions.
Nat
Re: RFC 226 (v1) Selective interpolation in single quotish context.
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
Re: RFC 213 (v1) rindex and index should return undef on failure
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. Nat
Re: RFC 218 (v1) Cmy Dog $spot is just an assertion
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, given this RFC it's possible to add other RFCs that deal with specific dependent language proposals and optimizations. Ok, I'll work on the RFC for the type-checking. Nat
Re: RFC 226 (v1) Selective interpolation in single quotish context.
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 $baz $quux'; The MagicInterpolativeStrings module has overridden q() for the scope in which it's 'use'd, and the override subroutine is called with: '$bar $baz $quux' and can return '\$bar $baz \$quux' which is then interpreted as a qq() string and used as the value assigned to $foo. IMHO the overloaded strings thing in 5.6 could be tweaked to be more useful. Nat
Re: RFC 218 (v1) Cmy Dog $spot is just an assertion
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 starting to
think I can write any old crap and you'll make sense of it :-)
Alternatively, one might imagine an attribute C:must that tells a variable
that anything assigned to it must provide certain methods:
my $foo : must(feed water play poop);
$foo = Manager-new(); # die "Manager object can't play".
An interface then becomes an alias for a particular Cmust:
use attr_alias Pet = qw(feed water play poop);
my $foo : must(Pet)
Not sure which I like better. :-)
The other style (Pet via pragmata or "implements") is like C++, only
your "virtual base class" isn't part of the inheritance hierarchy.
This :must attribute isn't something I've seen in any other language,
so I don't know what it's drawbacks might be.
Ah. "implements" makes the class designer do the work of listing
methods by designing interfaces. :must makes the user of a class do
the work. But the most common cases of OO in Perl don't use
polymorphism, so making the user do the work would be making something
hard which ought to be easy.
However, :must gives the user of a module flexibility, because only
you the user really knows what wacky polymorphic way you're combining
classes that the creators never envisioned ("it's a dog, it can
fetch(). it's an FTP client, it can fetch()!").
Is there some way to get the best of both worlds? Instead of :want,
let the user define custom interfaces?
package Dog implements Pet;
package NetSnarfer implements FTP;
# in main program
use Custom::Interface Fetcher = qw(fetch);
my Fetcher $x;
my Dog $spot;
my NetSnarfer $z;
$x = $z; # ok because $z can fetch
$x = $spot; # ok because $spot can fetch
$x-fetch(); # ok
$x-bark(); # not ok because Fetcher doesn't list bark()
Nat
Re: RFC 212 (v1) Make length(@array) work
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
Re: RFC 212 (v1) Make length(@array) work
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 feature.
Nat
Re: RFC 212 (v1) Make length(@array) work
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 point out things that have unexpected
consequences ("you seemed to think that value was defined, but it
wasn't", "that parenthesis after the function name is interpreted as
starting the argument list, but you put whitespace between the
function name and the parenthesis--you're not thinking the parentheses
are giving you a term in a larger expression, are you?"). They should
be things that you pay attention to because your program is probably
wrong.
Turning Perl into a nagging harpie means that the really important
warnings will be ignored.
This line of thinking brought to you by Mark-Jason's excellent talk
on data typing.
Nat
Re: RFC 215 (v1) More defaulting to C$_.
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 $_, then uses
FH;
to skip the next line, will have inadvertently trashed $_.
However, the perl526 translator can fix it by replcing void-context
FH with
{ local $_; FH; }
Nat
Re: RFC 213 (v1) rindex and index should return undef on failure
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 passing undef into the offset or start of substr have substr return an undef? Wouldn't you get a warning anyway, if you were treating undef like a number? Nat
Re: RFC 213 (v1) rindex and index should return undef on failure
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 position
of 'xyz'?
I guess I can't understand your idea of safe failure until I
see an example, and this doesn't seem to be it.
Nat
Re: RFC 166 (postHugo)
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
Re: RFC 196 (v1) More direct syntax for hashes
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 for reseting ?pattern? searches. Two weird
features crammed into one keyword. Shoving a third in doesn't seem
pleasent.
Either think up a better keyword, or remove those two crufty features.
I was expecting those two crufty features to be removed. If they
aren't, a third won't hurt.
This would be equivalent to:
foreach ($k,$v) (map { $_ = $hash{$_}
sort
keys %hash)
{ ... }
What you proposed and what you put in your example doesn't quite play
out. Csort keys %hash returns just the sorted keys of %hash, but
your foreach example implies that both keys and values would be
returned, sorted by key. Both would be useful.
That's what the map is for. (modulo syntax error in the map :-)
Nat
Re: RFC 196 (v1) More direct syntax for hashes
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 live with that. Just clear it up
in the RFC.
That's what I'm saying.
Nat
Re: The distinction between do BLOCK while COND and EXPR while COND should go
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Nat
Re: Proposal: chop() dropped
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
Re: Proposed RFC for matrix indexing and slicing
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
Proposal: chop() dropped
chomp() is best used for chop()s main raison d'etre, removing $/ from a string. I say we drop chop(). Nat
Idea: minor %hash changes
(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 does.
Resetting an each() should be done in some other way than calling
keys() or values(). Perhaps reset(%hash)? I'm subfond of the current
reset() semantics (symbol table crackheadery + single-match regexp
resetting).
I was against the idea of hash context, but I'd love it if:
foreach ($k,$v) (%hash) {
...
}
and
foreach ($k,$v) (sort %hash) {
...
}
magically "worked". Traversing hashes is so common, it'd be nice to
find a way around the keys() circumlocution. The former is already
suggested, and I like it. The latter requires the parser to
understand sort being passed a hash.
Nat
(just taught hashes in class, so I'm full of things that were hard to
justify)
Re: Proposal: chop() dropped
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 a problem.
I'm not sure I find either of those more legible. And they certainly
won't be faster. chop() has been around since perl1, too.
Yes, but chop()'s original purpose was what chomp() is now used for.
I doubt Larry would really have put in a function to remove the last
char in a string just to have a function that removes the last char in
a string. It was the chomp()-like itch I think he was trying to
scratch.
Then again, yes, people do tend to use it when they oughtn't. Hm...
Exactly.
Nat
Re: Idea: minor %hash changes
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. And a simple boolean (read: don't care) use shouldn't waste time looking for keys, really, but should be internally optimized to do the current reasonable thing. Which your suggestion would also boil down to, but for efficiency, this should be pre-boiled. Yes. I'll put that into the RFC. Nat
Re: Idea: minor %hash changes
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
while (($k,$v) = each %foo) {
... # begin again from the start
}
Nat
Python proposals
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
Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
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. The compatibility path for perl5 to perl6 is via a translator. It is not expected that perl6 will run perl5 programs unchanged. The complexity of the translator and the depth of the changes will be decided by the decisions Larry makes. Nat
Re: RFC 161 (v2) OO Integration/Migration Path
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 requires variables to be typed, and prevents assignments between incompatible types. A kind of compile-time type checking of the kind that C++ provides. I don't know how Larry's planning to do interfaces, but it's possible that we could even have pluggable type-checking systems: if C++'s inheritance polymorphism peeves you, use something else. I shudder to think of something that prevents simple variable accesses and instead requires verbose method calls. That doesn't seem to be making anything easy. Nat
Re: Some PDL issues (was Re: Test)
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, then ask for it. If full overloading on non-objects is what you need, then ask for it. If making objects look like non-objects is what you need, then ask for it. Heh, we're on the same page here. I'm just setting the framework for that discussion. I don't think the PDL folks yet know what they want, other than "better support for numerical structures". I'm trying to see what's wrong with the existing systems so that we can either fix them or replace them. Walking before we run, etc. Relax, I'm not trying to base the discussion around perl5's shortcomings. I just want to try and understand the problems and possible directions. Nat
Re: Some PDL issues (was Re: Test)
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
Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
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 programming language able to manipulate Perl programs is a common sense Good Thing. In particular, being able to manipulate the text of a Perl program means you can do analyses and preprocessing. If you say "oh, just use O:: and B::" then you force me to parse the program, suffering the injustices of the optimizer, before I can get my code back. Look at how B::Deparse struggles now. I don't want to struggle. Nat
Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
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
Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
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 chunks, I haven't kept track of whether: /3*5/ is part of $x/3*5 (in which case the tokens are /, 3, and /), or if (/3*5/) (in which case the tokens might well be /, 3*5, and /). Making sense of tokens is what a parser does. In theory. If we can break a couple of these nasty incestuosities between parser and tokenizer, we can make it possible to tokenize Perl without having to parse as well. Nat
Re: RFC 143 (v1) Case ignoring eq and cmp operators
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 trouble. Could you post some hypothetical code that would trigger the exception (including the loading of the module that defines the exception) so I can better see what you're proposing? If this was in last week's discussion, please send me a pointer to the archives. Thanks, Nat
Re: RFC 143 (v1) Case ignoring eq and cmp operators
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 comparison.
I'd say this argues for the parser to be told about new infix operators:
use operator
'eqi' = 'infix';
$blah eqi $bork
# rewritten as eqi($blah,$bork)
This raises another issue, though:
You'd obviously want to have a module that collected together your
favourite new operators. But if they were lexically scoped, they'd
be lexically scoped to the module they were defined in, i.e. your
collection rather than your main program. We're going to have to
think of a way to consistently say "do this in my caller's lexical
scope" without it becoming a nasty upvar hell.
Nat
Re: RFC 143 (v1) Case ignoring eq and cmp operators
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. I want to compare case-insensitively" is a specific problem and it's idiocy to go down the road of a special syntax for everyone's different specific problem. Nat
Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
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 idea that Perl should be the only thing that can tokenize, let alone parse, Perl. It's a great slogan, but a crappy reality. Anything that makes it possible for text editors to understand the syntax of the Perl code in a buffer, for pretty-printers to format Perl, code analysis tools to analyse Perl, etc. *without* requiring those editors, printers, analysers be written in Perl, is a GOOD THING. Read my lips: GOOD THING. I've nothing against dumping the parse tree, but it's not going to solve the problems of pretty printers, editors, code analysers. Nat
Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
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; # illegal %a = %b; # legal Be afraid. Be very afraid. Nat
Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-likewith or express
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 hand side is, I think:
$one-{two}{three}{four}
in a very complicated fashion. I'm unsure this is what you meant.
with %one\two {
push @\three\four, 5,6;
}
is clear and invulnerable.
Except that you often don't know the keys in advance, and so now
your code turns into:
with %one\$keytwo {
push @\$keythree\$keyfour, 5, 6;
}
which is decided sub-clear. The precedent of "if you're doing a hash
lookup, use {} around the key" is fairly well-ingrained in Perl.
Nat
Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-likewith or express
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
$fiename = "C:\$keythree\$keyfour"
Once again you show some code that doesn't work the way you seem to
think it does. You just made the string
'C:$keythree$keyfour'
I don't care how "ingrained" the concept of wrapping the
field names in curlies is, I still think it sucks, and so does anyone
who arrives here after using a language where there is a character (which
is conventionally dot) between the record name and a field in it.
I wrote a long response to this, but finally realized that my biggest
objection is that I think using a backslash sucks. You think curlies
suck. I think backslashes suck. You aren't proposing removing the
curlies from the rest of Perl, so what you're proposing is an
inconsistent-with-the-rest-of-Perl modification to the syntax to
suit your own tastes.
I'm all for learning from other languages, but it has to be consistent
with the rest of Perl.
I'd be more receptive to something that reuses existing or similar
Perl syntax (e.g., extend -).
So in my opinion, you haven't really come up with a strong argument
against:
$foo-{first}{second}{third}
I can't stop you RFCing it, but I definitely think you're heading down
the wrong path.
Nat
Re: functions that deal with hash should be more libera
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 of people wanting to coopt %{ or %( or %[ is truly frightening.
I think the message is: Don't put time into the parser when your
effort could better be spent in the optimizer.
Nat
Re: functions that deal with hash should be more libera
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 existing syntax. I have a document
coming on this to try and point people who want to give meaning to
every possible combination of punctuation and alphanumerics in the
right direction.
Perl is already very hairy and full of punctuational quirks. I think
we need a fairly compelling argument.
I have a list of stuff that looks a lot like a hash:
( foo = 1, bar = 2 )
Now, gol dern it, I want to treat it like a hash. I want *perl*
to let me treat it like a hash. Directly!
A hash is a specific data structure, currently encapsulated in the
innards as an HV. What you have is a list. You can assign that list
to a hash, in which case Perl builds an HV for you.
If not
keys ( foo = 1, bar = 2 )
then
keys %( foo = 1, bar = 2 )
I personally prefer:
('foo', 'bar')
or even
qw(foo bar)
for that.
Seriously, how many times do you want to call keys or values on
a list and then never do anything else with it? Very very rarely.
Most of the times you say:
foreach $foo (keys %bar) {
# do something with $foo and $bar
}
or at the very least you save away the list of keys and do something
with the corresponding values later on.
Yes, there are a few situations (e.g, where the presence of the key in
the hash is important not the actual value stored with the key) where
you might want the keys returned by a function but nothign else.
But those are mighty mighty rare.
In those mighty rare cases, I say you should have to deal with:
keys %{{ foo() }}
Nat
Re: Symbolic references, was Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 'refs'. That's the kind of thing that
the Exporter does.
Symbolic references are used for dynamic function generation:
foreach my $func (qw(red green blue)) {
*$func = sub { "FONT COLOR=$func@_/FONT" }
}
Also lazy function generation (similar thing but from within an
AUTOLOAD).
Class::Struct does it to mechanically create the subroutines for a
class.
Any object code that gets a class name (package) as an argument and
uses it to inspect variables in the package does it.
(off the top of my head)
Nat
Re: Things to remove
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; dump $fh }
sub resume { do $_[0] }
This is trickier than it first apperas, as the existing bytecode
shows. A Perl program is opcode + variables. Are you dumping symbol
tables? When recreated, will the variables have the same values they
currently do?
Just a pointer for the eventual RFCer to address.
Nat
Re: functions that deal with hash should be more liberal
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 for these functions). All functions recieve their arguments in a LIST via @_. The hash functions are prototyped as \%, meaning they are passed a reference to the hash named as an argument. The reference-taking: * permits them to change the data structures * is faster (one value, not all the key/value pairs) This isn't strictly needed for keys (if you don't mind it getting slower), but is needed for each() which maintains an iterator in the hash. There's also the fact that a list isn't a hash, the same way a list isn't an array. You are on a slippery slope that ends in: push( split(/,/), "foo" ); Because "push() just takes a list, right?" (hint: wrong). Nat
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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
Re: Extended Regexs
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 (${\join'|',@list}) here/
$" = "|"; /@list/ # snicker
Nat
Re: RFC 23 (v3) Higher order functions
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. What to do with private variables (and the possible stack of private variable bindings that goes with recursion) is something I can't see my way through. When there are no more language objections to this, I say we throw it over to the -internals group to pick at. It is quite a meaty bone. Nat (thinking in perl5 internals terms. bad me.)
Re: RFCs (Re: Ideas that need RFCs?)
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 its functionality moved into the core (or, indeed, replaced by a general compile-time interface setup with separate runtime execution semantics) for speed reasons. My message was *encouraging* RFCs And once again we're in violent agreement :-) Sorry for any confusion, Nat
Re: Ideas that need RFCs?
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 Cs/// with equivalent regularized functions that take mulitple arguments instead of using specialized syntax. It would be best if the names could be more "complete", like match(), translate(), and substitute() (although translate and substitute are rather long). I think you'll lose that battle. Perl's tight RE integration is a plus, not a minus. There are already long names for matching and substitution if you use the Regexp module. * Disallow use of C/ as delimiters for quote functions and require use of matching pair characters. Not sure what this would win. It's not really a parsing problem. * Remove special meaning from C/. Integrate that functionality with C' and C". Which special meaning? Division? :) This comes under the m-always-mandatory category. Nat
Re: RFC 82 (listops in list context)
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 control characters. At worst, we could run the script through (the horror) a unicode - trigraph/quadgraph/multi-graph translator to be able to read it. And then put it back that way. That's not making something easy, that's making it hard. Basically, we make them available for the fellows that need the symbols. Perl source code can already be Unicode. But the keywords and variables must remain ASCII if those of us with only 7-bits are to be able to use it. Please give up the idea. Nat
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
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;
}
This, by virtue of rvalue subs being default, keeps the lexical $var
private. Damian's big on privacy.
Your change would make privacy violation *automatic*.
That's dangerous.
Might look weird at first, but it's not. It's just like any other
assignment. This surely doesn't look weird:
@array = ($r-{func}) = split /:/, PASSWD;
And it works just fine in default Perl 5 with no special keywords.
No it doesn't. $r-{func} holds a scalar. split will return the
number of fields, not the data. This is irrelevant to your thesis,
though.
lvalue subs are worth a lot more than just simple data accessor
functions. I don't see why we should force-relegate them to a background
role by requiring an :lvalue constraint that most people won't
understand how to use correctly.
Now you're into rhetoric.
(1) It's not a background role.
(2) Changing variables in the subroutine's scope is a BIG THING, and
ought to be explicitly enabled, rather than explicitly disabled.
(3) :lvalue is hardly rocket science. You drastically overstate its
complexity.
Nat
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 idea as well, given the argument that you would be dropping prefix symbols but creating a lot of new operators to do the same task? Nat
Re: RFC 76 (v1) Builtin: reduce
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 somewhat dangerous in a sub that might have regexen in it... $1 and $2 are a poor choice because of regexps. $a and $b were done for speed: quicker to set up those global variables than to pass values through the stack. The documentation for perl5's sort function says that passing as arguments is considerably slower. I don't think you can handwave and say "oh, that's an implementation detail". I think it's an implementation detail that's bloody hard to fix, especially for things like code references passed to sort: sort $some_ref @unordered Perl can't do anything at compile-time to tell sort where lexicals in the sort sub are. So I don't have a solution, I just have more detail on the problem. Nat
Re: RFC 82 (listops in list context)
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 rationalization for this that does not invoke implementation expediency. As Damien observed, it's by the very definition of a compound assignment: X OP= Y is defined to be X = X OP Y So the only thing tested for truth with ||= is the LHS. Nothing to do with implementation. Nat (PS, loved the obscenity analogy :-)
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
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 strongly disagree with this. You know how many people have problems with my? Lots. What kinds of problems can you possibly have with my()? The concept isn't that hard ":lvalue makes it so you can assign to subs". But the hard part is deciding *where* it should be used. I think it puts an unfair burden on a CPAN author to try and forsee all the possible uses of a sub. My turn to strongly disagree. Module programmers must decide on an interface to that module. Programmers wanting to use the module must read its documentation to see what that interface is. There might be thousands of possible interfaces, and module authors are *NOT* under any obligation to implement them all. Lvalue subs do not change this. If the author doesn't forsee this, then I have to ask them to patch it. No, you work with what you have. Modules, like Perl, don't have to be all things to all people. This idea that it "ought to work" is what's broken. Here's what I want: * Andy's RFC on lvalue subs getting the rvalue as arguments reworked to account for the possibility of multiple rvalues. * A separate RFC saying what I want. I'll write the separate RFC now. Then we can shut up and let Larry sort it out. Nat
Re: RFC 82 (v2) Apply operators component-wise in a list context
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. Making my own functions do it gives me the willies. You'd require subroutine authors to label their subroutines as capable of having this rule applied. Subroutine users are still going to have to read the docs to work out how to use the subroutine. You're not really making anything automatic, just trading one set of typing for a different set. Context is weird enough without trying to add more magic to it. Stick with "make Perl's builtin operators apply themselves to list elements when in list context". Nat
Re: RFC 84 (v1) Replace = (stringifying comma) with =
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 the punctuation, and those who do. We already know what Perl is like with punctuation. Let the anti-punctuation folks make their RFCs, and let Larry decide. I think they're wasting their time, but it's not about what I think. And somewhere within those python-esque convolutions, there may be some ideas that Larry will adopt. Nat
Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument
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. Nat
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 Python
parser to permit curlies. If there aren't, surely it's on the table
for python3000.
I guess the question arises - how radical is perl6 allowed to be?
Only Larry can say how different from perl5 perl6 will be, and he can
only say that after he's seen how radical it *might* be. My personal
suspicion is that it won't be so different from perl5 that it feels
like a different language.
What makes Perl feel like Perl is, of course, subjective, but to me
the punctuation is a lot of it. We're trying to improve Perl, not
replace it. At some point you run into the grandfather's axe syndrome
("I have my grandfather's axe. My father replaced the blade, and I
replaced the shaft").
Larry will probably also have to consider ease of adoption: if current
Perl programmers can't migrate a lot of what they know, they'll be
starting from scratch. That's hardly embodying Laziness. Perl's got
a long history of stealing from other languages. Are you sure you
aren't trying to create another language and steal from Perl? Because
if you are, Python already did that :-)
It occurrs to me that for some kinds of RFCs, it's very important to
put the WHY into your RFCs, not just the how. Your suggested
implementation might be rejected, but Larry might be able to find
another way to permit what you want.
Nat
Re: RFC 104 (v1) Backtracking
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 all my students keep expecting it to mean. Nat
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
(-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 to be BigSoddingInts. That'll mean we're not screwed by the +/- 69.summat year problem that will hit the rest of civilization in 2038, and we can do useful calculations like "number of days since Queen Victoria ascended to the throne" without wrapping around in our int space. Nat (BigInts are not an internals headache, so I'm not bothering the internals list, which is right now debating the difference between arrays and matrices)
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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. Similarly @ isn't just a variable marker, it's used to indicate that you get multiple things: @foo[2..10] @$foo * current typing provides rudimentary compile-type checking. Saying: $foo = (1,3,5); gives a warning. Saying: %foo = "Nat"; gives a warning. You'd lose that. To get it back you'd need verbally-typed variables: $foo :scalar = (1,3,5);# to get the warning and even then it's not necessarily going to be possible to make that elicit a warning at compile-time. * no sample code. If you're proposing something as big as this, I *really* want to see how it's going to change the language. Take an existing 30 line program that does lots of work with variables and convert it. Show me how it affects things like slices. I want to make sure that code that is currently easy doesn't become hard. * you complain that @foo will become more meaningless once we have different data structures that act as collections. You don't consider using @foo for those, though: my @foo : FIFO = (4,5); This fits in with my personal vision of how Perl6 will handle new data types: better support for tie, basically. You can plug in your own C or Perl code to implement new types that masquerade as scalars, arrays, or hashes. Someone else suggested this in the thread, and you treated it as already dealt with in the RFC, but I don't think it's dealt with at all. I can't see how saying my @foo : SOME_TYPE_THAT_IMPLEMENTS_ARRAY_OPERATORS = (4,5); is going to debase the meaning of '@'. Nat
Re: RFC 84 (v1) Replace = (stringifying comma) with =
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.
Perl makes easy things easy. Hashes are bloody useful, as the last
decade of Perl has borne out. They deserve syntactic support because
they're used a lot and are worthy of a shorthand.
Anybody who seriously suggests that something that is commonly used in
Perl should become *harder* (also aka longer to type) needs mental
realignment.
There are many bad ways to do things, and I think this is one of them.
Nat
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@error
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 know. How odd, I've only very rarely needed this. I don't mind the extra typing in the few situations it has come up. I'd rather the extra typing than YAQO (yet another quoting operator). Nat
Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument
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 all for making lvaluable subroutines work intelligently is one thing. He thinks it's not a good idea to make all subs lvaluable. Not every subroutine corresponds to a method call exposing object-internal data. Most of my subroutines *do* something and make no sense to be called lvaluably. Explicit marking the compiler pick up assignments to non-lvaluable subroutines. It makes sense to explicitly mark the rare cases (:lvalue), rather than the common (:no_assignment). Nat
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
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 integers (either arbitrary precision, or 64-bit). The epoch change would then be fine by me. But epoch changes don't solve the 2038 problem, Unix already tried that before the move to 32-bit integers (they moved the epoch from 1970 to 1971, I think, when their previous size of integer was about to run out of space, then when it ran out again next year they said "yeah, ok, wrong solution" :-). Nat
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
(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 be perl. Bogus argument. This is a non-issue. I'm talking about it being easy to run the same program on different platforms but share data. Optimize for Perl. The only valid interchange would be to specify the date unambiguously, for example the ISO mumble, help me Jarkko MMDDHHMMSS.fff This is good for comparison but bad for math. Epoch seconds are good for both. That's why *I* use them. You can continue to use ISO mumble and have it work for you. I'm not breaking your code. There's also the issue that Perl code should (where practical) be portable by default. Perl tries to cover up operating system oddities. This is one oddity that can (and, I think, should) be covered up. Nat
