:syntax (was: \x{123a 123b 123c})
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 envisage Perl users occasionally needing/wanting/using
patterns which are any of:
:syntaxPOSIX
:syntaxgrep
:syntaxegrep
:syntaxvim
:syntaxSnobol
:syntaxGoogle
Not just because people are used to different syntaxes, but also because
programs will want to accept search patterns in different (generally: more
restrictive) syntaxes so as to be able to interpolate them safely:
use Regex::Google;
for = :promptFind: - $search {
for @texts {
say if m:syntaxGoogle/$search/;
}
}
And there aren't that many regexish languages anyway.
That depends on how broadly you define regexish. Search is a *very* common
activity and people are (re-)inventing notations for it all the time.
Damian
Re: type sigils redux, and new unary ^ operator
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? Are you saying that 0..^5 is one more character than ^5?
In any case, I'm not sure that this unary helps readability, or that I
like it all that much, but I can say that it's damned useful. I use
ranges of the form 0..$n-1 more than any other range, by a very long
shot.
To me, ^ indicates XOR, so unary ^ should really be the bit-flip
of the operand.
Except in Perl 6, XOR is spelled +^ or ~^, and ^ is Junctive one().
So it seems that ^$x should be one($x). But that's an entirely
useless, trivial junction, so it makes sense to steal the syntax for
something else.
Luke
Re: :syntax (was: \x{123a 123b 123c})
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... Modules welcome! ;-) Luke
Re: :syntax
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 and much greater readability if there were only one standard modifier that subsumed all future possibilities. Damian
Re: Perl 6 Summary for 2005-11-14 through 2005-11-21
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 doesn't work for example... Destruction or finalization? We don't have these two separated yet, but it wouldn't matter. Both can only happen after the GC has decided that the object is unreferenced. That is, if I have a filehandle I really want to close at the end of a scope but I don't care when GC drags it into the void, will the close happen even if there's introspection somewhere? *If* introspection sets the life bit (increments refcount) of the refered item(s) then destruction/finalization can only happen, after that introspection object is also dead. It's the same as: when you store a filehandle into an array, the filehandle will be bound to the life period of that array. The problem now is that there isn't any guarantee that such an introspection PMC stays in that call frame, the function could just return it to the caller (or store it into globals) as any other PMC. Which implies that the whole call chain (with its contents) would have to be kept alive. -- c leo
Lazy lists in Str context
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 S. Glock
implied looping (was: Re: type sigils redux, and new unary ^ operator)
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 pugs). With implied looping that
would be 10 lines, starting with two 0-lines.
--
Grtz, Ruud
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
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 in
particular I've often desired a very short, but clear, way to say: do
this #n times- IIUC (Perl6 new rules for blocks/closures and
dereferencing) this is only one dot or even whitespace away from passing a
list into an anonymous sub. Which may be confusing after all...
The problem (if any!) does not persist for the postponed block form. But
as far as code like
^5 { do_it };
is concerned, it is even _too_ concise, and I'd prefer some additional
syntactical indication about what's going on. For my tastes,
^5: { do_it }; # But then also 5: { do_it }; [*]
would be perfect, were not the colon already taken for a bazillion other
uses...
OTOH if I remember correctly there should be (provision for) a Cxx
variant that takes a closure and executes it over and over again.
[*] Or 5 - { do_it }; but I strongly suspect this would interfere with
pointy subs.
Michele
--
I am a deeply religious nonbeliever.
This is a somewhat new kind of religion.
- Albert Einstein
Re: :syntax
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 modifiers? Sure. But it'd lead to much less namespace pollution and much greater readability if there were only one standard modifier that subsumed all future possibilities. Okay, I don't think this is an important part of the design of the language, so I'll not fuss over it. However, I think it's a good case study that covers some important issues. Something I've learned from Haskell: if you have the following three things: * Fine-grained control over your lexical environment * A compiler that tells you when you're referring to something ambiguously, rather than just having one symbol hide the other * A way in all cases to refer to an export that you have *not* imported, using some fully-qualified form Then namespace pollution is not an issue... at all. I don't believe we have the last of those for regex modifiers. We should get it. Now, by grouping all these different modules under a standard :syntax, the following things follow: * The string has to be evaluated at compile-time; i.e. $syn = vim; rx:syntax($syn)/.../ is not legal. It takes a fair amount of maturity in the workings of Perl to understand why that doesn't work. * Various :syntax modifiers will probably do very different things inside the regex (one approach is not likely to work for everyone), so our common interface will add little to nothing over the standard modifier interface, other than another name to sift through in the docs. * We have to provide our own registry for these, which map strings onto implementations, rather than using the already existing symbol table. By reinventing this registry, we lose fully-qualified referrability to these symbols, which was one of the requirements for avoiding namespace pollution. It seems we've made that problem worse... but see below: :-) * The :syntax modifiers cannot take arguments, further worsening the namespace pollution problem rather than helping it. Or... if they can take arguments, it would be like this: :syntax['POSIX', :charclasses], which means reinventing the calling conventions already in place in much of the language (and losing some features in the process of reinventing, as usual), and losing any type information in the process. Also it's butt ugly. So... those have some strong language in there. I don't really want to go back and sugar them up, but pretend I did. Anyway, I think the biggest point is that when you substitute a string for a first-class object, you have to emulate (poorly) all the fancy mechanisms that the language designers have meticulously crafted. Luke
Re: type sigils redux, and new unary ^ operator
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 an additional character written the more legible
way.
Huh? Are you saying that 0..^5 is one more character than ^5?
In any case, I'm not sure that this unary helps readability, or that I
like it all that much, but I can say that it's damned useful. I use
ranges of the form 0..$n-1 more than any other range, by a very long
shot.
To me, ^ indicates XOR, so unary ^ should really be the bit-flip
of the operand.
Except in Perl 6, XOR is spelled +^ or ~^, and ^ is Junctive one().
So it seems that ^$x should be one($x). But that's an entirely
useless, trivial junction, so it makes sense to steal the syntax for
something else.
I think using C ..5 to mean (0, 1, 2, 3, 4) would be a more
sensible option. Makes sense to me at least.
Matt
--
Computer Science is merely the post-Turing Decline of Formal Systems Theory.
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: type sigils redux, and new unary ^ operator
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, but [EMAIL PROTECTED] doesn't return an index. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Lazy lists in Str context
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 **(1..Inf); $s = substr( ~( **(1..Inf) ), 0, 10 ); This would work, I think, if ranges were convertable to iterators, stringification was lazy, and substr() informed the stringification of how much it needed to do. I'm not sure how feasible that last one is ... Rob
Re: implied looping
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,oo,bar)».chars
from S3 yet
(I assume it just ignores the hyper)
--
Grtz, Ruud
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
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) { say; say }
: d. @{0..4} { say; say }
: (etc.)
:
: b. now produces 2 lines with 01234 (in pugs).
Which is wrong by the current spec, by the way. It should be a syntax
error to have two terms in a row. Bare parens can't be function args
unless they're abutted or use ..
: With implied looping that would be 10 lines, starting with two 0-lines.
I don't like that much deep magic without a keyword to clue the reader,
and we have plenty of keywords to work it already:
for ^5 { say }
^5.each { say }
(0..4).each == say
say for ^5;
I can see the mathematical appeal of coming up with a language in
which there is a meaning for every possible combination of tokens.
But there's an important linguistic principle here that I think has
never been adequately researched, and is probably worth a doctorate
to whoever does it. But it's a subtle principle, so it's rarely
mentioned. That principle is that there has to be some kind of
self-clocking aspect to a syntax, or you never realize if you've
gotten out of sync. In other words, there have to be some sequences
in the syntax that are syntax errors, or you'll never get any syntax
errors. That sounds like a tautalogy, but I don't mean it that way.
The self-clocking, phase-locked-loop aspect of Perl is driven by the
fact that we almost never allow two terms in a row, and also by the
fact that it's pretty easy to distinguish terms from operators most
of the time. This is what allows Perl to be a language that does,
in fact, overload leading characters between terms and operators
rather heavily. But if we allowed you to say $foo %bar and gave
it some meaning, you wouldn't be able to tell whether that % should
be a sigil or a modules operator.
And we also have to be careful about terms like {...} and (...) and
[...]. We've already made the exception that you can have {...} where
an operator is expected--that's exactly how the grammar recognizes
the difference between
for foo 1,2,3 {...}
and
for foo 1,2,3,{...},{...},{...} {...}
But it's easy enough to get tangled up with that exception, and if we
start making any sequence of bare brackets mean something, we'll not
get a syntax error but an unexpected successful parse, which can be
far more devastating than a syntax error.
However, in order to milk our bracketing characters for all they're
worth, as well as all the other operators, we finessed it in Perl 6
depending on the whitespace (or .) so that we can tell which
operators are intended as postfix operators and which ones are
misplaced terms. And that's why
{say} (1)
has to be a syntax error, while
{say}(1)
{say}.(1)
are just function calls. We really have to make that rule, or people
will be very confused a very large amount of the time. And the worst
part of it is that they'll think it's because they're stupid, not
because the language is poorly designed. It's a counterintuitive fact
that languages that are too efficiently coded induce inefficiencies in
communication. We're already dancing on the brink of too efficient,
and it would be easy to fall over the edge. Some would say we already
have...
Larry
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
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
Re: type sigils redux, and new unary ^ operator
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). : So, now, is it 0..one(@x) or [EMAIL PROTECTED] It's the latter, regardless of whether you visually parse it as 0 .. [EMAIL PROTECTED] 0 ..^ @x Perl parses it the latter way, of course, but the visual pun is part of why I wanted ^ to be short for 0..^. Larry
Re: type sigils redux, and new unary ^ operator
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 rather than ..5. Larry
Re: Lazy lists in Str context
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 lazy list. It should iterate over that rather than output it all at once, anyway, for reasons of conserving memory. to output an infinite stream, instead of just looping forever? How do you imagine anything outputs infinite stuff, without looping forever? I don't think stdout knows about our kind of laziness :) OTOH, it would be nice if say substr( ~(1..Inf), 0, 10 ) printed 1 2 3 4 5. Here, 1..Inf is stringified as a whole, while with say, each of the individual elements of the list are separately stringified. The question of lazy strings is an interesting one. It would be very useful, and would also allow GREAT things like my $revfoo := reverse $foo; $revfoo ~~ s/foo/bar/g; I wonder if it's doable, though... Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: implied looping
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).each: { say }
unless we made an infix:each operator of looser precedence:
^5 each { say }
Or we don't have infix:do, so maybe
^5 do { say }
Well, or we go back to ^ beeing the kind sigil that, like $5 retrieves
matched data, captures some countably 5 numbers singly stepping
to result in the lazy list (0,1,2,3,4) with five elements
as ordered. I would call that 'five out of void' :)
Note that ^5[-1] obviously is 4. And also ^5[-5] == 0. Welcome to the
heart of cardinal numbers. Or was that a card attack? Perhaps we call
that idiom a cardiogram? Or cardiarray? Might sound funny, but is
running very deep! To the heart of Perl6 arrays, actually.
--
Re: type sigils redux, and new unary ^ operator
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 same list.
I read ^5 as a range-list, like (in some mathematical notation) [0..5
or [0..4].
Such a list can be stored as (start;count;step=1).
Yes, it could use a step:
^42.7 = (0, 7, 14, 21, 28, 35)
^42.-7 = (35, 28, 21, 14, 7, 0)
^-42.7 = (-35, -28, -21, -14, -7, 0)
^-42.-7 = (0, -7, -14, -21, -28, -35)
and (^-42.7 + ^42.7) has length 11, maybe better expressed as ^-42.7.42,
which makes '^5' the short way to write '^5.1.0'.
--
Grtz, Ruud
Re: type sigils redux, and new unary ^ operator
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 plus one. It should not be used for index math.
There are cases where we should write @foo.last + 1, even though the
result will in almost all cases be the same as [EMAIL PROTECTED], and there are
cases where we should write @foo - 1, even though the result will be the
same as that of @foo.last.
That almost all arrays range from 0..i is no reason to write bad code.
Maybe someone doing
for ([EMAIL PROTECTED])-$i { say @foo[$i] }
That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
latter.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
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] returns the *number of elements*, not the index of the last
: element plus one. It should not be used for index math.
:
: There are cases where we should write @foo.last + 1, even though the
: result will in almost all cases be the same as [EMAIL PROTECTED], and there
are
: cases where we should write @foo - 1, even though the result will be the
: same as that of @foo.last.
:
: That almost all arrays range from 0..i is no reason to write bad code.
:
: Maybe someone doing
:for ([EMAIL PROTECTED])-$i { say @foo[$i] }
:
: That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
: latter.
I don't think that's a big problem. Formal arrays are allowed to view
all incoming array parameters as 0-based even if created elsewhere as
non-0-based arrays. Forcing everyone to use the same circumlocutions
because someone somewhere *might* use a non-0-based view of their
arrays is just falling back into one of those magical action at a
distance traps, I think. A non-0-based view is fine in a particular
lexical scope, but it shouldn't leak out.
Which means you can use [EMAIL PROTECTED] and know it's right in your lexical
scope.
Larry
Re: type sigils redux, and new unary ^ operator
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 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 mean %hash.keys. Flipping it the other way, does that argue that 5.keys means 0..4? Hmm. Doesn't do much for me. One of the other reasons I like ^5 is that the uparrowness of it naturally reads as up to 5. But for containers we could certainly abstract it out to the domain. Larry
Re: type sigils redux, and new unary ^ operator
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 mean %hash.keys. Or maybe not. We need some way of getting the keys of just the first dimension, and maybe .keys is that, on the model of Perl 5, where all multidims are really XoX in form, and .keys only ever gives you the top level. Then ^%hash and %hash.keys would mean the same thing only for 1-dimensional hashes. Likewise for arrays. Larry
Re: Lazy lists in Str context
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 supposed to *be* iterators, but pugs isn't there yet, last I checked. : stringification was lazy, and substr() informed the stringification of : how much it needed to do. I'm not sure how feasible that last one is : ... 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 up some way of declaring this particular string is lazy. 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. Larry
Re: type sigils redux, and new unary ^ operator
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: .. ^.. ..^ ^..^ If the rule is you can omit the 0, then it's ..^5 rather than ..5. 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). Regardless, my gut tells me that C ^5 is just a little too short for what it does. Also, I find the argument that people will type [EMAIL PROTECTED] and get confused fairly convincing. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Lazy lists in Str context
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 whole. say will have an array that represents the lazy list. It should iterate over that rather than output it all at once, anyway, for reasons of conserving memory. Ah, ok - but I believe that say() is slurpy, which means the list must be instantiated first. to output an infinite stream, instead of just looping forever? How do you imagine anything outputs infinite stuff, without looping forever? I don't think stdout knows about our kind of laziness :) There are some reasons for this - you can see what's happening, and press ctrl-C; or you may wish for it to output until there is a timeout; or maybe you are writing a daemon which is supposed to run forever anyway. OTOH, it would be nice if say substr( ~(1..Inf), 0, 10 ) printed 1 2 3 4 5. Here, 1..Inf is stringified as a whole, while with say, each of the individual elements of the list are separately stringified. The question of lazy strings is an interesting one. It would be very useful, and would also allow GREAT things like my $revfoo := reverse $foo; $revfoo ~~ s/foo/bar/g; I wonder if it's doable, though... I believe it is - I've come to this idea while trying to write down the Array spec, and it seems pretty feasible. Juerd Thanks! - Flavio
Re: Lazy lists in Str context
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 cannot be copied, because that flattens in list context, which is provided by assignment to another @-thing. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Lazy lists in Str context
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 ranges are iterator objects. The hidden iterators of a * list are evaluated when the values are requested from the slurpy array. So say 1...; ought to produce lots of output without ever running out of memory. (In reality, iterators are allowed to produce their values in batches for efficiency, so there's a slight possibility that an iterator could exhaust memory while producing the next batch.) Larry
Re: type sigils redux, and new unary ^ operator
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 integer range generation operator which returned 1 .. N in monadic (prefix) mode and M .. N in dynadic (infix) mode. and ^ used to be a full up arrow with a shaft (teletypes) and that is vaguely similar to the iota char. but given larry's stretchable imagination i don't think this mnemonic would hurt anyone. you just need to know some computer history. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Lazy lists in Str context
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 want.
: $foo can't flatten in list context, which .. does want, which would be
: inconsistent,
If you say
$r = 1..10;
you are intentionally putting the range object in a place where you
have to explicitly iterate it, so in list context you'd have to say
for =$r { say }
: but with @, it cannot be copied, because that flattens in
: list context, which is provided by assignment to another @-thing.
It only flattens notionally as * lazy, which means if you say
@r = 1..10;
@s = @r;
the iterator doesn't have to be evaluated, but just passed along as
part of the .specs to the next array, presumably with COW so the two
arrays can then have the appearance of having flattened the iterator.
But it's all * magic, not ** magic.
Larry
Re: type sigils redux, and new unary ^ operator
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 other use. : Regardless, my gut tells me that C ^5 is just a little too short : for what it does. I'd've felt the same way before I started revising S9, whereupon I discovered I wanted ^5 all over the place. It was either that or make special exceptions for lists containing one element, and that was gross. : Also, I find the argument that people will type : [EMAIL PROTECTED] and get confused fairly convincing. I dunno. I'm not confused by it, and I'm easily confused. Or maybe I'm just confused about not being confused... Larry
[OT] (was: Re: implied looping)
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 are too efficiently coded induce inefficiencies in communication. Many of us will experience that every day, for example when telling somebody what to do and how to do it. We're already dancing on the brink of too efficient, and it would be easy to fall over the edge. Some would say we already have... I know some. As a coincidence I am working on a project in which we remove topping layers from texts, to deduce a (quite artificial) skeleton from each text. This to make it possible to find and define relations between the texts. We use the skeleton-format also to link to very different data, like to parts of scanned images of the same kind of texts, to sound bytes, etc. -- Grtz, Ruud
Re: Lazy lists in Str context
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 up some way of declaring this particular string is lazy. 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. 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( [~](1..Inf), 10 ); my $revfoo := reverse $foo; $revfoo ~~ s/foo/bar/g; - Flavio S. Glock
Re: type sigils redux, and new unary ^ operator
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 ^5 { say } # 0, 1, 2, 3, 4
It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n.
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?
--
Peter Scott
Re: type sigils redux, and new unary ^ operator
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 operator in revising S09. It also makes it easy to
: write
:
: for ^5 { say } # 0, 1, 2, 3, 4
:
: 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'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 me offhand. First we're doing away with $#foo.
Second is all the array sizing in P5 is implicit, whereas S9 style
arrays are all about explicit array sizing, and 0..$n-1 comes up all
the time there. But I also am liking the generalization of unary ^
to mean domain.
And in an axiomatic sort of way, it corresponds to those theories
of math that build up the integers by counting set elements. The
argument that produces 5 is 0..4. And it works out that +^5 == 5.
But the generalization to hashes is even cooler because I can say
my %thishash{^%thathash};
or some such to duplicate the shape regardless of the typology
of %thathash.
Larry
Re: type sigils redux, and new unary ^ operator
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 expression.
| :
| : [EMAIL PROTECTED] returns the *number of elements*, not the index of the
last
| : element plus one. It should not be used for index math.
| :
| : There are cases where we should write @foo.last + 1, even though the
| : result will in almost all cases be the same as [EMAIL PROTECTED], and there
are
| : cases where we should write @foo - 1, even though the result will be the
| : same as that of @foo.last.
| :
| : That almost all arrays range from 0..i is no reason to write bad code.
| :
| : Maybe someone doing
| :for ([EMAIL PROTECTED])-$i { say @foo[$i] }
| :
| : That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
| : latter.
|
| I don't think that's a big problem. Formal arrays are allowed to view
| all incoming array parameters as 0-based even if created elsewhere as
| non-0-based arrays. Forcing everyone to use the same circumlocutions
| because someone somewhere *might* use a non-0-based view of their
| arrays is just falling back into one of those magical action at a
| distance traps, I think. A non-0-based view is fine in a particular
| lexical scope, but it shouldn't leak out.
|
| Which means you can use [EMAIL PROTECTED] and know it's right in your lexical
| scope.
What about array with holes as supported by Parrot?
Does .elems return the number of elements with or without
the holes?
Does iterating over the array iterates over the holes as well?
That would sound inefficient to do that over a mostly empty array.
Related question, Is there a way to get a list of iterators
that iterate only over the non-holey parts of an array?
--
cognominal stef
|
| Larry
|
Re: type sigils redux, and new unary ^ operator
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 is that this shortcut hurts clarity. It's almost as if a purpose was sought for the available ^, rather than there is something that will be used a lot, that needs a shortcut. Personally, I think even ^.., ^..^ and ..^ are too much, but that I can live with. Couple reasons occur to me offhand. First we're doing away with $#foo. Yea, and there's @foo.last to replace it. Indexes and numbers (counts) just aren't the same thing, and I think source code should communicate meaning using the right words. The word for the last index is .last, that of the number of elements is .elems, or [EMAIL PROTECTED] If you need the last index, plus one, you shouldn't use the number of elements, and if you need the number of elements, minus one, you shouldn't use the last index. Am I the only one who cares about this distinction? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
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 be interpreted implying anything :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Lazy lists in Str context
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( [~](1..Inf), 10 );
my $revfoo := reverse $foo;
$revfoo ~~ s/foo/bar/g;
That would violate the principle of least surprise. If all scalars
are, by default, eager, then:
foo( [EMAIL PROTECTED] );
foo( @list.join('') );
could potentially do different things, including possibly run out of
memory in some cases. Plus, what if the @list isn't lazy?
Better, I think, would be:
say substr( ~(1..Inf) is lazy, 0, 10 );
Or, have substr()'s signature be:
sub substr( Str $str is rw is lazy, Int $start, Int $?end, Int $?replacement );
Rob
Re: type sigils redux, and new unary ^ operator
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 me offhand. First we're doing away with $#foo.
Second is all the array sizing in P5 is implicit, whereas S9 style
arrays are all about explicit array sizing, and 0..$n-1 comes up all
the time there. But I also am liking the generalization of unary ^
to mean domain.
What about @array.indices instead? Then, there's no possible
fenceposting, your code is self-documenting, and we're not introducing
another unary operator?
And in an axiomatic sort of way, it corresponds to those theories
of math that build up the integers by counting set elements. The
argument that produces 5 is 0..4. And it works out that +^5 == 5.
So, +^5 is the way to generate the Church number for 5 through the use
of an iterator masquerading as a range?
But the generalization to hashes is even cooler because I can say
my %thishash{^%thathash};
or some such to duplicate the shape regardless of the typology
of %thathash.
my %thishash{%thathash.keys};
Much easier to read. The methods are there for a reason. Don't re-add
operators where there's a perfectly good method. Plus, overwriting
methods is much easier to grok for the average programmer than the
corresponding operator, unless you're aliasing the operator, in which
case I have problems figuring out why this is good, unless we're
deliberately designing P6 for the obfu/golf crowd.
Re: Lazy lists in Str context
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
lazy string to me is much like:
my @a = 1...;
my $b = [EMAIL PROTECTED];
Scalar context is strict, but that doesn't necessitate strict
evaluation the whole way down. The scalar context in that example is
saying evaluate the reference *now*, not the list.
The kind of lazy string that would be affected by scalar context is:
my $str = do { say hi there; foo };
say intermediate;
say $str;
If scalar context were lazy, it would say hi there *after*
intermediate (but before foo, of course).
But we're talking about a string with a lazy internal representation,
like a reference to a lazy list. That's perfectly okay to pass around
in scalar context. And I think it's perfectly okay to have
stringification return this kind of lazy string.
Luke
