> Well, RFC 23 doesn't mention ^0, and has several examples starting
> at ^1. And it draws the analogy between ^1, ^2, etc and $1, $2,
> etc. I didn't make it up.
My apologies. The examples you refer to are incorrect. They were added by
a helper, but the responsibility is mine -- for not
Well, RFC 23 doesn't mention ^0, and has several examples starting at ^1. And
it draws the analogy between ^1, ^2, etc and $1, $2, etc. I didn't make it up.
So I don't think you're being consistent here. Neither do I consider it an
improvement to add ^0.
While the positional placeholders may w
> So that's what I missed, that you expect named actual parameters to
> be legally passable to subs with unnamed formal parameters. I would
> consider that inappropriate, needing at least a warning.
Perhaps under:
use strict 'parameters';
> If people want to use named pa
hi all
Can any body tell me how do i learn mod perl and what is mod perl
i am new to perl and got some experence in php
can i get some guide lines
thanks in adv
reg
rajesh mats
--
QuantumLink Communications, Bombay, India
Damian Conway wrote:
>> Clever, and really obscure;
>
> "Invisible", rather than "obscure", I would say.
> DWIMity of the first order. :-)
>
>> wouldn't this then require that _everyone_ that
>> writes a curried expression for the sort sub use ^a & ^b, and that everyone
>> writing
> Except that Perl 6 people will know all about numbered parameters, so they
> will write:
>
> @out = sort ^2 cmp ^1, @in;
>
> and it will work just as they expect!
As long as they expect it to fail miserably! :-(
Now, go home and write it out 100 times:
"Array and
Clever, and really obscure; wouldn't this then require that _everyone_ that
writes a curried expression for the sort sub use ^a & ^b, and that everyone
writing a non-curried sort sub name their parameters a and b? I guess that
wouldn't necessarily be bad, but it would be restrictive.
Damian Conw
Larry Wall wrote:
> Jarkko Hietaniemi writes:
> : > > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still
> : > > consider the $ and $b to be warts.)
>
> Yes, but has anyone pointed out that
>
>@out = sort ^b cmp ^a, @in;
>
> won't do what people will certainly think it ou
Larry Wall wrote:
> Jarkko Hietaniemi writes:
> : > > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I
still
> : > > consider the $ and $b to be warts.)
> : > >
> : > And anyhow, this will work just fine (see RFC 23):
> : >
> : > $sum = reduce ^a + ^b, @numbers;
> :
> : I have b
Nathan Torkington wrote:
>
> David L. Nicol writes:
> > RFC: Perl6 is Final. There will Be No Perl7
> >
> > We declare that our framework willbe so flexiblke
> > that anything can be done with it and there will be no penalty
> > for something being in-core opposed to out-of-core and so on
Larry pointed out:
> Yes, but has anyone pointed out that
>
>@out = sort ^b cmp ^a, @in;
>
> won't do what people will certainly think it ought to?
It *will*, if C *names* the two values it passes to the
comparator!
E.g.:
sub sort (^&comparator, @list) {
Larry Wall wrote:
>
> Yes, but has anyone pointed out that
>
>@out = sort ^b cmp ^a, @in;
>
> won't do what people will certainly think it ought to?
>
> Larry
Well, this will hopefully be moot. I was inspired by discussion here, my
own disdain, and p5p strict issues to write an RFC simply
Jarkko Hietaniemi writes:
: > > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still
: > > consider the $ and $b to be warts.)
: > >
: > And anyhow, this will work just fine (see RFC 23):
: >
: > $sum = reduce ^a + ^b, @numbers;
:
: I have been amply reminded of this, thank
Nathan Wiger writes:
> Anyone RFC'ing this yet?
I could RFC it in vague terms, but I'm waiting to see how things
like interfaces turn out.
> Which reminds, anyone gonna RFC the rumored death of typeglobs? :-)
I figured that as Larry had used it as an example of things that were
up for grabs in
Nathan Torkington wrote:
>
> 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.
Anyone RFC'ing this yet?
This time I'm *not* voluntee
Larry Wall wrote:
> The main downside of accessors is that you can't (currently) say
>
> local $obj->attribute = 2;
Is anyone thinking of this? This comes at a good time when I've
been looking for just such an idea to shore up one of my proposals on
perl6-language-strict.
J. David
"David L. Nicol" wrote:
> > =head1 TITLE
> >
> > Default methods for objects
>
> Title does not match description. How about
>
> Overloadable bracketing
>
> or
>
> Brackets as Methods
>
> or
>
> Syntax as Overloadable Methods
Good point! Will be part of v2.
Christian
Jeremy Howard wrote:
>
> > 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".
> >
> Say "anything that can't be done *fast
> : Text::Balanced has to track in order to parse almost any Perl code.
>
> It's a good thing you said "almost".
Ah, that Jesuit education finally pays off! ;-)
> Does it parse [*]] correctly?
No, but only because C ignores punctuation vars entirely.
It would be a simple fix to
Nathan Torkington writes:
: The fact that other languages can implement it trivially doesn't mean
: that Perl can. I'd like us to have realized what kind of internals
: support is needed for a language feature (e.g., optree duping for
: partially-evaluated subroutines) *before* speccing out the i
[EMAIL PROTECTED] writes:
: Bare C and bare C *are* the main culprits. They require
: the tokenizer to track expression semantics so that when it encounters a
: '/' or '?' it can tell whether a pattern is plausible in this place or
: whether they've reached a division or hook operator, respectivel
> > * The match operator, C, 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?
Bare C and bare C *are* the main
> So perhaps you should ask people to contribute implementation notes
> sections to your RFCs rather than entire RFCs? And no sense in requiring
> that for the initial version, though a solicitation in the text of the
> RFC itself might hasten their appearance.
I thought that was what
> > If there are any RFC's which you have in mind and could send me your
> > notes on, I'd be *more* than happy to help out.
> >
> This is actually an excellent idea, because then Damian can
> concentrate on coming up with the key ideas. However, rather than
> having to shuffle n
On Sat, Aug 19, 2000 at 07:57:34AM +1000, Jeremy Howard wrote:
> The choice of algorithms is a great idea, but why do we need a modifier?
> Isn't it a pretty straightforward set of rules that allow us to decide if a
> DFA matcher will work?
Well, that all depends what the meaning of the word work
> 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".
>
Say "anything that can't be done *fast*enough* with a pure perl module" an
On Fri, 18 Aug 2000, David L. Nicol wrote:
> There will Be No Perl7
Of course not. Odd numbers are the development releases. The next
Perl after 6 will be 8.
Seriously, while a worthwhile goal, this is rather short-sighted.
The industry and the world will continue to change in spite (or
beca
Stephen P. Potter writes:
> * The match operator, C, 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 C, C, and C with equiva
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
David L. Nicol writes:
> RFC: Perl6 is Final. There will Be No Perl7
>
> We declare that our framework willbe so flexiblke
> that anything can be done with it and there will be no penalty
> for something being in-core opposed to out-of-core and so on.
Bad idea. You can't make anything
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) o
Damian Conway writes:
> me, at least) trivial implementation issues, well documented in the
> compiler literature. I choose to ignore them because I *have* to ignore
> them or my brain is going to melt.
The brief explanations you gave ("here's how it would be translated",
and "walk each statement
Robert Mathews wrote:
>
> > James Mastros wrote:
> > > [/f for fast DFA regexen]
> Jeremy Howard wrote:
> > The choice of algorithms is a great idea, but why do we need a modifier?
> > Isn't it a pretty straightforward set of rules that allow us to decide if a
> > DFA matcher will work? It woul
Damian Conway wrote:
>
> It was simply attempting to explain why I choose to ignore what are (to
> me, at least) trivial implementation issues, well documented in the
> compiler literature. I choose to ignore them because I *have* to ignore
> them or my brain is going to melt.
So perhaps you sho
Here's my RFC todo list which I am dropping like a good mensch
on the occasion of Friday Evening.
RFC: Perl6 is Final. There will Be No Perl7
We declare that our framework willbe so flexiblke
that anything can be done with it and there will be no penalty
for something being in-
Steve Fink writes:
> True. Would anyone mourn @$scalar_containing_variable_name if it died?
> I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't
> notice $x="var"; print @$x either -- it'll complain if you mention @var
> once.
These are symbolic references. You can forbid them
Nathan Wiger wrote:
> Damian Conway wrote:
> >
> > You're error is in assuming I have time *now*.
> >
> > With 30+ RFCs still to write, I've been seriously contemplating
> > just abandoning the Perl 6 effort, because added to the demands
> > of my full-time job, my O'Reilly and other tutorial comm
Robert Mathews wrote:
>
> > James Mastros wrote:
> > > [/f for fast DFA regexen]
> Jeremy Howard wrote:
> > The choice of algorithms is a great idea, but why do we need a modifier?
> > Isn't it a pretty straightforward set of rules that allow us to decide if a
> > DFA matcher will work? It would
Peter Scott wrote:
>
> At 05:12 AM 8/19/00 +1000, Damian Conway wrote:
> >> The main downside of accessors is that you can't (currently) say
> >>
> >> local $obj->attribute = 2;
> >
> >Even if C returns an lvalue???
>
> If it does, how do you localize it? What would that mean?
Nathan Torkington wrote:
>
> 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 }
True. Wou
> James Mastros wrote:
> > [/f for fast DFA regexen]
Jeremy Howard wrote:
> The choice of algorithms is a great idea, but why do we need a modifier?
> Isn't it a pretty straightforward set of rules that allow us to decide if a
> DFA matcher will work? It would be a lot nicer if Perl could just not
James Mastros wrote:
> On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote:
> > There is one significant area of perl that has very little attention
here
> > (other than one of my RFCs) that is regexs.
> >
> > Perl has very powerfull regexs - but what other features might be
desirable?
"Casey R. Tweten" wrote:
>
> This looks counter intuitive, my brain says to dereference the reference at the
> begining, just like you make the reference, in other words, keep it all the
> same:
>
> $hashref->{key}->@ # Deref
> $hashref->{key}->$ # Deref
> $hashref->{key}->% # Deref
> $hashref->
Nathan Torkington wrote:
>
> Steve Fink writes:
> > We are NOT here to construct a radically better language. We are here to
> > design the underpinnings of one.
>
> Perhaps. And by "perhaps", I mean "no".
>
> We're here to say what we'd like to see in the next version of Perl.
> These can be
[Apologies for following-up my own post]
I wrote:
> You're error is in assuming I have time *now*.
>
> With 30+ RFCs still to write, I've been seriously contemplating
> just abandoning the Perl 6 effort, because added to the demands
> of my full-time job, my O'Reilly and other tu
On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote:
> There is one significant area of perl that has very little attention here
> (other than one of my RFCs) that is regexs.
>
> Perl has very powerfull regexs - but what other features might be desirable?
Well, one thing that has aca
Glenn Linderman wrote:
>
> If a curried subroutine is truly generated because of seeing an
> expression containing placeholders, then that expression contains some
> finite number of placeholders. Each placeholder turns into a parameter
> of the generated subroutine. The generated subroutine has,
Glenn Linderman wrote:
>
> Nathan, thanks for zeroing in on this paragraph from RFC 23. It raises a
> question in my mind about the meaning of the RFC, and whether the paragraph is
> even necessary, which could answer your question about implementation.
>
> If a curried subroutine is truly gene
On Sat, Aug 19, 2000 at 06:35:55AM +1000, Damian Conway wrote:
> You're error is in assuming I have time *now*.
>
> With 30+ RFCs still to write, I've been seriously contemplating
> just abandoning the Perl 6 effort, because added to the demands
> of my full-time job, my O'Reilly and other tutori
Jarkko Hietaniemi wrote:
> > $item:n would be the position $item had in the last container it was in
>
> $item:i, you surely meant? $item:n would be the size of the list...
The size of the list would be something like $#{$item:contained_in}
the size of the list is not a property of the item, s
Damian Conway wrote:
>
> You're error is in assuming I have time *now*.
>
> With 30+ RFCs still to write, I've been seriously contemplating
> just abandoning the Perl 6 effort, because added to the demands
> of my full-time job, my O'Reilly and other tutorial commitments,
> my modules, and my poo
> > The subroutines generated by a placeholder are not exactly like
> > the equivalent subroutines shown above. If they are called with
> > fewer than the required number of arguments, they return another
> > higher order function, which now has the specified arguments
> > bound as
Nathan, thanks for zeroing in on this paragraph from RFC 23. It raises a
question in my mind about the meaning of the RFC, and whether the paragraph is
even necessary, which could answer your question about implementation.
If a curried subroutine is truly generated because of seeing an expressio
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 (${\
> Here is a few throw away thoughts - they don't constitute RFC
> material yet, I am not sure if they would be that useful and have
> not yet thought of any syntax, but any others? All of these can be
> done today but are not necessarily "easy".
>
> * Embeded patterns that do no
Hi,
There is one significant area of perl that has very little attention here
(other than one of my RFCs) that is regexs.
Perl has very powerfull regexs - but what other features might be desirable?
I had one long term good idea on assignment and submitted that, but there
may be other things peo
At 05:12 AM 8/19/00 +1000, Damian Conway wrote:
>> The main downside of accessors is that you can't (currently) say
>>
>> local $obj->attribute = 2;
>
>Even if C returns an lvalue???
If it does, how do you localize it? What would that mean?
--
Peter Scott
Pacific Systems Design
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
Jonathan Scott Duff wrote:
>
> Does the presence of an ordering subroutine cause perl to generate a
> linked list of all the elements of the %hash in the proper sequence
> prior to iteration (and somehow attach it to the iterator)? Seems
> like everytime we did that it would generate a new oper
> The main downside of accessors is that you can't (currently) say
>
> local $obj->attribute = 2;
Even if C returns an lvalue???
Damian
> What if the hash keys we want to use are not valid scalar names? For example,
> I've had keys like "total - female" as keys, but using the ^ syntax
> would fail on this...
^{"total - female"}, just like $ variables.
Damian
Today around 2:47pm, Jerrad Pierce hammered out this masterpiece:
: That's pretty damn nifty, too problems though:
Thanks :-)
: print SCALAR $hashref->{key}, "\n";
: is bogus, SCALAR eats the newline as an argument.
: Granted this could be fixed with parens, but somehwat disap
Nathan Torkington writes:
: Steve Fink writes:
: > We are NOT here to construct a radically better language. We are here to
: > design the underpinnings of one.
:
: Perhaps. And by "perhaps", I mean "no".
:
: We're here to say what we'd like to see in the next version of Perl.
: These can be bi
In reply to your message from the not too distant future: next Friday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Fri, 18 Aug 2000 14:47:44 EDT
From: Jerrad Pierce
That's p
Perl6 RFC Librarian writes:
> =head2 Re-currying deferred expressions
>
> The subroutines generated by a placeholder are not exactly like the
> equivalent subroutines shown above. If they are called with fewer than the
> required number of arguments, they return another higher order function,
> w
This had bugged me too. But the solution I had arrived at is slightly
different. What do you think?
($retval, $scalar) = chomp $scalar;
or
($retval, @list) = chomp @list;
In list mode chomp returns a list whose first element is the return value,
the remainder being the modified value(s).
In cur
Steve Fink writes:
> We are NOT here to construct a radically better language. We are here to
> design the underpinnings of one.
Perhaps. And by "perhaps", I mean "no".
We're here to say what we'd like to see in the next version of Perl.
These can be big things (currying) or small (hashes retur
Today around 2:04pm, Casey R. Tweten hammered out this masterpiece:
: Today around 10:45am, Steve Fink hammered out this masterpiece:
:
: : Ted Ashton wrote:
: : >
: : > > all
: : > > dereferencing can be done with ->.
: : >
: : > I
Today around 10:45am, Steve Fink hammered out this masterpiece:
: Ted Ashton wrote:
: >
: > > all
: > > dereferencing can be done with ->.
: >
: > Is that "can be done with" or "must be done with"?
: >
: > Either way, I like the ide
Ted Ashton wrote:
>
> > all
> > dereferencing can be done with ->.
>
> Is that "can be done with" or "must be done with"?
>
> Either way, I like the idea. To me it reads more smoothly, and as I seldom
> dare to use the double-punctu
Damien Neil wrote:
>
> On Thu, Aug 17, 2000 at 03:10:44PM -0700, Steve Fink wrote:
> > My proposal would be what I implemented for perl5 a while back (Sarathy
> > didn't dislike it, but wasn't convinced enough to put it in): all
> > dereferencing can be done with ->.
> >
> > $x->@ is the same as
On 8/18/00 11:56 AM, Larry Wall wrote:
> I'm not sure we have to throw out the orthogonality of OO to data
> structure to get what you want.
Do you mean orthogonality of syntax or implementation? Or both?
It seems like it might be both cleaner and easier to allow "Perl 5 o-o" to
live on largely
> $hour = 0 .. 24
Did you mean 0 .. 23?
> $wday = 1 .. 7 # 1 == Sunday, 7 == Saturday
> I'm still a little uneasy about C<$wday> starting with 1 == Sunday, just
> because Monday seems like the first day of the week to me. But I'm not
> the one writing the calendars, and it
(Damn these CC's!)
On Fri, Aug 18, 2000 at 09:19:55AM -0700, Larry Wall wrote:
> We seem to be asking for contradictory things here. If it's truly
> opaque, the programmer shouldn't care whether it's polymorphic or
> monomorphic.
That's right.
> I'm inclined to think the polymorphic solution w
[EMAIL PROTECTED] writes:
: To put it another way, no one should ever be tempted to do this:
:
: $obj->{'attribute'}
:
: for efficiency reasons inside a tight loop or what have you. (And no,
: the solution is not to "use C when you need efficiency." I shouldn't
: need to use portable assem
On Fri, 18 Aug 2000, Jonathan Scott Duff wrote:
> On Fri, Aug 18, 2000 at 10:39:36AM -0500, Brian Wheeler wrote:
> > "Using" might be an interesting alternative
>
> Reminds me of BASIC :-)
Works for me.
> > What if the hash keys we want to use are not valid scalar names? For examp
On Fri, Aug 18, 2000 at 10:39:36AM -0500, Brian Wheeler wrote:
> "Using" might be an interesting alternative
Reminds me of BASIC :-)
> What if the hash keys we want to use are not valid scalar names? For example,
> I've had keys like "total - female" as keys, but using the ^ syntax
> would fai
I've usually been lurking, but I have a few thoughts
>
> On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
>
> > BTW, if we define C to map keys of a hash to named place holders
> > in a curried expression, this might be a good thing:
> >
> > with %person {
> > print "How
On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
> BTW, if we define C to map keys of a hash to named place holders
> in a curried expression, this might be a good thing:
>
> with %person {
> print "Howdy, ", ^firstname, " ", ^lastname;
> }
>
> # becomes
> sub {
On Fri, Aug 18, 2000 at 09:31:44AM +0100, Hildo Biersma wrote:
> Ah, syntax - I have no idea.
Well, syntax aside, how would this work?
> One thing we could do, theoretically:
>
> %hash = ('James' => 'Gibbon',
> 'Dave' => 'Mallon',
> 'Pete' => 'Munro');
>
> while (my ($key,
On Fri, Aug 18, 2000 at 03:46:10AM -0500, David L. Nicol wrote:
> Mike Pastore wrote:
> >
> > Any thoughts on this?
Yes, please, the idea, that is: I've wanted such a variable oftentimes.
What I'm not certain about is reusing the $#. Reusing obsoleted stuff
is Dangerous.
> Attributes.
>
> ($
Thus it was written in the epistle of Steve Fink,
>
> Which has next to nothing to do with any particular issue. And it's too
> hard to argue when we agree.
:-).
> If I asked you which variable $x[4] is accessing, I bet you'd say @x.
> Which is one source of the confusion -- in one case, you us
Damian Conway <[EMAIL PROTECTED]> writes:
> I'd like to say that I whole-heartedly endorse the sentiments expressed in
> this RFC (and *not* just because it likes my book! ;-)
Well, it is a very good book...
> Well done, John.
Seconded.
--
Piers
Mike Pastore wrote:
>
> Any thoughts on this?
Attributes.
($item : arrayposition) would tell us what the position is.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Does despair.com sell a discordian calendar?
"David L. Nicol" wrote:
>
> Hildo Biersma wrote:
> >
> > > =head1 ABSTRACT
> > >
> > > Herein a new syntax is introduced to specify a sort function
> > > for the keys of any hash.
> > >
> > > =head1 DESCRIPTION
> > >
> > > %professors{ $a->name cmp $b->name };
> >
> > I feel the sort orde
Damian Conway <[EMAIL PROTECTED]> writes:
> Okay, what if C simply aliased its hash argument to a
> localized %_ (remember that one?):
>
> with (%ws) {
> print $_{height}; # prints $ws{height}
> print $height; # perl5 visibility rules
>
> =head1 ABSTRACT
>
> Herein a new syntax is introduced to specify a sort function
> for the keys of any hash.
>
> =head1 DESCRIPTION
>
> %professors{ $a->name cmp $b->name };
I feel the sort order should be specified on the iterator, not on the
hash variable. It should be possible to
"David L. Nicol" wrote:
>
> What if its a method of anything in an array? $_ is already
> a reference to the object on the array in for loops rather
> than a copy of it. What if we make change be not something about
> for loops, but about anything in an array?
>
> print "The index, in
88 matches
Mail list logo
