ctors, but I don't think those get to get called
until everything goes away (since there's a reference chain between
them).
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
On Tue, 2005-11-15 at 12:30, Luke Palmer wrote:
> On 11/15/05, Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > This question came out of a joking comment on IRC, but it's a serious
> > concern. Can chained buts be optimized, or must the compiler strictly
> > create i
Larry (bless his wire-photographing heart) took the time to re-vamp S29.
Of course, this threw off all of my collating of S29, but that's fine
since he's actually answered more of my questions than I could have
hoped.
The fourth of July weekend was fairly slow for me, so I started with
Larry's S29
On Wed, 2006-07-05 at 16:09 -0400, Aaron Sherman wrote:
> The fourth of July weekend was fairly slow for me, so I started with
> Larry's S29 and went forward.
>
> My first pass at a revised S29 is attached.
I already see one problem. "as" slipped in, which is
The special directive, C<%n> does not work in Perl 6 because of the
difference in parameter passing conventions, but the example above
simulates its effect using C<%C>.
=cut
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
want to talk to a less officially
blessed language:
use Lang::Bash::Loader;
use Lang::Elisp::Loader;
bashuse "~/.bashrc";
elispuse "hanoi";
say %*ENV{PATH}
hanoi(13);
Inventing syntactic sugar for the back-end case probably doesn't buy
ltidimensional, C operates only on the first
dimension, and works with Array References.
=item unshift
our Int multi Array::unshift ( @array is rw, [EMAIL PROTECTED] )
our Int multi method Array::unshift ( @array: [EMAIL PROTECTED] )
C adds the values onto the start of the C<@array>.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
I've gathered my ducks in a row, used the feedback that I've gotten so
far, and I think I'm ready to officially update S29. For that I need two
things:
1) I'd really like Larry to glance over the changes and $s29.bless but
all comments are welcome
2) I'll need commit rights to whatever reposit
Darren Duncan wrote:
At 8:32 PM -0400 7/8/06, Joe Gottman wrote:
I have one minor comment about join. You should specify its behavior
when
it is passed an empty list. Does it return undef or the empty string?
I think it makes the most sense for it to return an empty string,
which is a reas
ition for each of these
functions into the section for each type of container (too many
eaches...). I don't even have a section for things like Seq and Buf yet,
and I'd rather not if I don't have to.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsm
On Tue, 2006-07-11 at 10:06 -0400, Aaron Sherman wrote:
> For example:
>
> our List multi Container::each(Container [EMAIL PROTECTED])
In thinking about each, I've come across an interesting need. I wrote
this example:
for each(=<>; 1..*) -> ($line, $lineno) {
behavior. Something like, "class Buf is Scalar, does
Container". Which really blows some assumptions that I'm willing to bet
many people will make.
--
Aaron Sherman <[EMAIL PROTECTED]>
On Tue, 2006-07-11 at 09:53 -0700, Trey Harris wrote:
> In a message dated Tue, 11 Jul 2006, Aaron Sherman writes:
> > But would it be reasonable to also provide a named-only parameter to
> > each for that purpose?
> It sounds reasonable to me, but :stop reads badly. Maybe C<
m still not clear on how :fewest and :most modify a container, but I'm
convinced that once I make sense of it, there will be other ways in
which I want to use that modifier.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
On Tue, 2006-07-11 at 16:22 -0400, Aaron Sherman wrote:
> zip(:fewest, @a;@b;@c); # Until one runs out
Once again, I missed some Larry magic. He already selected ":shortest"
for this, so I guess on roundrobin, it's ":longest"... ignore my
choices.
I think just
o feel out where the line between S29 and that document
are There's some overlap, but I want to keep it minimal.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
Smylers wrote:
[EMAIL PROTECTED] commits:
New Revision: 10077
Modified: doc/trunk/design/syn/S02.pod
==
-foo.bar # foo().bar -- postfix prevents args
+foo.bar# foo().bar -- illegal postfix
y for all the lame questions! I'm just trying to make
sure that the docs I write aren't utterly, worthlessly wrong. :-/
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
.
In fact, I would expect that this bit of behind-the-curtain magic is how
the MCP arranges for polymorphism when you:
sub foo(Object $x) {...}
my A $y;
foo($y);
Is all of that fair?
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good ma
:= $b.buf;
return $bufa >>===<< $bufb;
}
our Bool multi infix:<==> ( Int $a, Int $b ) {
return $a === $b;
}
our Bool multi infix:<==> ( Num $a, Num $b) {
return $a === $b;
}
our Bool multi infix:<==> ( Bool $a, Bool $b ) {
return $a === $b;
}
# ... complex, bit, etc.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
On Wed, 2006-07-12 at 15:32 -0500, Jonathan Scott Duff wrote:
> On Wed, Jul 12, 2006 at 04:16:13PM -0400, Aaron Sherman wrote:
> > On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
> > > 4. will we have a deep (possibly optimized[1]) equality operator, that
> > >
Yuval Kogman wrote:
On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote:
Then ~~ is wrong in that respect, and I think we should be talking about
that, not about making === into "~~, but without invoking code when it
shouldn't."
But it should! It's the sma
On Wed, 2006-07-12 at 17:52 -0700, Larry Wall wrote:
> On Wed, Jul 12, 2006 at 12:51:57PM -0400, Aaron Sherman wrote:
> : I would assume that all classes automatically define:
> :
> : multi submethod *infix: ($self: $?CLASS) { $self }
>
> Hmm, "as" is really onl
9 may not contain every function available to
Perl 6 programmers as a builtin, it will at least give Perl 5
programmers a sense of what happened to what they knew. The API
documents should probably be the more authoritative reference for
implementing P6 core libraries.
--
Aaron Sherman <
nship to each other that was obvious to the
programmer who wrote the statement.
Keep in mind that if you have an Any and you want to match against it
smartly, you can always request your poison:
$a ~~ ($b as Regex)
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
are scalarized here. Both C<~~>
and C/C provide scalar contexts to their arguments.
(You can always hyperize C<~~> explicitly, though.)
Both C<$_> (the value) and C<$x> (the match specification) here are
potentially references to container objects.
And since lists pro
On Mon, 2006-08-21 at 08:45 -0700, Chip Salzenberg wrote:
> On Mon, Aug 21, 2006 at 10:48:59AM -0400, Will Coleda wrote:
> > The way you phrase the question, you're not going to get any of these
> > answers. Who is programming parrot on their *physical* VT100? =-).
> > The primary reason for an
would mean that parrot is JITing to LLVM byte-code, which is JITing to
machine code. Not really ideal.
--
Aaron Sherman
Senior Systems Engineer and Toolsmith
[EMAIL PROTECTED] or [EMAIL PROTECTED]
John Siracusa wrote:
On 8/23/06 4:09 PM, Aaron Sherman wrote:
here's the problem with that: llvm is a very light layer, but it's yet another
layer. To put it between parrot and hardware would mean that parrot is JITing
to LLVM byte-code, which is JITing to machine code. Not re
I was looking over an example of named parameter passing:
foo(:a<1>, :b<2>)
And had the thought that we might be able to get away with treating
named parameters as lvalues, making the above:
foo(:a=1, :b=2)
Would this be unreasonable? Does it break anything else? I'm not sure
Jonathan Scott Duff wrote:
On Wed, Sep 13, 2006 at 10:20:31AM +1200, Sam Vilain wrote:
Larry Wall wrote:
.META is more correct at the moment.
Does making it all upper caps really help? It's still a pollution of the
method space, any way that you look at it...
Yeah but perl has already h
David Brunton wrote:
Aaron Sherman wrote:
IMHO, the golden rule of programming languages should be: if you
need a namespace, create one.
Is there any reason these "meta" methods could not be part of some
default function package like Math::Basic and Math::Trig? The
packag
I didn't see this going back, sorry if I missed someone sending the mail.
There was a discussion on IRC on Sept 9th about the -X filetest
operators between at least audreyt, Juerd, myself and markstos. The
problem with these operators was that they conflicted in some cases with
the parsing of
What happens to a program that creates a thread with a shared variable
between it and the parent, and then the parent modifies the class from
which the variable derives? Does the shared variable pick up the type
change? Does the thread see this change?
Smylers wrote:
Randal L. Schwartz writes:
"Smylers" == Smylers <[EMAIL PROTECTED]> writes:
Smylers> No: no aliases. Perl does not have a tradition of these,
except "for"/"foreach". :)
I don't reckon one instance is enough to be labelled a tradition!
(Um ... actually I forgot about that o
Mark J. Reed wrote:
(by the way, newbies don't use grep because list transforms confuse and
intimidate, not because of the name).
I dispute that. List transforms and grep are wholly separate beast,
This was a minor side-comment. Let's stay focused and not rat-hole on
our respective definiti
Jonathan Lang wrote:
Larry Wall wrote:
Mark J. Reed wrote:
: I have no horse in this race. My personal preference would be to
: leave grep as "grep". My second choice is "select", which to me is
: more descriptive than "filter"; it also readily suggests an antonym of
: "reject" to do a "grep -
Michael Snoyman wrote:
I just recently got interested in Perl 6 (within the past two
months), and I found that reading the book was a good kick-start.
Sure, lots of stuff has changed, but many of the general ideas still
seem to hold true.
Yes, the book is still an OK primer on the high-level co
Damian Conway wrote:
In other words, classify() takes a list of values, examines each in
turn, and ascribes a "label" value to it. The call returns a list of
pairs, where each pair key is one of the label values and each pair
value is an array of all the list values that were ascribed that labe
[EMAIL PROTECTED] wrote:
I still don't think we have a consensus that grep needs to be renamed,
much less what it should be renamed to. To me, "keep" implies throwing
the rest away,I.e., modifying the list. "Select" has the advantage of
lacking that connotation. To avoid dissonance with the two
Trey Harris wrote:
Might I propose the following normalization:
1. .call, method definition call(), and .wrap call all take captures.
2. .call() and both types of call() all pass on the arguments of the
current subroutine.
> 3. To call with no arguments, use .call(\()) and call(\()).
I
Larry Wall wrote:
On Wed, Sep 20, 2006 at 11:18:09AM -0400, Aaron Sherman wrote:
: Trey Harris wrote:
: >Might I propose the following normalization:
: >
: >1. .call, method definition call(), and .wrap call all take captures.
:
: >2. .call() and both types of call() all pass on t
Larry Wall wrote:
Okay, I think this is worth bringing up to the top level.
Fact: Captures seem to be turning into a first-class data structure
that can represent:
argument lists
match results
XML nodes
anything that requires all of $, @, and % bits.
This is quite true, and wo
Larry Wall wrote:
On Wed, Sep 20, 2006 at 05:18:12PM -0400, Aaron Sherman wrote:
: For this reason, I'd suggest putting away the Latin-1 glyphset and
: instead focusing on developing operators to act on containers with
: multiple access methods and their expanded forms.
There'
[EMAIL PROTECTED] wrote:
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 10 Aug 2004
- Last Modified: 18 Sept 2006
+ Last Modified: 20 Sept 2006
Number: 2
- Version: 69
+ Version: 70
+| capture/arguments/match
+|$args; # all of the above
I'll read that as
Mark J. Reed wrote:
Ok, I dkimmed through the synopses again and didn't see this offhand.
If I have two arrays @a and @b and I wish to create a two-element list
out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the
correct way to do
that in Perl6? If it's still ([EMAIL
All sounds good up to:
Larry Wall wrote:
The cultural ambiguity is also being reduced insofar as we're trying
to discourage use of bare constants in favor of sigilled constants.
If you see a bare function name you should generally assume it
has arguments in Perl 6.
Well, in that case, should
Jonathan Lang wrote:
Larry Wall wrote:
You don't need to use | to store a capture any more than you need @ to
store an array. Just as
$x = @b;
@$x;
gives you the original array,
Huh. I'm not used to this happening. So what would the following
code do, and why?
my @b = ('foo',
Carried over form IRC to placeholder the conversation as I saw it:
We define the following in S06 as immutable types:
ListLazy Perl list (composed of Seq and Range parts)
Seq Completely evaluated (hence immutable) sequence
Range Incrementally generated (hence la
Larry Wall wrote:
On Mon, Sep 25, 2006 at 09:02:56PM -0500, Mark Stosberg wrote:
:
: eval($yaml, :lang);
:
: Still, these options may not substitute for the kind of role-based
: solution you have mind.
I'm not sure it's wise to overload eval this way. Seems like a
great way to defeat MMD. P
Executive summary:
I suggest a signature prototype that all multis defined in or exported
to the current namespace must match (they match if the proto would allow
the same argument list as the multi, though the multi may be more
specific). Prototypes are exportable. Documentation tie-ins are a
Trey Harris wrote:
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes:
Any thoughts?
I'm still thinking about the practical implications of this... but
what immediately occurs to me:
The point of multiple, as opposed to single, dispatch (well, one of
the points, and the only
TSa wrote:
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe
that declarative requirements should go on roles. And then packages
could do them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the
Jonathan Lang wrote:
Aaron Sherman wrote:
TSa wrote:
> Miroslav Silovic wrote:
>> package Foo does FooMultiPrototypes {
>> ...
>> }
>
> I like this idea because it makes roles the central bearer of type
> information.
Type information is secondary to the propos
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate file - quite likely one heavily laced with
>
Jonathan Lang wrote:
I hope not. My understanding is that '{ ... }' is supposed to
represent the notion of abstract routines: if you compose a role that
has such routines into a class or package, I'd expect the package to
complain bitterly if any such routines are left with yada-yadas as
their c
Trey Harris wrote:
In a message dated Fri, 29 Sep 2006, Aaron Sherman writes:
That said, this is a different point, above and I think it's an easy
one to take on.
role A { method x() {...} }
class B { does A; }
does generate an error per "If a role merely declares methods without
Jonathan Lang wrote:
I'm not used to programming styles where a programmer intentionally
and explicitly forbids the use of otherwise perfectly legal code. Is
there really a market for this sort of thing?
use strict;
chromatic wrote:
On Monday 02 October 2006 12:32, Jonathan Lang wrote:
Before we start talking about how such a thing might be implemented,
I'd like to see a solid argument in favor of implementing it at all.
What benefit can be derived by letting a module specify additional
strictures for its
Trey Harris wrote:
In a message dated Fri, 1 Sep 2006, jerry gay writes:
On 9/1/06, Trey Harris <[EMAIL PROTECTED]> wrote:
In a message dated Fri, 1 Sep 2006, Paul Seamons writes:
> I'm not sure if I have seen this requested or discussed.
This was definitively rejected by Larry in 2002:
p
Paul Seamons wrote:
Of course, that wasn't exactly what you were asking, but it does present
a practical solution when you want to:
{say $_ for =<>}.() if $do_read_input;
Which I just verified works fine under current pugs.
Thank you.
Hadn't thought of that. I think that is workable
xamples/pge/wikipedia/README (revision 0)
+++ examples/pge/wikipedia/README (revision 0)
@@ -0,0 +1,13 @@
+This directory contains a very crude example parser that reads a fixed string
+"1+(1+1)" and produces a parse tree. The parser itself is used as an example
+in the Wikipedia article:
+
Paul Seamons wrote:
It relates to some old problems in the early part of the RFC/Apocalypse
process, and the fact that:
say $_ for 1..10 for 1..10
Was ambiguous. The bottom line was that you needed to define your
parameter name for that to work, and defining a parameter name on a
modifi
Markus Triska wrote:
Aaron Sherman writes:
+Written in 2006 by Aaron Sherman, and distrbuted
Typo: distributed
You are correct, sir.
This was not, in fact some strange attempt to seize control of the
Parrot codebase ;)
chromatic wrote:
On Thursday 28 September 2006 14:51, Markus Triska wrote:
Allison Randal writes:
mini transformation language to use in the compiler tools.
For what purpose, roughly? I've some experience with rule-based
peep-hole optimisations. If it's in that area, I volunteer.
That's par
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
my $i = 0;
class A { method inci() { die if $i
Aaron Sherman wrote:
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
Corrected example follows (there
I'm noodling around with the idea of creating an archive and index of
all of the messages to the mailing list over the years for purposes of
quickly finding all of the messages that have definitive information on
a given topic. Simply searching on Google or through my mail spool just
doesn't cu
Trey Harris wrote:
I read it as "yes, you *can* put strictures on the using code into a
library, though I wouldn't do it and would say that any module that does
so shouldn't be released on CPAN for general use. ..."
Hey, I have an idea. Let's write a module that enforces that!
Seriously, I t
S04 now reads:
==
However, a hash composer may never occur at the end of a line. If the
parser sees anything that looks like a hash composer at the end of
the line, it fails with "closing hash curly may not terminate line"
or some such.
my $hash = {
1 => { 2 => 3, 4 => 5 },
Jonathan Lang wrote:
What if I import two modules, both of which export a 'foo' method?
That's always fine unless they have exactly the same signature. In
general, that's not going to happen because the first parameter is
created from the invocant. Thus:
use HTML4;
use Math:
Aaron Sherman wrote:
Proposal: A sigil followed by [...] is always a composer for that type.
%[...]- Hash. Unicode: ⦃...⦄
@[...]- Array. Unicode: [...]
...
I left out ::, which is probably a mistake. Part of the elegance of
this, IMHO, is that it behaves the same for all
Mark J. Reed wrote:
On 10/5/06, Aaron Sherman <[EMAIL PROTECTED]> wrote:
Proposal: A sigil followed by [...] is always a composer for that type.
%[...] - Hash. Unicode: ⦃...⦄
@[...] - Array. Unicode: [...]
? - Seq. Unicode: ⎣...⎤
&[...] - Cod
Aaron Sherman wrote:
(updated based on followup conversations)
Proposal: A sigil followed by [...] is always a composer for that type.
%[...]- Hash.
@[...]- Array.
&[...]- Code.
|[...]- Capture. Identical to \(...).
$[...]- Scalar. Like item(...),
The example in S05 under "Subpattern numbering" isn't quite complex
enough to give the reader a full understanding of the ramifications of
the re-numbering that occurs with alternations, especially with respect
to the combination of capturing and non-capturing subpatterns. I've
written a small
@larry[0] wrote:
Log:
P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"
Wow, I really missed this one! That's a pretty big thing to get my head
around. Are embedded closures in the string handled correctly so that:
s:g[\W] = qq{\\{$/}};
Will do what I seem to be expecting i
Hey there, sorry about not responding. My mailer hid this message from
me. I was actually about to reply asking what the deal was. ;)
chromatic wrote:
On Tuesday 03 October 2006 13:41, Aaron Sherman wrote:
This contains the Makefile, README, .pg grammar, a -harness.pir that
executes the
Ovid wrote:
The "intermediate class" solves the problem but it instantly suggests
that we have a new "design pattern" we have to remember. Basically, if
I can't lexically scope the additional behavior a role offers, I
potentially need to remove the role or use the "intermediate class"
pattern.
Larry discounted RFC261 in A5, but I think there's some good in it. The
biggest problem is not that it's hard to do in Perl6, but that 80-90% of
it is ALREADY done in Perl5! Once you peel away that portion of the RFC,
you get to Perl5's limitations and what Perl6 might do to support these
things.
On Mon, 2002-06-17 at 16:10, Luke Palmer wrote:
> > So, in order for me to avoid learning Java, I propose
> > that a CPAN "Curation Project", or an Extended
> > Standard Perl Library", be formed.
>
> Or, Standard Extended Library of Perl. SELP is more pronouncable than
> ESPL. SELF is bette
ing and we'll
be fine (or was that X.500... which one was the funky LDAP-like ugly-as-sin
thing the Europeans (i.e. ISO) tried to pretend was better than
Internet-style addressing because it allowed you to route mail based on how
much fiber the recipient had in their diet?)
--
Aaro
On Fri, 2002-07-12 at 02:33, Sean O'Rourke wrote:
> What's currently "supported":
> - if/elsif/else (even "unless" and the feared "elsunless";)
When we talked about this last, I had been concerned about loops and
conditionals, but others had scoping concerns. Ok, perhaps there's no
way we can r
On Fri, 2002-07-12 at 13:22, Thomas A. Boyer wrote:
> Aaron Sherman wrote:
> > An example:
> >
> > $pid = fork() // -1;
> > if $pid < 0 {
> > # error ...
> > } else unless $pid {
> > # Parent
> > }
On Mon, 2002-07-15 at 11:29, Karl Glazebrook wrote:
> complex formulae. Imagine:
>
> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>
> (or would it be ^sqrt() ?) - This looks like sendmail :-)
I would imagine that non-binary operators would simply have a hyper-form
(which could
On Mon, 2002-07-22 at 04:36, [EMAIL PROTECTED] wrote:
> > Now, I ask for PMC programmers to take care implementing this! Notice
> > that, for example in arrays, arrays with the same length but different
> > elements should return different hash codes (or try). But for the same
> > elements MUST r
On Wed, 2002-07-24 at 12:34, Fisher Mark wrote:
> > But then sometimes you'd *want* hashing to be based on the
> > content.
>
> OK, I'll bite -- when would you want this behavior? This behavior means
> that once you change the contents, the hash value would become irretrievable
> unless you rest
I had assumed Perl6 will have copy-on-write references, so that
$x = [1,2,3];
@y = *$x;
would not require a copy. However, on thinking about it further, I
realized that that would get you in trouble here:
$x = [1,2,3];
%h{$x} = 1;
@y = *x;
$x[0]++;
print %h{$x};
Thi
On Thu, 2002-07-25 at 03:12, [EMAIL PROTECTED] wrote:
> Aaron Sherman <[EMAIL PROTECTED]> writes:
> > my @x is Hashed::ByValues = (1,2,3);
> > %h = (@x => 1);
> > @x[1] += 4;
>
> Personally I don't like the C< is Hashed::ByValues > bec
On Fri, 2002-08-16 at 19:05, [EMAIL PROTECTED] wrote:
> On Fri, 16 August 2002, Luke Palmer wrote:
>
> > I want superpositions too :). But, what would this mean?
> >
> > my all(str, int) $foo;
> > #...
>
> That you need some *serious* psychotherapy! ;-)
>
> Actually, it would mean tha
I just wrote this code in Perl5:
$stuff = (defined($1)?$1:$2) if /^\s*(?:"(.*?)"|(\S+))/;
This is a common practice for me when I parse configuration and data
files whose formats I define. It's nice to be able to quote fields that
have spaces, and this is an easy way to parse the result.
In
On Wed, 2002-08-28 at 03:23, Trey Harris wrote:
> Note--no parens around $field. We're not "capturing" here, not in the
> Perl 5 sense, anyway.
>
> When a pattern consisting of only a named rule invokation (possibly
> quantified) matches, it returns the result object, which in boolean
> context
On Thu, 2002-08-29 at 08:05, Ken Fox wrote:
> A question: Do rules matched in a { code } block set backtrack points for
> the outer rule? For example, are these rules equivalent?
>
> rule expr1 {
> { /@operators/ or fail }
> }
>
> rule expr2 {
> @operators
> }
>
> And a comm
On Thu, 2002-08-29 at 10:28, Ken Fox wrote:
> Aaron Sherman wrote:
> > rule { { /@operators/.commit(1) or fail } }
> >
> > The hypothetical commit() method being one that would take a number and
>
> That would only be useful if the outer rule can backtrack i
[NOTE: BCCing off-list to protect private email addresses]
On Fri, 2002-08-30 at 09:07, Ken Fox wrote:
> Does the following example backtrack into ?
>
>rule foo { b+ }
>rule bar { a b }
This was the bit that got me on-board. I did not see the need for
backtracking into rules until he
Is C<\n> going to be a rule (e.g. C<< >>) or is it implicitly
translated to:
<[\x0a\x0d...]>+
If it's the latter, then what does this do?
\n?
Do I get
[<[\x0a\x0d...]>+]?
Or do I get
<[\x0a\x0d...]>+?
If the former (which I assume is the case), how do I get
On Sat, 2002-08-31 at 07:07, Damian Conway wrote:
> Aaron Sherman wrote:
>
> > Is C<\n> going to be a rule (e.g. C<< >>)
>
> There might be an named rule like that. But C<\n> will certainly
> still be available.
>
> > or is it implicitl
I'm working on a library of rules and subroutines for dealing with UNIX
system files. This is really just a mental exercise to help me grasp the
new pattern stuff from A5.
I've hit a snag, though, on hypothetical variables. How would this code
work?
{
my $x = 2;
my $y = "Th
On Mon, 2002-09-02 at 23:50, Trey Harris wrote:
> No. $0{x} would be set to "grass". $x would stay as 2. $x is in a
> different scope from the hypothetical, so it doesn't get touched.
Ok, it's just taking some time for me to get my head around just what
C and C are, but I'm getting there. Thi
On Tue, 2002-09-03 at 11:35, Ken Fox wrote:
> Peter Haworth wrote:
> > Also the different operators used (:= inside the rule, = inside the code)
> > seems a bit confusing to me; I can't see that they're really doing anything
> > different:
> >
> > / $x := (gr\w+) /vs/ (gr\w+) { let $
On Tue, 2002-09-03 at 17:03, Sean O'Rourke wrote:
> On Tue, 3 Sep 2002, Markus Laire wrote:
> > Would it be possible to rename "perl6-internals" now to something
> > better like "parrot-internals"?
>
> I think aliases can take care of this, though I'm not the sysadmin.
> Maybe it makes people fe
1 - 100 of 761 matches
Mail list logo
