> I've been working at updating the various synopses on dev.perl.org.
> In particular, you folks might like to know that the regex synopsis at:
>
> http://dev.perl.org/perl6/synopsis/S05.html
>
> is no longer two years out of date :-)
>
> Larry
ok, cool, I'm beginning to understand perl6 pa
Edward Peschko writes:
> > I've been working at updating the various synopses on dev.perl.org.
> > In particular, you folks might like to know that the regex synopsis at:
> >
> > http://dev.perl.org/perl6/synopsis/S05.html
> >
> > is no longer two years out of date :-)
> >
> > Larry
>
> ok, c
On Thu, 16 Sep 2004, Jonathan Scott Duff wrote:
And FWIW, I kinda like $& even with the over-done & :-)
me too!
Michele
--
[...] is like requiring to play tennis with a square ball.
Which admittedly makes the game more interesting.
- Giuseppe "Oblomov" Bilotta in comp.text.tex (edited)
On Thu, 16 Sep 2004, Larry Wall wrote:
Except that only one of these variables' meanings is actually
associated with subs. And I kind of like to read the C as "which".
So if we actually make use of our sigils, we get possibilities like this:
[snip useful examples]
at first I didn't get what you me
On Fri, 17 Sep 2004, Larry Wall wrote:
with a named abstraction is not terribly useful. The "whichness"
of C happens subconsciously, whereas having a named hash forces
As I said in my other mail, the more I think of this the more it seems to
me to be reasonable and even "natural". It's "which?-ne
On Sat, 18 Sep 2004, Luke Palmer wrote:
Example above becomes:
sub MediansBy5 ([EMAIL PROTECTED]) {
while @list.length >= 5 {
emit (sort @list.splice(0,5))[2];
}}
That's actually a very good idea. That's why Perl 6 has it :-)
sub MediansBy5 ([EMAIL PROTECTED]) {
gather {
On Sat, 18 Sep 2004, Rod Adams wrote:
2. Should a subsequent implicit return behave differently than usual if
some values have already been emitted?
It seems clear to me that behind the scenes there should be a "stack" into
which Cted stuff is pushed and that this is returned upon either
explici
> # With the new :ov (:overlap) modifier, the current rule will match at all
> possible character positions (including overlapping) and return all matches
> in a list context, or a disjunction of matches in a scalar context. The
> first match at any position is returned.
>
> $str = "abracad
> > # With the new :ov (:overlap) modifier, the current rule will match at
> > all possible character positions (including overlapping) and return all
> > matches in a list context, or a disjunction of matches in a scalar
> > context. The first match at any position is returned.
> >
> > $str =
On Tue, 2004-09-21 at 02:52 -0600, Luke Palmer wrote:
> If you replace the first line:
>
> method Rule::Group::generate(Int $n) {
>
> With
>
> multi generate (Rule::Group $group: Int $n) {
>
> Everything ought still to work.
>
> I think the best you can do is to implement it as a routi
I fear, and with good reasons, that this may be too wild a case of an
extremization, but I wonder wether, just like for example strings are
implemented by means of special (quote-like) operators, sigils, instead of
being syntactical creatures could be (sort of special) operators
themselved and
On Tue, Sep 21, 2004 at 12:37:09PM +0200, Ph. Marek wrote:
> But that gets me to the next question, ie I don't understand the
> difference between exhaustive and overlap.
>
> Is it that overlap fixes the first point of the pattern match and does
> further scanning for all possibilities, and exhaust
On Tue, Sep 21, 2004 at 11:45:55AM +0200, Michele Dondi wrote:
: at first I didn't get what you mean, but now I must admit it does make
: sense and looks smart too.
I can be very persuasive when I'm right, as well as the rest of the time. :-)
Larry
On Tue, Sep 21, 2004 at 01:49:07PM +0200, Michele Dondi wrote:
: I fear, and with good reasons, that this may be too wild a case of an
: extremization, but I wonder wether, just like for example strings are
: implemented by means of special (quote-like) operators, sigils, instead of
: being synt
Now you're underusing smileys. I hope.
On Tue, 21 Sep 2004 12:04:01 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 21, 2004 at 01:49:07PM +0200, Michele Dondi wrote:
> : I fear, and with good reasons, that this may be too wild a case of an
> : extremization, but I wonder wether, just l
Larry Wall wrote:
Somebody needs to talk me out of using A..Z for the simple cases.
Larry
The Turing programming language uses splat to stand in for the length of
the array, so in Turing *a[*-1]* means what Perl 5 programmers mean when
they say *$a[-1]*.
However, splat is already quite heavil
John Macdonald <[EMAIL PROTECTED]> writes:
> If a int1 (or int2 or nybble or other sub-addressable sized value)
> is being referred to, a similar issue arises since most machines
> these days have byte addressing, but do not have bit addressing. If
> you can't refer directly to it, the value will
--- Jonadab the Unsightly One <[EMAIL PROTECTED]> wrote:
> I surely must be misunderstanding what you're saying... the way I
> read that, you're suggesting that it will matter to Perl -- not only
> to the compiler but even to user code -- how the underlying hardware
> addresses its memory. I real
Aaron Sherman <[EMAIL PROTECTED]> writes:
> It took us some time discussing this... we weren't sure what tense
> you were using. At first we thought it might be the past subjective,
> but after a while, we decided to coin a new tense: the vapor tense. ;-)
Actually, it's not new at all; there's al
Larry Wall <[EMAIL PROTECTED]> writes:
> int1, int2, int4, int8, int16, int32, int64, uint1, uint2, uint4,
> uint8, uint16, uint32, uint64, num32, num64, num128, complex32,
> complex64, complex128, ...
Well, all that is harmless enough, as long as I don't ever have the
misfortune to inherit maint
Edward Peschko writes:
> Ok, fair enough.. although I'm not sure that I'm all that sure I'm completely
> happy-with/understand the syntax described in that article. It works for the trivial
> cases, but what about complex grammars?
It works for anything. It gets pretty inefficient in the case o
Luke Palmer wrote:
Edward Peschko writes:
Ok, fair enough.. although I'm not sure that I'm all that sure I'm completely
happy-with/understand the syntax described in that article. It works for the trivial
cases, but what about complex grammars?
It works for anything. It gets pretty ineff
On Tuesday 21 September 2004 07:18 pm, Thomas A. Boyer wrote:
> Larry Wall wrote:
> >Somebody needs to talk me out of using A..Z for the simple cases.
> >
> >Larry
>
> [ <> for array dimension placeholder ]
> That might confuse users of languages that were not
> C-syntax-influenced, who think that
23 matches
Mail list logo
