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
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
way.
Huh?
On 11/22/05, Damian Conway [EMAIL PROTECTED] wrote:
:syntaxPOSIX
:syntaxgrep
:syntaxegrep
:syntaxvim
:syntaxSnobol
:syntaxGoogle
Aren't we providing an interface to define your own regex modifiers?
All of these can easily be mapped into Perl 6 patterns, so...
Luke wrote:
On 11/22/05, Damian Conway [EMAIL PROTECTED] wrote:
:syntaxPOSIX
:syntaxgrep
:syntaxegrep
:syntaxvim
:syntaxSnobol
:syntaxGoogle
Aren't we providing an interface to define your own regex modifiers?
Sure. But it'd lead to much less namespace pollution
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
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
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
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
On 11/23/05, Damian Conway [EMAIL PROTECTED] wrote:
Luke wrote:
On 11/22/05, Damian Conway [EMAIL PROTECTED] wrote:
:syntaxPOSIX
:syntaxgrep
:syntaxegrep
:syntaxvim
:syntaxSnobol
:syntaxGoogle
Aren't we providing an interface to define your own regex
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
for something that is
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,
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 fail):
say
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
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)
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 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
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
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
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:
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 the
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
element
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 PROTECTED]
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
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
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 objects are
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:
..
^..
..^
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 stringified as a
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 @, it
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
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 things. iota is
an
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
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 any
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.g
It's a counterintuitive fact
that languages that
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 set
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
for
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
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
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
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 to
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 = substr(
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 occur to
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. Having a
42 matches
Mail list logo
