On 11/23/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> Basically, we're attaching the whole lazy/nonlazy mess to the
> list/scalar distincion, which I think is a really good default.
> We use ** and lazy() to violate those defaults.
I think you might be mixing up the "scope" of laziness here. Havin
On 11/23/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> : I'm also puzzled that you feel the need to write 0..$n-1 so often; there
> : are so many alternatives to fenceposting in P5 that I almost never write
> : an expression like that, so why is it cropping up that much in P6?
>
> Couple reasons occu
On 11/23/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote:
> How about allowing reduce() to return a scalar with the same laziness
> as the list:
>
> [EMAIL PROTECTED] - a lazy string if @list is lazy
> [EMAIL PROTECTED] - a lazy number if @list is lazy
>
> It would look like:
>
> $foo = s
Juerd skribis 2005-11-24 0:39 (+0100):
> Personally, I think even ^.., ^..^ and ..^ are too much, but that I can
> live with.
For the record, I don't want to die if ^ is introduced. If it's there,
I'll use it. If using [EMAIL PROTECTED] becomes accepted style, I'll use it.
The "live with" isn't
Larry Wall skribis 2005-11-23 13:10 (-0800):
> : It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n.
> But then you'd usually want 1..$n instead...
I think this illustrates very well that it's a bit silly to have a
shortcut for just one of the three much-used ranges. My view
Larry Wall a écrit :
| On Wed, Nov 23, 2005 at 07:10:39PM +0100, Juerd wrote:
| : Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
| : > > Doesn't ^5 encourage [EMAIL PROTECTED] too much?
| : > Can you explain when that creates a problem?
| :
| : It's not about problems in execution, it's about
On Wed, Nov 23, 2005 at 08:04:32AM -0800, Peter Scott wrote:
: On Tue, 22 Nov 2005 14:34:12 -0800, Larry Wall wrote:
: > What tipped me over the edge, however, is that I want ^$x back for a unary
: > operator that is short for 0..^$x, that is, the range from 0 to $x - 1. I
: > kept wanting such an
On Tue, 22 Nov 2005 14:34:12 -0800, Larry Wall wrote:
> What tipped me over the edge, however, is that I want ^$x back for a unary
> operator that is short for 0..^$x, that is, the range from 0 to $x - 1. I
> kept wanting such an operator in revising S09. It also makes it easy to
> write
>
>
2005/11/23, Larry Wall <[EMAIL PROTECTED]>:
>
> I think the last one is more feasible than the middle one, at least
> by default. The problem is that stringification is considered a result
> of a kind of scalar context, and ordinary scalar context is not lazy
> in Perl 6. So we'd probably need to
Larry Wall:
> I can see the mathematical appeal of coming up with a language in
> which there is a meaning for every possible combination of tokens.
Yes, that sounds like my language. I agree it's not Perl. And not a lot
of other things too.
> It's a counterintuitive fact
> that languages that
On Wed, Nov 23, 2005 at 02:21:15PM -0500, Matt Fowles wrote:
: I like C< ..^5 > better than C< ^5 > actually. I was going for the
: rule that an omitted LHS was 0 and an omitted RHS was infinity (your
: probably cannot omit both).
But that only saves you 1 keystroke, and eliminates unary .. for a
On Wed, Nov 23, 2005 at 08:35:09PM +0100, Juerd wrote:
: Larry Wall skribis 2005-11-23 11:16 (-0800):
: > Range objects are supposed to *be* iterators, but pugs isn't there yet,
: > last I checked.
:
: Is the associated sigil @ or $? Either way, there's a problem.
No, either way it does what you
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> One of the other reasons I like ^5 is that the uparrowness of it
LW> naturally reads as "up to 5". But for containers we could certainly
LW> abstract it out to the domain.
it also harkens back to apl's iota op which did similar thing
On Wed, Nov 23, 2005 at 05:24:11PM -0200, Flavio S. Glock wrote:
: Ah, ok - but I believe that say() is slurpy, which means the list must
: be instantiated first.
It's * instantiated, but not ** instantiated, so the iterators buried
in the .specs of the list aren't forced to evaluate yet. And ran
Larry Wall skribis 2005-11-23 11:16 (-0800):
> Range objects are supposed to *be* iterators, but pugs isn't there yet,
> last I checked.
Is the associated sigil @ or $? Either way, there's a problem. $foo
can't flatten in list context, which .. does want, which would be
inconsistent, but with @, i
Juerd:
2005/11/23, Juerd <[EMAIL PROTECTED]>:
> Flavio S. Glock skribis 2005-11-23 10:13 (-0200):
> > Can we have:
> > say 1..Inf;
>
> It's important, I think, to note that this isn't item context, but list
> context. Str list context, but still list context. Which means 1..Inf
> isn't stringifi
Larry~
On 11/23/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 23, 2005 at 11:55:35AM -0500, Matt Fowles wrote:
> : I think using C< ..5 > to mean (0, 1, 2, 3, 4) would be a more
> : sensible option. Makes sense to me at least.
>
> That doesn't derive well from any of:
>
> ..
> ^
On Wed, Nov 23, 2005 at 12:07:08PM -0500, Rob Kinyon wrote:
: On 11/23/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote:
: > OTOH, it would be nice if
: >
: > say substr( ~(1..Inf), 0, 10 )
: >
: > printed "1 2 3 4 5".
: This would work, I think, if ranges were convertable to iterators,
Range obje
On Wed, Nov 23, 2005 at 10:58:53AM -0800, Larry Wall wrote:
: Well, as I said in my other reply, that's not a big problem for
: 1-dimensional arrays. But it does possibly make sense that ^ on a
: multidimensional array or hash would return a zip of all the key sets.
: Plus it generalizes ^%hash to
On Wed, Nov 23, 2005 at 10:45:21AM -0800, Mark A. Biggar wrote:
: Actually I like that and think that ^$x should be 0..($x-1) and that
: [EMAIL PROTECTED] should be define to return the array's index set (usually
: 0..$#foo) but maybe something else for a non-zero based array.
Well, as I said in
On Wed, Nov 23, 2005 at 07:10:39PM +0100, Juerd wrote:
: Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
: > > Doesn't ^5 encourage [EMAIL PROTECTED] too much?
: > Can you explain when that creates a problem?
:
: It's not about problems in execution, it's about expression.
:
: [EMAIL PROTECTE
Juerd wrote:
Rob Kinyon skribis 2005-11-23 11:58 (-0500):
I don't use 0..$n-1 very often. I use 0..$#arr most often.
Good point. Doesn't ^5 encourage [EMAIL PROTECTED] too much? After all, we
should
write what we mean, instead of something that happens to evaluate to the
same list. We mean
Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
> > Doesn't ^5 encourage [EMAIL PROTECTED] too much?
> Can you explain when that creates a problem?
It's not about problems in execution, it's about expression.
[EMAIL PROTECTED] returns the *number of elements*, not the index of the last
elemen
Juerd:
> Doesn't ^5 encourage [EMAIL PROTECTED] too much?
Can you explain when that creates a problem?
Maybe someone doing
for ([EMAIL PROTECTED])->$i { say @foo[$i] }
in stead of
say for @foo
> After all, we should
> write what we mean, instead of something that happens
> to evaluate to t
Larry Wall wrote:
On Wed, Nov 23, 2005 at 06:21:56PM +0100, Juerd wrote:
: Larry Wall skribis 2005-11-23 9:19 (-0800):
: > ^5.each { say }
:
: Without colon?
Yeah, that one doesn't work a couple of way. Unfortunately .each still
binds tighter than ^ too. So it'd have to be:
(^5).ea
Flavio S. Glock skribis 2005-11-23 10:13 (-0200):
> Can we have:
> say 1..Inf;
It's important, I think, to note that this isn't item context, but list
context. Str list context, but still list context. Which means 1..Inf
isn't stringified as a whole. &say will have an array that represents
the l
On Wed, Nov 23, 2005 at 06:21:56PM +0100, Juerd wrote:
: Larry Wall skribis 2005-11-23 9:19 (-0800):
: > ^5.each { say }
:
: Without colon?
Yeah, that one doesn't work a couple of way. Unfortunately .each still
binds tighter than ^ too. So it'd have to be:
(^5).each: { say }
unless w
On Wed, Nov 23, 2005 at 11:55:35AM -0500, Matt Fowles wrote:
: I think using C< ..5 > to mean (0, 1, 2, 3, 4) would be a more
: sensible option. Makes sense to me at least.
That doesn't derive well from any of:
..
^..
..^
^..^
If the rule is "you can omit the 0", then it's ..^5
On Wed, Nov 23, 2005 at 11:58:23AM -0500, Rob Kinyon wrote:
: Here's an issue - if ^$x would be one($x), then what will [EMAIL PROTECTED]
be? To
: me, that seems like it should be one(@x), which is entirely useful.
: Except, if I try and use it as [EMAIL PROTECTED] (which, to me, would be
useful)
Larry Wall skribis 2005-11-23 9:19 (-0800):
> ^5.each { say }
Without colon?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
On Wed, Nov 23, 2005 at 02:23:51PM +0100, Ruud H.G. van Tol wrote:
: Larry Wall:
:
: > for ^5 { say } # 0, 1, 2, 3, 4
:
: The 'for' can go if a list (and also an array) would imply looping, when
: it is positioned next to a block:
:
: a. say (0..4);
: b. { say; say } (0..4);
: c. (0..4)
Ruud H.G. van Tol:
> b. { say; say } (0..4);
>
> b. now produces 2 lines with 01234 (in pugs). With implied looping
> that would be 10 lines, starting with two 0-lines.
Standard:
do {say; say} for 0..4
for 0..4 {say; say}
Wishful:
(0..4) »{say; say}
pugs doesn't seem to do the
("f","o
On 11/23/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote:
> Can we have:
>
> say 1..Inf;
>
> to output an infinite stream, instead of just looping forever?
>
> OTOH, it would be nice if
>
> say substr( ~(1..Inf), 0, 10 )
>
> printed "1 2 3 4 5".
>
> Flattened lists would still loop forever (or fa
Rob Kinyon skribis 2005-11-23 11:58 (-0500):
> I don't use 0..$n-1 very often. I use 0..$#arr most often.
Good point. Doesn't ^5 encourage [EMAIL PROTECTED] too much? After all, we
should
write what we mean, instead of something that happens to evaluate to the
same list. We mean to use indexes,
Matt Fowles skribis 2005-11-23 11:55 (-0500):
> I think using C< ..5 > to mean (0, 1, 2, 3, 4) would be a more
> sensible option. Makes sense to me at least.
.. as a unary is uncomfortable, because of the different whitespace
styles people use with this operator. I personally use both "0..15"
an
On 11/23/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 11/23/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> > On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> > >
> > > for ^5 { say } # 0, 1, 2, 3, 4
> >
> > I read this and I'm trying to figure out why P6 needs a unary operator
> > for some
Luke~
On 11/23/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 11/23/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> > On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> > >
> > > for ^5 { say } # 0, 1, 2, 3, 4
> >
> > I read this and I'm trying to figure out why P6 needs a unary operator
> > f
On 11/23/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
>
> > On 11/22/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> >
> >> :syntax
> >> :syntax
> >> :syntax
> >> :syntax
> >> :syntax
> >> :syntax
> >
> >
> > Aren't we providing an interface to define your own r
On Wed, 23 Nov 2005, Ruud H.G. van Tol wrote:
for ^5 { say } # 0, 1, 2, 3, 4
The 'for' can go if a list (and also an array) would imply looping, when
it is positioned next to a block:
a. say (0..4);
b. { say; say } (0..4);
I'm not really sure: while I like it for its conciseness -and
Larry Wall:
> for ^5 { say } # 0, 1, 2, 3, 4
The 'for' can go if a list (and also an array) would imply looping, when
it is positioned next to a block:
a. say (0..4);
b. { say; say } (0..4);
c. (0..4) { say; say }
d. @{0..4} { say; say }
(etc.)
b. now produces 2 lines with 01234 (in p
Can we have:
say 1..Inf;
to output an infinite stream, instead of just looping forever?
OTOH, it would be nice if
say substr( ~(1..Inf), 0, 10 )
printed "1 2 3 4 5".
Flattened lists would still loop forever (or fail):
say **(1..Inf);
$s = substr( ~( **(1..Inf) ), 0, 10 );
- Flavio
On Nov 23, 2005, at 3:06, chromatic wrote:
On Wed, 2005-11-23 at 01:39 +0100, Leopold Toetsch wrote:
But my argument was: whenever you
start introspecting a call frame, by almost whatever means, this will
keep the call frame alive[1] (see Continuation or Closure). That is:
timely destruction
Luke wrote:
On 11/22/05, Damian Conway <[EMAIL PROTECTED]> wrote:
:syntax
:syntax
:syntax
:syntax
:syntax
:syntax
Aren't we providing an interface to define your own regex modifiers?
Sure. But it'd lead to much less namespace pollution and much greater
readabilit
On 11/22/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> :syntax
> :syntax
> :syntax
> :syntax
> :syntax
> :syntax
Aren't we providing an interface to define your own regex modifiers?
All of these can easily be mapped into Perl 6 patterns, so...
Modules welcome! ;-)
On 11/23/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> >
> > for ^5 { say } # 0, 1, 2, 3, 4
>
> I read this and I'm trying to figure out why P6 needs a unary operator
> for something that is an additional character written the more legible
> w
Larry wrote:
> But the language in the following lexical scope is a constant, so what can
> :syntax($foo) possibly mean? [Wait, this is Damian I'm talking to.]
> Nevermind, don't answer that...
Too late! ;-)
Regex syntaxes already are a twisty maze of variations, mostly alike. I
can easily env
46 matches
Mail list logo
