v6d.pod
Log Message:
---
Add proposal to codify rules on matching brackets
All matched delimiters to should be determined by their
Unicode properties. I propose two simple rules to adopt
for uniformity, elegance and clarity.
-operators.pod
Log Message:
---
Change square brackets to french angle quotes
:
M S02-bits.pod
Log Message:
---
Added omitted square brackets example with parametric typing.
-bits.pod
Log Message:
---
Spec halfwidth corner brackets for Q[] equivalent
This is primarily to improve output of strings that mostly want
to be complete quoted, to avoid cluttering such output with Q[].
But to allow it for .perl output, we have to allow it on input too.
>>>>>> "m" == moritz writes:
>
> m> S02 says:
>
> m> "To get a Perlish representation of any object, use the .perl method.
> Like
> m> the Data::Dumper module in Perl 5, the .perl method will put quotes
> around
> m> s
Uri,
On Sun, 04 Jan 2009 22:37:43 -0500, Uri Guttman wrote:
> that fails with nested arrays. we don't want them to flatten.
>
> my $c = eval '(1, (4, 5), 3)';
>
> will that work as you envision?
No, but it's not what I'm proposing. A reference must Perlify as a
reference, just as it does toda
y more) solves that problem for us.
ML> If you say
ML> my @c = eval '(1, 2, 3)';
ML> then @c has three elements. If you say
ML> my $c = eval '(1, 2, 3)';
ML> then Perl constructs (if I've got the Perl 6 lingo right) an Array object
ML&g
t;
> m> @a.push eval(@b.perl)
>
> m> would then DWIM.
>
> for your def of DWIM. i can see wanting an anon array to be pushed onto
> @a building up a structure.
That would be easily achievable if we made the change I'm suggesting, so
that C<@a.perl> emitted ro
>>>>> "m" == moritz writes:
m> S02 says:
m> "To get a Perlish representation of any object, use the .perl method. Like
m> the Data::Dumper module in Perl 5, the .perl method will put quotes around
m> strings, square brackets around list value
rrect here?
S02 says:
"To get a Perlish representation of any object, use the .perl method. Like
the Data::Dumper module in Perl 5, the .perl method will put quotes around
strings, square brackets around list values,"
So according to this, Rakudo has it right.
But I think that a .perl()if
/6$ perl6 -v
This is Rakudo Perl 6, revision 34744 built on parrot 0.8.2-devel
for i486-linux-gnu-thread-multi.
Copyright 2006-2008, The Perl Foundation.
m...@edward:~/perl/6$
Because C<@a.perl> returns a string surrounded in square brackets, rather
than round brackets, C produces a list
On Fri, 3 Dec 2004, Larry Wall wrote:
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
: This whole issue kind of makes me go 'ugh'. One of the things I like
: best about Perl is the amazing simplicity of the <> input construct.
Hmm.
while (<>) {...}
for .lines {...}
Looks l
On Mon, 06 Dec 2004 12:22:22 GMT, Smylers <[EMAIL PROTECTED]> wrote:
David Green writes:
I guess we could always use prepend/append, pull/pop.
No! C and C are a well-defined pair, not just in Perl, for
dealing with stacks; we should keep those as they are. (And no
synonyms, before somebody sugges
Austin Hastings wrote:
I'll guess that you're pointing at
.:send_one($_);
Which supposedly uses "topic" to resolve .:send_one into $this.send_one.
If that works, then I'm happy -- I like being able to control topic and
$_ differently. But if C changes topic, then what?
OUTER::.:send_one($_);
Yu
On Mon, 6 Dec 2004 11:34:24 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
> Though it's awfully tempting to fill in the holes in the periodic table:
>
> ($a, $b, $c) = @foo *<< 3;
>
> And then just say all the corresponding unaries default to 1 (or the arity
> of the left):
>
> $bit = +<<
stuff & grab :-)
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-- Original message --
> On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote:
> : But I'd be willing to rename them to get/put.
>
> If I went with "get", the opposite
Luke Palmer wrote:
class MyStream {
has $.stream;
method :send_one ($item) {
$.stream.send($item);
}
method send ([EMAIL PROTECTED]) {
.:send_one("BEGIN");
for @data {
.:send_one($_);
}
.:send_one("
Matthew Walton writes:
> Luke Palmer wrote:
>
> >The remaining problem is what to do about unary dot. Repeated here for
> >the, er, benefit? of p6l:
> >
> >class Duple {
> >has $.left;
> >has $.right;
> >
> >method perform (&oper) {
> >&oper($.left);
> >
On Mon, Dec 06, 2004 at 03:50:42PM -0500, Austin Hastings wrote:
: Larry Wall wrote:
:
: >On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: >: >If I went with "get", the opposite would be "unget" for both historical
: >: >and huffmaniacal reasons.
: >
: >
: Why? (I get the huffman, not
Larry Wall wrote:
On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: >If I went with "get", the opposite would be "unget" for both historical
: >and huffmaniacal reasons.
Why? (I get the huffman, not the history.) Is it just a nod to unshift?
Given the existence of a unary = for abbrev
Luke Palmer wrote:
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (&oper) {
&oper($.left);
&oper($.right);
}
}
Let's change that i
On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: >If I went with "get", the opposite would be "unget" for both historical
: >and huffmaniacal reasons.
:
: But "get" has too strong a class accessor connotation in most OO.
:
: "unpull?" ;-)
Given the existence of a unary = for abbrevia
On Mon, Dec 06, 2004 at 01:25:29PM -0600, Rod Adams wrote:
> Dan Brian wrote:
>
> >>If I went with "get", the opposite would be "unget" for both historical
> >>and huffmaniacal reasons.
> >
> >
> >But "get" has too strong a class accessor connotation in most OO.
> >
> >"unpull?" ;-)
> >
> >
> push
Dan Brian wrote:
If I went with "get", the opposite would be "unget" for both historical
and huffmaniacal reasons.
But "get" has too strong a class accessor connotation in most OO.
"unpull?" ;-)
pushf/popf. f is for "front".
But I still don't see anything wrong with shift/unshift.
I'd prefer to
On Mon, Dec 06, 2004 at 10:59:18AM -0800, Larry Wall wrote:
> On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote:
> : On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
> : > On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
> : > : Can we ditch C in the exa
On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote:
: On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
: > On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: > : Can we ditch C in the examples in favor of C, for a while? :)
: >
: > Okay. Have an example
If I went with "get", the opposite would be "unget" for both historical
and huffmaniacal reasons.
But "get" has too strong a class accessor connotation in most OO.
"unpull?" ;-)
On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
> On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
> : Can we ditch C in the examples in favor of C, for a while? :)
>
> Okay. Have an example:
>
> while =$IN -> $line {...}
>
> I think that works. I'm back to thin
Larry Wall writes:
> Currently it does. There have been some rumblings in the design team
> that maybe it shouldn't. But it occurs to me that this might be another
> spot to have our cake and eat it to. We could say that
>
> for @foo -> $input { ... $input ... }
>
> doesn't set the topic i
David Wheeler wrote:
On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
for =<> {...}
I dub the...the fish operator!
:-)
Back before there was a WWW, I used an editor called "tgif". It was
written in france, and part of the idiom was to have two GUI buttons
showing respectively the head (" <
On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote:
: But I'd be willing to rename them to get/put.
If I went with "get", the opposite would be "unget" for both historical
and huffmaniacal reasons.
Larry
Or even the dead fish operator:
while =<###x> -> $net {...}
And here's a flounder:
while =<:>
Larry
On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: = Idiom:
:
: The other concern is idiom. Using C suggests "start at the
: beginning, continue to the end". OTOH, using C is a little
: "weaker" -- "keep doing this until it's time to stop". Obviously they'll
: usually be use
On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: Two more issues: idiom, and topification
:
: = Topification:
:
: There are cases in P5 when I *don't* want
:
: while (<>) {...}
:
: but prefer
:
: while ($input = <>) {...}
:
: so that I can have something else be the to
On Mon, Dec 06, 2004 at 09:06:22AM -0800, David Wheeler wrote:
: On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
:
: >> for =<> {...}
:
: I dub the...the fish operator!
:
: :-)
Mmm. Next thing you'll know, people will name their files oddly just so
they can write things like:
for = {
On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
for =<> {...}
I dub the...the fish operator!
:-)
David
Smylers wrote:
Larry Wall writes:
But then are we willing to rename shift/unshift to pull/put?
Yes. C is a terrible name; when teaching Perl I feel
embarrassed on introducing it.
No!
But I'd be willing to rename them to get/put.
'Pull' is the opposite of 'push', but 'pop' already works.
Larry Wall wrote:
But here's the kicker. The null filename can again represent the
standard filter input, so we end up with Perl 5's
while (<>) {...}
turning into
for =<> {...}
Two more issues: idiom, and topification
= Topification:
There are cases in P5 when I *don't* want
while (<
David Green writes:
> I guess we could always use prepend/append, pull/pop.
No! C and C are a well-defined pair, not just in Perl, for
dealing with stacks; we should keep those as they are. (And no
synonyms, before somebody suggests any!)
Smylers
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Luke Palmer) wrote:
>But what we'd really like to do is: given the user knows what push/pop
>do, what would they *guess* to mean shift (I tend to think that this
>is a very good technique for naming).
>And, well, I'm thinking pull. So it's a t
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Matt Diephouse) wrote:
>On Sat, 04 Dec 2004 08:59:24 -0700, David Green <[EMAIL PROTECTED]> wrote:
>C signifies a role named "Iterate". Roles are sort of a
>mix of interfaces and mixins (as I understand it -- I'm still waiting
>for E12). So sayin
It makes good sense to me -- if we're trying to move a piano from you
to
me then either you can push or your end or I can pull on my end: we're
operating on different ends of it, but the effect in both cases is
moving in one direction.
As a mnemonic for remembering which side push/pull operate on,
Dan Brian writes:
> Having push and pull operate on opposite ends of an array strikes me
> as more confusing than even shift.
It makes good sense to me -- if we're trying to move a piano from you to
me then either you can push or your end or I can pull on my end: we're
operating on different ends
If there's a willingness to rename shift/unshift, why not consider
going a bit further (and offend shell heritage) to note that pull/put
aren't really linguistically opposed either (unlike push/pull). Why
not
rename pop to pull, and use something like put/take for shift/unshift?
That goes way beyo
On Thursday, December 2, 2004, 10:08:31 AM, you
(mailto:[EMAIL PROTECTED]) wrote:
> On Tue, 30 Nov 2004, Austin Hastings wrote:
>> How about just having C< system() > return a clever object with .output and
>> .err methods?
> interesting...
> Michele
Prior art of this on Windows...
http:/
Dan Brian writes:
> If there's a willingness to rename shift/unshift, why not consider
> going a bit further (and offend shell heritage) to note that pull/put
> aren't really linguistically opposed either (unlike push/pull). Why not
> rename pop to pull, and use something like put/take for shift
On Sat, 4 Dec 2004 23:33:24 -0700, Dan Brian <[EMAIL PROTECTED]> wrote:
> If there's a willingness to rename shift/unshift, why not consider
> going a bit further (and offend shell heritage) to note that pull/put
> aren't really linguistically opposed either (unlike push/pull). Why not
> rename pop
C's only virtue, IMHO, is that it's clearly the inverse of
C. But I think the spelling and aural relationship between
C, C, C, and C is clear enough to negate that.
But then, I'm a little biased.
Except that push and pull are logical opposites linguistically, but
not in standard CS parlance. coul
Brent 'Dax' Royal-Gordon wrote:
Smylers <[EMAIL PROTECTED]> wrote:
Yes. C is a terrible name; when teaching Perl I feel
embarrassed on introducing it.
C's only virtue, IMHO, is that it's clearly the inverse of
C. But I think the spelling and aural relationship between
C, C, C, and C is cl
Smylers <[EMAIL PROTECTED]> wrote:
> Yes. C is a terrible name; when teaching Perl I feel
> embarrassed on introducing it.
C's only virtue, IMHO, is that it's clearly the inverse of
C. But I think the spelling and aural relationship between
C, C, C, and C is clear enough to negate that.
But the
David Green <[EMAIL PROTECTED]> wrote:
> Aren't lazy lists a funny kind of iterator? Ones that memoise their
> results. And supply an indexing method [].
As I mentioned the other day, I fail to see any material difference
between an iterator and a lazy list, except that a few operations are
allo
On Sat, Dec 04, 2004 at 01:24:41PM -0800, Larry Wall wrote:
: I suppose we could also have
:
: for words <> {...}
: for tokens <> {...}
: for paragraphs <> {...}
: for chunks(<>, :delim(/^^===+\h*\n/)) {...}
:
: etc.
I see a problem with
for words <> {...}
since there's lik
On Sat, Dec 04, 2004 at 11:08:38PM +0300, Alexey Trofimenko wrote:
> On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams <[EMAIL PROTECTED]> wrote:
>
> >Okay, this rant is more about the \s<\s than \s=\s. To me, it is easier
> >to understand the grouping of line 1 than line 2 below:
> >
> >if( $a<$b &
On Sat, Dec 04, 2004 at 11:02:38PM +0300, Alexey Trofimenko wrote:
: hm. we have short and strange , for input.. (and for some reason, it
: is bracketing! there's no sense at all in it)
: ..but we have long (and even looking slightly OOish, in perl5 sense) print
: FH for output, and noone compl
On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams <[EMAIL PROTECTED]> wrote:
Okay, this rant is more about the \s<\s than \s=\s. To me, it is easier
to understand the grouping of line 1 than line 2 below:
if( $a<$b && $c<$d ) {...}
if( $a < $b && $c < $d ) {...}
In line2, my mind has to stop and ask
On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams <[EMAIL PROTECTED]> wrote:
Larry Wall wrote:
for =$*IN {...}
for =$*ARGS {...}
for = {...}
for = {...}
for =Â$foo.c $foo.h {...}
for =['foo.c', 'foo.h'] {...}
for =['.myrc', @*ARGS] {...}
for [EMAIL PROTECTED] {...}
for =<> {
On Fri, Dec 03, 2004 at 06:38:42PM -0800, Larry Wall wrote:
> On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
> : This whole issue kind of makes me go 'ugh'. One of the things I like
> : best about Perl is the amazing simplicity of the <> input construct.
>
> Hmm.
>
> while
Rod Adams writes:
> Okay, this rant is more about the \s<\s than \s=\s. To me, it is easier
> to understand the grouping of line 1 than line 2 below:
>
> if( $a<$b && $c<$d ) {...}
> if( $a < $b && $c < $d ) {...}
>
> In line2, my mind has to stop and ask: is that "($a < $b) && ($c <
> $d)", or
Larry Wall wrote:
So you can say
for =$*IN {...}
for =$*ARGS {...}
for = {...}
for = {...}
for =«$foo.c $foo.h» {...}
for =['foo.c', 'foo.h'] {...}
for =['.myrc', @*ARGS] {...}
for [EMAIL PROTECTED] {...}
for =<> {...}
The simplicity is nice, but the visual message is,
On Sat, 4 Dec 2004 01:37:00 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
> for =$*IN {...}
> for =$*ARGS {...}
Yay. A generalised form of the input operator, which can create even
handier idioms for simple file processing. Maybe I wasn't clear
enough. My issue wasn't specifically with '.lin
On Sat, 04 Dec 2004 08:59:24 -0700, David Green <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Matt Diephouse) wrote:
> >Supposing
> >class Filehandle does Iterate; # Iterate or Iterator?
> >we have an easy way to create new iterators. I'm not sure how useful
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Matt Diephouse) wrote:
>What I mean is that Perl takes an array and makes an iterator out of it.
>Sure, you probably don't think about it like that, but the behavior is
>the same (who says arrays need to iterate starting at element zero?).
I prob
On Fri, Dec 03, 2004 at 06:38:42PM -0800, Larry Wall wrote:
: Might even just be a global multi sub that defaults to $*ARGS:
:
: multi sub *lines (IO ?$handle = $*ARGS) {...}
: multi sub *lines (Str $filename) {...}
: multi sub *lines (IO @handle) {...}
: multi sub *lines (Str @fil
Okay, maybe I should have gone to bed, but I kept thinking about this.
I'm starting to suspect it's time to haul out the operator I've
been holding in reserve for lo these many years now, the unary =.
Suppose we say that it iterates iterators, but also it recognizes
certain things that aren't itera
Larry Wall writes:
> But then are we willing to rename shift/unshift to pull/put?
Yes. C is a terrible name; when teaching Perl I feel
embarrassed on introducing it.
Given the nature of many of the other changes in Perl 6, completely
changing regexps for example, renaming a couple of functions
ecord separator. C<.next_byte> and
family could be implemented on top of that as well.
The biggest problem I see (and I may just be blind) is that
for $iterator -> $x { ... }
is slightly ambiguous to the programmer, which makes me want angle
brackets back. Other syntax could be use
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
: This whole issue kind of makes me go 'ugh'. One of the things I like
: best about Perl is the amazing simplicity of the <> input construct.
Hmm.
while (<>) {...}
for .lines {...}
Looks like a wash to me.
: Replacing th
This whole issue kind of makes me go 'ugh'. One of the things I like
best about Perl is the amazing simplicity of the <> input construct.
Replacing that with something that not only is object oriented, but on
top of that also LOOKS object oriented is bound to be a loss. It's
going to be that bit lo
On Fri, Dec 03, 2004 at 09:31:33AM -0800, Larry Wall wrote:
: I guess the only real argument against unifying is that neither of
:
: for [EMAIL PROTECTED] {...}
:
: or
:
: for @foo {...}
:
: indicate destructive readout. Which probably says that *
: is the wrong operator to use for tha
On Fri, Dec 03, 2004 at 12:56:18AM -0800, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall <[EMAIL PROTECTED]> wrote:
: > Speaking of "at the moment", I just now updated the Synopses at
: > dev.perl.org.
:
: The new S2 says:
: # Heredocs are no longer written with <<, but with an adverb on any other
Larry Wall <[EMAIL PROTECTED]> wrote:
> Speaking of "at the moment", I just now updated the Synopses at
> dev.perl.org.
The new S2 says:
# Heredocs are no longer written with <<, but with an adverb on any other
# quote construct:
#
# print qq:to/END/
# Give $amount to the man behind
On Thu, Dec 02, 2004 at 09:15:50PM -0800, Larry Wall wrote:
: On Thu, Dec 02, 2004 at 02:54:42PM -0700, John Williams wrote:
: : Does / <-> / capture to $0{'-'} ?
: : Or should that be written / <-«alpha»> / ?
:
: At the moment I've got it that only assertions of the form capture.
Which is a bit
On Thu, Dec 02, 2004 at 02:54:42PM -0700, John Williams wrote:
: Does / <-> / capture to $0{'-'} ?
: Or should that be written / <-«alpha»> / ?
At the moment I've got it that only assertions of the form capture.
Anything else you have to do an explicit binding, or use :keepall.
Larry
John Williams writes:
> Is all the "Extensible metasyntax (<...>)" being changed to Â... ?
>
> Or is the new rule that <...> is capturing metasyntax, and Â... is
> non-capturing metasyntax?
That's the one.
> You can't really capture anything on an assertion, so
> /^foo .* <( do { say "Got
On Tue, 30 Nov 2004, Larry Wall wrote:
> Here's the proposal.
>
> First the bad news:
> * We accept that the C<< < >> operator requires whitespace
> around it, and be prepared to be burned in effigy occasionally.
My biggest worry about this is that people will be writing
if $x<3
loo
On Tue, 30 Nov 2004, Austin Hastings wrote:
How about just having C< system() > return a clever object with .output and
.err methods?
interesting...
Michele
--
Windows shuts down automaticaly giving an count down. what could be
the problem
Windows?
- "Le TeXnicien de surface" in comp.text.tex
On Tue, 30 Nov 2004, Brent 'Dax' Royal-Gordon wrote:
I like this in general. However...
Larry Wall <[EMAIL PROTECTED]> wrote:
* Since we already stole angles from iterators, «$fh» is not
how you make iterators iterate. Instead we use $fh.fetch (or
whatever) in scalar context,
Larry Wall <[EMAIL PROTECTED]> writes:
> On Tue, Nov 30, 2004 at 03:03:38PM -0800, Jon Ericson wrote:
> : while(<>) {...}
> You left out the most important phrase:
>
> "or whatever we decide is the correctest idiom."
I saw that, but I didn't know what to make of it. The Perl 5 idiom is
p
On Wed, Dec 01, 2004 at 09:55:32AM +, Matthew Walton wrote:
: >I neglected to mention that the smart quoter should also recognize
: >pair notation and handle it.
:
: I've been trying to get my brain round that, but I can't quite figure
: out what you mean. Pair notation is, as I understand it
On Wed, 01 Dec 2004 07:41:18 GMT, Smylers <[EMAIL PROTECTED]> wrote:
> John Siracusa writes:
>
> > Call me crazy, but at this point I'm prone to stick with what I've done in
> > Perl 5 for years:
> >
> > $var{'key1'}{'key2'}[3]{'key3'}
>
> In which case do that, since it'll still work in Perl
Matthew Walton writes:
> Pair notation is, as I understand it, when you get
>
> key => value
That can now also be written as:
:key
or, where value is 1, simply as:
:key
I suspect it was this form that Larry was referring to.
Smylers
Matthew Walton skribis 2004-12-01 10:11 (+):
> Well that depends... are you intending to write programs, or drive the
> world insane?
Yes.
Juerd
Juerd wrote:
Matthew Walton skribis 2004-12-01 9:55 (+):
Yes, that would be fun... almost worth throwing out a compiler warning
for that, especially if we've still got use warnings. Something like
Warning: «{ }» creates empty list
It should generate a warning similar to the warning of inte
Matthew Walton skribis 2004-12-01 9:55 (+):
> Yes, that would be fun... almost worth throwing out a compiler warning
> for that, especially if we've still got use warnings. Something like
>
> Warning: «{ }» creates empty list
It should generate a warning similar to the warning of inte
Larry Wall wrote:
I thought so.
: I don't think I've ever used a hash slice in my life. Is there something
: wrong with me?
No, a lot of people are naturally monoindexous.
I like that word.
: >* The :w splitting happens after interpolation. So
: >
: > « foo $bar @baz »
: >
: > can end up
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Smylers) wrote:
>David Green writes:
>> I'm not even sure what those double-quotation marks are doing --
[...]
>Look back at how Larry defined the guillemets: [...]
>So the double-quotes in there are "shell-like", though I guess if you
>don't ha
David Green writes:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Larry Wall) wrote:
>
> >* The :w splitting happens after interpolation. So
> >« foo $bar @baz »
> >can end up with lots of words, while
> >« foo "$bar" "@baz" »
> > is guaranteed to end up wit
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Brent 'Dax' Royal-Gordon) wrote:
>I'm going to pull a Larry and think out
>loud for a minute here. Note that I speak authoritatively here,
Noted. Or not. =)
>Treating it like an array is wrong.
>On the other hand, what if a filehandle *is* an
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Larry Wall) wrote:
>Here's the proposal.
>First the bad news:
>* We accept that the C<< < >> operator requires whitespace
>around it, and be prepared to be burned in effigy occasionally.
I wouldn't go that far, although when I inevitably
output has an explicit C statement, but the input doesn't
appear to be anywhere in the code -- there's just some brackets in a
C loop, and it doesn't occur to people that brackets might have
the effect of reading from a file.
However, does anything in this proposal conflict with k
John Siracusa writes:
> Call me crazy, but at this point I'm prone to stick with what I've done in
> Perl 5 for years:
>
> $var{'key1'}{'key2'}[3]{'key3'}
In which case do that, since it'll still work in Perl 6.
Actually, it works 'better' in Perl 6, since it doesn't mislead in any
way.
I'
On Tue, 30 Nov 2004 19:10:48 -0800, Brent 'Dax' Royal-Gordon
<[EMAIL PROTECTED]> wrote:
> John Siracusa <[EMAIL PROTECTED]> wrote:
> > On 11/30/04 9:54 PM, Matt Diephouse wrote:
> > > use CGI «:standard»;
> > > [...]
> > > use CGi <:standard>;
> >
> > Who is doing this? I'm just saying...
>
On Tue, 30 Nov 2004 19:10:48 -0800, Brent 'Dax' Royal-Gordon
<[EMAIL PROTECTED]> wrote:
> John Siracusa <[EMAIL PROTECTED]> wrote:
> > Who is doing this? I'm just saying...
> >
> >use CGI ':standard';
I normally use qw// when use-ing. *shrug*
> And won't we just be doing:
>
> use CGI :
All the cool kids are thinking aloud these days. Why not jump on the
bandwagon?
Larry Wall writes:
> * We get the cute, clean and rather more typeable
>
> $var[3]
It looks like if you shook that up and down a bit, it would break in
half.
I wonder what would happen if we made <> a lit
John Siracusa <[EMAIL PROTECTED]> wrote:
> On 11/30/04 9:54 PM, Matt Diephouse wrote:
> > use CGI «:standard»;
> > [...]
> > use CGi <:standard>;
>
> Who is doing this? I'm just saying...
>
>use CGI ':standard';
And won't we just be doing:
use CGI :standard;
anyway?
--
Brent '
On 11/30/04 9:54 PM, Matt Diephouse wrote:
> use CGI «:standard»;
> [...]
> use CGi <:standard>;
Who is doing this? I'm just saying...
use CGI ':standard';
It really ain't all that broke, is it?
-John
On Tue, 30 Nov 2004 13:35:37 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
> The basic problem with «...» is that most of its uses
> were turning out to be more useful that the corresponding <...>.
> In fact, I was thinking about all this on the way home from Seattle
> yesterday (a 15-hour drive), a
On 11/30/04 6:35 PM, James Mastros wrote:
> Austin Hastings wrote:
>> Larry Wall wrote:
>>>* We get the cute, clean and rather more typeable
>>>
>>> $var[3]
"Cute" maybe (looks like a chain of fish)
> The problem with {} for a hash dereference operator is not it's
> typeablility, but rat
On Tue, Nov 30, 2004 at 03:03:38PM -0800, Jon Ericson wrote:
: Larry Wall <[EMAIL PROTECTED]> writes:
:
: > The p5-to-p6 translator will turn any
: >
: > while () {...}
: >
: > into
: >
: > for @$handle {...}
:
: Including:
:
: while(<>) {...}
:
: to
:
: for @$ {...}
:
: ?
You le
On Tue, Nov 30, 2004 at 06:27:55PM -0500, Matt Fowles wrote:
: Even if he wasn't cackling, I admit to feeling it. I don't even use
: the qx/qq/qw stuff in perl5. I always got by with "".
:
: Although I must admit to liking python's C< r"..." > meaning
: absolutely raw string (useful for avoiding
1 - 100 of 191 matches
Mail list logo
