Re: S5: range quantifier woes
Jonathan Scott Duff wrote:
- for minimal matching the ? is too far away from the operator that it
applies to. It looks like it's doing something to the closure (and
maybe it is) Should that be [foo]**?{$m..$n} instead?
- Bringing a closure into the picture seems to put too much power in
such a simple construct. [foo]**{ destroy_the_world; 0... }
This gave me 2 ideas. First:
# not a closue, no runtime side effect, a straight compile
/[foo]**(3..5)/
# The closure is explicit and before the code it affects.
# (Yay end-weight!)
/ {($min, $max) = binNsmall()} [foo]**($min..$max) /
Second, if it is a problem that '?' is too far away, how about this?
[foo]**{5..3} # greedy
[foo]**{3..5} # lazy
Kindof implies
[foo]* == [foo]**{*..0} # greedy
[foo]*? == [foo]**{0..*} # lazy
but those would probably really be
[foo]**{Inf..0} # greedy
[foo]**{0..Inf} # lazy
But the greedy case would require careful processing, forget it. Might
work if the closure idea were replaced with a semi-special non-closure
syntax. Of couse we have the simpler syntax for those common cases
anyhow, forget it. No, really.
Oh, is there a way to trick this closure syntax into being the '0 or
more' equivalent? Suppose it would have to be returning an infinite
list. That seems familiar, but I forget why.
I guess I'm not seeing the point in having a special closure based
syntax. (Well, aside from Larry saying so. That ain't a bad reason.
I'm just sayin'...) It could be abused in ugly ways and the only power
it provides in the intended case is an arbitrary finite range. Seem
this could be made to work with plain closures and simple range that
allows variables as well as literals. It would be just as possible and
not much less friendly.
Ok, so I guess I'd suggest
/ {($x,$y)=daRange()} thing**($x..$y) /
since parens kind of get you a list, which is really all you want to
allow anyhow. It kinda looks a little like a code assertion too, well
if you want to see it that way.
/ {($x,$y)=daRange()} thing* ($x..$y ~~ +@thing) /
So maybe:
/ {($x,$y)=daRange()} thing**($x..$y) /
or
/ thing**(deRange()) /
I wouldn't beat a drum for any of them though. Well, not more than I
have. Those last two would be easy to mis-read. And actually, now that
I think of it, setting the range in a closure has the requirements of
running at canonical times. That's probably not what we want is it. I
guess we're back to the closure syntax again. And the curly braces of
the closure already have history attached to them. Forget it. No, I
mean it this time. Honest.
Dan
Re: What Requires Core Support (app packaging)
Simon Cozens wrote: For heaven's sake. Have you even *seen* the Perl 5 internals? If you don't trust things which are self-declared scary hackery to be stable, you probably shouldn't be using Perl until Perl 6 comes out. And probably not until then. Um, on a somewhat unrelated note, having tried to get a department of mine to switch over to perl from csh and REXX of all things, I have co-workers I hope never see this. Look, we're not going to agree on this. Should we just drop the subject? I know I've seen more than I wanted to. Dan
Re: Synopsis 2 draft 1 -- each and every
Peter Behroozi wrote:
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... } #or
for $foo.grab { ... } #or
for $foo.eat { ... }
And to replace $/ we could have something like:
for $foo.fetch :upto(,) { ... } #or
for $foo.fetch :until(,) { ... }
general impose scalar impose list
--- --
D $foo.eat$foo.bite $foo.gobble
N $foo.look $foo.peek $foo.peruse
hmm, I don't like eat in this case
D $foo.take $foo.grab $foo.horde
That assumes folks think of grab as being singular and take as being
open ended. That, and I don't want take to colide with gather{take}.
Oh well.
Dan
Re: Synopsis 2 draft 1 -- each and every
Chromatic wrote: On Fri, 2004-08-20 at 14:26, Austin Hastings wrote: Dan Hursh wrote: generalimpose scalarimpose list ----- D$foo.eat$foo.bite$foo.gobble N$foo.look$foo.peek$foo.peruse hmm, I don't like eat in this case D$foo.take$foo.grab$foo.horde s/horde/hoard/ If I'd written that, I'd claim that as deliberate. Though it does leave a problem with grab as a singular noun, It kinda looked wrong, but, well... 6 of one, a dozen of the other It's all the same to spell check... send it!
Re: Synopsis 2 draft 1 -- each and every
David Green wrote:
...but print next $foo is better than print each $foo. ...
print another $foo
for another $foo {...}
while another $foo {..}
It's 5 characters too many, but it works.
Dan
Re: [Fwd: Re: Something to ponder]
Aaron Sherman wrote:
This bit comes from the p6i list, and I just thought I'd ask those
in-the-know if my suggested returntype role/property would make sense
here, or if there's another way to do it that makes more sense?
For that matter, does MMD on return type map into Perl6's gestalt at
all, or would it be tumorous?
To sum up:
Dan: return continuations and MMD calling means we can dispatch return
via MMD
Aaron: suggested an implementation in Perl and Python. In Perl, it would
be a role/propery called returntype that would take some sort of list
or hash of types and closures. The difference between this and a
given/when block being that the MMD internals of parrot handle which
closure is invoked based on the return type. Thus, very low overhead.
My example in the attached message is mostly error handling, but that's
obviously not the only way it could be used
[snip]
$sock.peername()
does returntype(
Net::Address::IP - $ip {
die Remote host unresolvable: '$ip';
}, Net::Address - $addr {
die Non IP unresolvable address: '$addr';
}, Str - $_ {
print Seemingly valid hostname: '$_'\n;
});
Could this just work with the switch statement somehow? If not, could
'when' be extended to take a signature that is matched against the
return 'arguments'?
given $sock.peername() {
when(Net::Address::IP){
die Remote host unresolvable: '$_'
}
when(Net::Address){
die Non IP unresolvable address: '$_'
}
when(Str){
print Seemingly valid hostname: '$_'\n
}
}
or more complexly
sub foo {
return time if time % 2;
return (time,
() = gmtime)# ya, I know p6 has a better way,
# but I can't remember it right now
}
given foo(){
when(Int){
say $_, , join , gmtime $_
}
when(Int $t, Array @gmt){
say $t, , join , @gmt
}
}
Dan
Re: Why do users need FileHandles?
Larry Wall wrote: Sounds like you're confusing #3 with #4. Larry Could be. Does 3 mean at install time, you down load the latest of the 'supported' packages from the CPAN alike or is it more like versioned snapshots? (Possibly yet to be decided?) It's the idea of a standard library being open to daily change that scaring me most at the moment. If that's not likely, then me other concerns, well, aren't. Dan
Re: Why do users need FileHandles?
Aaron Sherman wrote: Do any C++ programmers consider the STL to be anything other than in core even though it's not part of the compiler, and with at least GCC, it's distributed as a separate component? Do any C programmers consider strlen or sprintf to be outside of the core? It's part of the ANSI C *STANDARD LIBRARY*, not the ANSI C spec. Does anyone really ship compilers w/o a standard library. I don't care if they are in separate tar/rpm/etc files. As long as they go together. Does anyone other than a spec writer document the language minus the library? Define outside of the core, please. I'm sticking to my definition involving the camel book and packing them together. If I was going to make a recommendation (which I guess I am), I would suggest having 4 layers of library: 1. Really-really core (the stuff you can't write the other stuff without), and is probably all built-ins in Parrot. The toy for the researcher. Not much of a tool yet, but fun. 2. Really core. This is the sort of standard library. Just the most essential bits that are required for general Perl usability. You'd probably include most of these, even in a trimmed down release, such as an OS installer What most venders will ship. 3. The extended core. The modules from some CPAN-alike that are considered to be supported Perl extensions In Perl 5, I think of libwww-perl and libnet this way, but making an official distinction lets users decide what modules to rely on in code that will have to be updatable for 5 years. What my site IT people might get around to installing in the site image for perl 6 during the perl 8.2 time frame. 4. The CPAN-like grab-bag of goodies. The pre-pre-alpha modules that work on two-ish platforms. Many of which were in the same state a year ago. OK, maybe I'm over stating that. But I do think that if perl 6.X.Y is not accompanied by a packaged perl library version I.J.K that is as documented, tested and portable as the language, then most people won't see any modules outside of those shipped in the perl6 source archive. I hate that. To put it another, if a library version is not done in concert with a given language version, then either users can't rely on the availability or exact behavior of any function beyond the core package. Each vendor with have to make their own library, and test it. Overlooking the duplication of effort for each vender, given that vendors seem to have enough trouble packaging remotely recent versions of perl 5, and given that different venders might not choose the same selection of modules or that they might not pick compatible versions of the same modules, this just looks like a black eye waiting to happen. This all assumes that venders put the effort into it at all. If not the venders, do you expect each perl programmer to have root -like access? I could have missed the chapter, but I didn't see a good way for a perl programmer to install from CPAN to his home directory and use it seemlessly with an OS shipped perl install. So far my experience do it with CPAN haven't gone well anyone. Maybe each user could compile his own interpreter from source. That's how I had my best luck. I still get lots of errors on CPAN installs. It's kind of a pain. Besides, things should be run out of a user's home directory in a production environment. I know this isn't a new problem, but it is why I didn't use Net::FTP at work until about a year ago. They just didn't install the bugger and I didn't have control of the site image. The same goes for perl5.6 for that matter, so I might not see perl6 at work before I retire in some 20 years from now and this will all be moot. I just think there ought to be a decent library. It worked well for python and java (even inspite of how java's library is designed!) and it would put perl ahead of the likes of C and C++ (which I believe have far too skinny standard libraries to be useful). I also think that library needs to be tested as well as perl6. It needs to be equally portable as well. (Yes I know there are limits there. If TK won't run on my watch, I'll understand. I'm sure the watch probably won't support all the core features either.) And a given version of the library needs to 'go together' with a given version of the language. The gcc folks may not tar the C++ standard lib up with the compiler, but there tends to be a given version of one to use with a given version of the other. Of course, maybe there are other solutions. Maybe I'm wrong for thinking it ought to be a requirement. Maybe I just need to work at a shop with more perl biggots on staff. Dan
Re: Why do users need FileHandles?
Larry Wall wrote: On Sun, Jul 25, 2004 at 01:32:29AM -0500, Dan Hursh wrote: : 2. Really core. This is the sort of standard library. Just the most : essential bits that are required for general Perl usability. You'd : probably include most of these, even in a trimmed down release, such : as an OS installer : : What most venders will ship. Which is basically why we are planning not to produce one of these. I think we should concentrate on 1 and 3. I know. In that case, I think venders are liable to be lazy or peeved and ship option 1 or worse, nothing. Is the answer really supposed to be CPAN or no library? Is there a plan to at least have stable snapshots of CPAN? Sorry to be a pest on this, but the implications actually scare me about things I didn't worry about before because I had confidence that they would be addressed in 'the library'. Maybe I just need to sit and meditate some more. Dan
Re: String interpolation
Larry Wall wrote:
No Yes
-- ---
@foo@foo[1]
%bar%bar{a} or %bar«a»
$foo.bar$foo.bar()
foofoo(1)
I may have missed it, but what are the contexts in these cases? I'm
thinking the first two are easily scalar. Are the second list just as
if they were inside curly braces, or are the scalar to match the others
(or just to be flexibly different)?
In this worldview, $foo is an exception only because it doesn't naturally
have a form that ends with some kind of bracket.
Will $x[$y] interpolate? Oh and if $x is a reference to an array, is
$x a stringified reference or dereferenced (and in which context)? I
got it in my head that since things in curlies would be in list context
that the others must be scalar/string context. I haven't been able to
find a reason for justifing that leap, but I kind of like it. Well for
the moment.
Dan
Re: Why do users need FileHandles?
Luke Palmer wrote: JOSEPH RYAN writes: - Original Message - From: David Storrs [EMAIL PROTECTED] Date: Monday, July 19, 2004 5:04 pm Subject: Re: Why do users need FileHandles? Second, I would suggest that it NOT go in a library...this is reasonably serious under-the-hood magic and should be integrated into the core for efficiency. How would integrating this in the core make it more efficient? Core or not, I'd see something like this being implemented with a custom pmc. I tend to think of inclusion in the core being more of a philosophical decision... Yes, it is. Whether or not a PMC is in the core, it should be equally fast. That is, unless Parrot is allowed intimate knowledge of the PMC's internals. And there are very few (any?) PMCs that possess this property even now. Even more philosophical is what is core? I get the impression that Larry is trying to blur the distinction between core and non-core as much as possible. So making it go in the core may just mean that it's on the list of recommended modules to install. Luke How about we say in core means it packaged with the perl6 source and covered in the coresponding camel lama books. :) Dan
Re: scalar subscripting
Larry Wall wrote:
On Wed, Jul 14, 2004 at 10:23:18AM -0700, Larry Wall wrote:
: Another alternative is $( $file ).ext. I'd tend to use that before
: ${file}.ext these days. Perhaps that's irrational--but it was hard
: to get the special-case ${name} form to work right in the Perl 5
: lexer, and that bugs me. If we're going to get rid of the autoquoting
: of $hash{shift}, we likely ought to undo the autoquoting of ${shift}
: as well, even if that gives heartburn to a certain number of shell
: programmers.
And if we do that, I guess that means that $«file».ext could
be made to work as a replacement, which seems conceptually clean if
you don't think about it too hard.
Maybe I'm missing something here, but this looks just plain cruel. Is
it easier to parse ...um... that? It's that same debate that's been
here before, but a lot of us can't type it yet. I probably could, but I
don't know the incantation for mozilla on windows. If I did, it bet it
wouldn't be the same as as the raindance for notepad. If it is the
same, then it probably isn't the same as the incantation in vi or emacs
on linux or aix.
I use ...${var}... a lot, and unfortunately, I have to use a number of
different programs and oses. Unfortunately, typing '«' '»' (thank you
cutpaste) is not as portable on the keyboard as say '{' '}' (or ''
for that matter).
Is ${var} really that rare in real world perl? Are we going to try to
have ascii equivalents like '' '' in quoted strings? (Please no.)
Do I need to put a unicode keyboard next to the APL keyboard on my
wishlist?
Dan
Re: if not C, then what?
Michele Dondi wrote:
A late thought, but since I am one of thow whose' keen on the
print,next if /stgh/;
Ouch. I hadn't thought of that. I'm a big fan of litering loops with
discard(),next if dontCareBecause(); # it don't matter here
type constructs. I was going to suggest
print and next if /stgh/;
but there is a difference that will probably bite you when you least
expect it. You could say
(print or 1) and next if /stgh/;
but not we are in the areas of pointlessy ugly hacks. I could live with
do{print;next} if /stgh/;
but the do just feels over verbose. So do the braces. Can next be used
in numeric context?
(print) + (next) if /stgh/;
hmm. ug. Never mind. Oh! I've got it!
eval print;next if /stgh/;
no. That as bad as do, 'cept differnt. I give up.
Dan
Re: push with lazy lists
Joseph Ryan wrote:
The way I understand the magicness of lazy lists, I'd expect:
@x = 3..Inf;
say pop @x; # prints Inf
@x = 3..Inf;
push @x, 6; # an array with the first part being
# lazy, and then the element 6
say pop @x; # prints 6
say pop @x; # prints Inf
say pop @x; # prints Inf
say pop @x; # prints Inf
# etc
The way I think of a lazy infinite list is kind of like a special object. It needs to keep track of what the start is and what the end is. Every other element doesn't actually exist, but is calculated based on the index of the FETCH/STORE/SPLICE/whatever call.
I guess that's true with X..Y lazy lists. I thought there were other
ways to make lazy lists, like giving it a closure that gets called
lazily to populate the list with the result's being cached. I can't
remember the syntax though. I think gather was one way. Maybe I'm just
remembering wrong.
Anyhow, I was thiking that was how X..Inf was implemented. That would
be foolish in this case.
how 'bout
@x = gather{
loop{
take time
}
} # can this be @x = gather { take time loop }
push @x, later;
say pop @x;# later
say pop @x;# heat death?
say @x[rand]; # how about now?
Also, any list that contains and infinite list becomes tied. The container list's FETCH would
change so that any accessed index that falls within the indexes owned by the
infinite list would be dispatched to the infinite list. So, with a list like:
@array = ('a','b','c',2..Inf,woops);
Elements 0, 1, and 2 would be accessable as normal, but then elements 3 through Inf would be dispatched to the infinite list. However, since woops's index is also Inf, and that index is owned by the infinite list, it would be impossible to access it except through a pop call (which doesn't look at indexes at all).
I was wondering about lazy list where we don't know how many element it
might generate. Admittedly, I picked a poor example. I would right to
assume woops would also be accessable with @array[-1], right?
Dan
push with lazy lists
Hi, If I can assume: @x = 3..5; say pop @x;# prints 5 @x = 3..5; push @x, 6; say pop @x;# prints 6 say pop @x;# prints 5 What should I expect for the following? @x = 3..Inf; say pop @x;# heat death? @x = 3..Inf; push @x, 6;# heat death or # an array with infinity + 1 elements? say pop @x;# prints 6? say pop @x;# heat death? Dan
Re: definitions of truth
Paul Hodges wrote:
--- Jonadab the Unsightly One [EMAIL PROTECTED] wrote:
Consider this test in Perl:
if \0 {...}
Its equivalent in C is this:
if () ...
That can't be right. If anything it's got the two languages
flipped, but that's still not quite right either. Apples and
orange leotards.
lol
if(!strcmp(\0Apples\0, \0orange leotards\0))
printf(I see no difference here\n);
