> > Another win is in evaluation of lists constructed by generator
functions:
> > # ($start: f(__): $end) == ($start, f($start), f(f($start)), ...)
> > @powersOf2 = (1:__*2:); # (1, 2, 4, 8, ...)
> > @first10PowersOf2 = @powersOf2[0..9]; # Calculates 1st 10 powers of 2
> > # ...interesting
On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote:
> Basically, you don't want to go anywhere near this mess; it eats people.
I agree.
> I see two reasonable options to go with instead. One is to just use a
> binary flag that says use UTC or not; this is the simplest and most
> relia
On Sun, Aug 06, 2000 at 01:10:23PM -0700, Nathan Wiger wrote:
> > GMT is not UTC (although it is equal for most practical purposes).
>
> Ok, I'll have to research this a little. I've heard both ways (it is, it
> isn't, it's supposed to be...)
For me, GMT has no leap-seconds, UTC does.
> > since
"Jeremy Howard" <[EMAIL PROTECTED]> writes:
> Damian Conway wrote:
[...]
> > Personally, I intend only to update the RFC to include the *possibility*
> > of (..$x) and (..). I'm reasonably sure Larry will kill the whole thing
> > -- I think I might too, were I in his place ;-)
> >
> Now don't
Ken Fox wrote:
> Jeremy Howard wrote:
> > Anyhoo, there's no reason why you can't have ^1, ^2, and so forth, _and_
> > allow named placeholders too. Although I don't see what this buys you.
>
> Argument ordering. We might be constrained by the caller as to what order
> the placeholders are passed
At 12:50 AM 8/7/00 -0500, Jonathan Scott Duff wrote:
>On Sun, Aug 06, 2000 at 08:03:51PM -0700, Nathan Wiger wrote:
> > > What about C ?
> >
> > Here's yet another one - how about "here"?
Doesn't this have a list of its own yet?
>Well, "here" isn't a verb and I think we need a verb er ... here.
Ken Fox wrote:
>
> my $f = (^x < ^max) ? ^x * ^scale : ^y * ^scale;
>
> has to be called
>
> &$f($x, $max, $scale, $y)
Hmm, perhaps we can use those named placeholders when calling the
function by a hash. And instead of generating a complete new code
reference, we can simply "build up" our
On Sat, Aug 05, 2000 at 08:53:58PM +, Nick Ing-Simmons wrote:
> You loose one little thing - you have a new scalar (the handle)
>
> with
>
> open $fh,$filename
>
> one can re-use an existing thing to which someone else may have a reference.
> (Not that that is useful very often.)
Well per
On Sun, Aug 06, 2000 at 08:03:51PM -0700, Nathan Wiger wrote:
> > What about C ?
>
> Here's yet another one - how about "here"?
Well, "here" isn't a verb and I think we need a verb er ... here.
Granted, "local" isn't a verb either, but that's probably part of it's
problem.
-Scott
--
Jonathan S
Jeremy Howard wrote:
> Anyhoo, there's no reason why you can't have ^1, ^2, and so forth, _and_
> allow named placeholders too. Although I don't see what this buys you.
Argument ordering. We might be constrained by the caller as to what order
the placeholders are passed in. Also, we want to make
> > There's two potential solutions here:
> > 1- Use '_'
> > 2- Use '^', but increase the strictness of sub calls
>
> > The second suggestion specifically relies on us deciding that barewords are
> > always evil, so that :
> > $a = foo; # Error! Evil bareword! Return to firey depths of hell!
> There's two potential solutions here:
> 1- Use '_'
> 2- Use '^', but increase the strictness of sub calls
>
> I'd be happy with both. I'm with Damian that '__' looks cool, but I
> understand that people typing in perl from a magazine (do people still do
> that?) might get confused (mmm... comfy
Ken Fox wrote:
> Actually I was wrong about ^ not working. The binary operator ^ is XOR.
> The unary "operator" ^ could be for curries.
>
Right. I though you were just worried about it looking confusing. I don't
think the parser will be bothered (at least, I can't think of anything
ambiguous so fa
> >{
> > here $/ = "\n"; # what it is in here
> >}
>
> But it isn't "here" that's the problem. If we just wanted to change
> the value "here", we could use my(). The problem is that local()
> changes the value for somewhere else as well as here. Other names
> suggested (like "sh
> Well, what's the different between the placeholder &foo and the sub
> &foo? That's the main reason why. Also, '&' already has a perfectly good
> meaning: binary AND with the function foo(). :) Not trying to be a
> smartass, but I think you understand what I'm trying to say.
Yes. '&' is misleadi
Mike Pastore wrote:
> Ken Fox wrote:
> > > Although, I suppose '&' would not work.
> >
> > Why not? I think it would work great.
>
> Well, what's the different between the placeholder &foo and the sub
> &foo? That's the main reason why. Also, '&' already has a perfectly good
> meaning: binary AND
Here's a thought. Wouldn't this be cool (see below)? The idea is that in
Perl 6 you should be able to read from a file handle one character or one
line at a time (just like you can in Perl 5) BUT if you just go ahead and
use the filehandle, directly, in a scalar context then perl will read it in
> $zot **= ^foo# "what's that binary op doing there..
> # ..oh, that's a placeholder"
I think this is a valid way of looking at it. If you think about it, *
for typeglobs is the same symbol as * for multiplication. But the parser
can figure it out based on context. I don't se
I concur with Mike. If we *have* to have a prefix (and I *still* prefer
a naked __, gumble, grumble, pout), then I'd certainly rather ^ that &.
What we *really* need are some more types of brackets:
$range = Ç__È < ÇvalÈ && ÇvalÈ < Ç__È;
;-)
Damian
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
List context return from filesystem functions
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 6 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 52
=hea
Ken Fox wrote:
>
> > - ^foo is the placeholder 'foo'
>
> That already has perfectly good meaning: XOR with the function foo().
Good point. Back to the drawing board?
> > Although, I suppose '&' would not work.
>
> Why not? I think it would work great.
Well, what's the different between the p
> > New programmers should easily understand
>
> New? You're talking about "new" "easy" and "higher order functions"
> in the same sentence? ;)
>
This was intentional. (Err, yes, it was bait, basically...)
Higher order functions are harder for old [procedural] programmers than new
ones (IMHO). Ha
> > What about C ?
>
> Here's yet another one - how about "here"?
>
>{
> here $/ = "\n"; # what it is in here
>
>}
>
> Not really any confusion on this - $/ is "\n" 'in here', but maybe
> something else outside.
>
> Unlike "hide" or others, this doesn't connote it's necessaril
[Sorry, spent too much time thinking in the editor and did not
see this before my reply.]
Mike Pastore wrote:
> - ^foo is the placeholder 'foo'
That already has perfectly good meaning: XOR with the function foo().
> Although, I suppose '&' would not work.
Why not? I think it would work great.
> What about C ?
Here's yet another one - how about "here"?
{
here $/ = "\n"; # what it is in here
}
Not really any confusion on this - $/ is "\n" 'in here', but maybe
something else outside.
Unlike "hide" or others, this doesn't connote it's necessarily any
different from somew
On Sun, Aug 06, 2000 at 12:35:58AM +1000, [EMAIL PROTECTED] wrote:
> I do *not* want to see any more obscenity of name calling here. It does
> nothing to advance the purposes of this working group, and discourages
> people from contributing.
You're quite right, I went too far there. Yes, I was f
Dan Sugalski wrote:
> But, if we toss refcounts, and split GC cleanup and
> end of scope actions anyway, we need to have a mechanism to hoist things
> out of the current scope.
Why say hoist when we can say return? I can think of several ways of
returning values that don't require the caller to a
> Or just STRING. It's a verb to, you know ;-)
Yeah, I think this is best. SCALAR isn't real accurate anyways. I'll
change it in v2.
-Nate
Jeremy Howard wrote:
> It is proposed that Perl introduce a new prefix '_', which indicates a
> placeholder. This can be used either as '_identifier', which creates a named
> placeholder, or '__', which creates an anonymous placeholder.
This is a good idea, but it has a good chance of tripping up
Nathan Wiger wrote:
>
> I think the principle of a "general purpose placeholder" is a good one.
> But I think _ is already used so much in Perl that something else is
> better. I like ^ since is looks like a carat ("insert your variable
> here"), personally.
Or even a thumbtack, holding the vari
On Sun, Aug 06, 2000 at 06:29:46PM -0700, Nathan Wiger wrote:
>print $pw;
This resulting in a $pw->SCALAR method call is confusing. $pw is not being
evaluated in scalar context.
>print $pw;
>print scalar $pw;
These resulting in a $pw->STRINGIFY or $pw->TO_STRING call is also
co
Okay. I'll rework the proposal with the consensus syntax.
Damian
> But the expression
>
> __ < 2 + __ * sin(__ / 2) or die __
>
> curries to
>
> sub { $_[0] < 2 + $_[1] * sin(sub { $_[0] / 2 }) or die $_[2] }
>
> That's very odd.
No. You got it exactly right. :-)
> I really hope I'm missing something, but __ the way yo
> >STRINGIFY would have my vote. "It's a string!!!". A string is a very
> >specific subtype of scalar.
>
> How about TO_STRING? Little less geeky.
AS_STRING. It doesn't convert, it translate.
Or just STRING. It's a verb to, you know ;-)
> How would this play with overload.pm?
> > Just as simply,
> >
> > - $foo is the variable 'foo'
> > - ^foo is the placeholder 'foo'
> > - $_ is the default variable
> > - ^_ is the default placeholder
>
> Yeah, I personally can read this much clearer. Peter also mentions that
> __ is hard to distinguish from _, unless they're right nex
At 04:02 AM 8/7/00 +0200, Bart Lateur wrote:
>STRINGIFY would have my vote. "It's a string!!!". A string is a very
>specific subtype of scalar.
How about TO_STRING? Little less geeky.
How would this play with overload.pm? What if that also specifies a
stringify routine? Which one should win?
Damian Conway wrote:
> That should of course have been:
>
> __ < 2 + __ * atan2($pi, __) or die __
Oh, yes, of course. Um, wait. Nope, I still don't follow. The
expression above curries to:
sub { $_[0] < 2 + $_[1] * atan2($pi, $_[2]) or die $_[3] }
But the expression
__ < 2 + __ * sin(__
On Sun, 06 Aug 2000 17:20:06 -0700, Nathan Wiger wrote:
>I'm not against other names. You're right, STRINGIFY has a ring to it,
>but I worry it might be too catchy for its own good? Not sure.
>
>The reason I thought SCALAR was good was because of this:
>
>print scalar $object;
>
>If this call
Perl6 RFC Librarian wrote:
> BiDirectional Support in PERL
I know nothing about bi-directional output. It doesn't seem
like Perl has any assumption of left-to-right at all. What's
the difference between right-to-left support in Perl and just
editing/using Perl in an xterm that does right-to-left?
> I'm ashamed that this feature would mess with my (bad?) habit of
> re-writing "$pw" to just $pw on the assumption that whoever wrote
> it didn't know what the hell he was doing. Would anybody else be
> caught like that?
I'm not sure it would. I think if we did it right all of these could
potent
> Just as simply,
>
> - $foo is the variable 'foo'
> - ^foo is the placeholder 'foo'
> - $_ is the default variable
> - ^_ is the default placeholder
Yeah, I personally can read this much clearer. Peter also mentions that
__ is hard to distinguish from _, unless they're right next to each
other,
Nathan Wiger wrote:
>$pw = getpwnam('nwiger');
>print "$pw"; # calls $pw->SCALAR, which prints 'nwiger'
>die "Bad group" unless $pw->gid == 100;
I'm ashamed that this feature would mess with my (bad?) habit of
re-writing "$pw" to just $pw on the assumption that whoever wrote
Jeremy Howard wrote:
>
> New programmers should easily understand that:
> - $foo is the variable 'foo'
> - _foo is the placeholder 'foo'
> - $_ is the default variable
> - __ is the default placeholder.
> Then, when they see the same named placeholder appear twice in the same
> higher-ord
At 05:35 PM 8/6/00 -0700, Nathan Wiger wrote:
>Can I make one observation? Maybe I'm the only one.
>
>I find the __ *really* hard to follow. I've been trying to keep up with
>this discussion, but it's really chewing me up.
>
>Since this is really something different (not a scalar, hash, etc), has
> I find the __ *really* hard to follow. I've been trying to keep up with
> this discussion, but it's really chewing me up.
>
> Since this is really something different (not a scalar, hash, etc), has
> any consideration been given to other variable names:
>
>^_
>&_ # kinda like this
> The error was not here but in:
>
>__ < 2 + __ * atan($pi/__) or die __
>
> That should of course have been:
>
>__ < 2 + __ * atan2($pi, __) or die __
Can I make one observation? Maybe I'm the only one.
I find the __ *really* hard to follow. I've been trying to keep up with
this disc
> Larry's commented (in p5p) on his own experience in trying to
> have properly "stringified" objects. He wound up with a bunc of
> classes doing exactly what you suggest, which is using the
> existing overload mechanism *for just that one operation*. He
> speculated then that this particular on
Damian Conway wrote:
> I think I opened a bigger can of worms than I intended :-)
Yes, sorry about the overload of email you must of got from me on this, this
morning ;-)
>
> As MJD as pointed out to me in private email, if we are serious
> about this feature, we probably want to go the whole hog
> I don't see in here how an object tells the difference between being in
> scalar context and being in string context.
Think tie(). It wouldn't necessarily be the object that makes the
decision.
> for anything that wants to take such a relatively odd action.
As Spider notes, this isn't really
> (Note that I'm keeping the ':' notation, because then it's clear that
we're
> talking about a generation rule, not an upper bound). Now I write it like
> this, wouldn't it be nice if we could also say:
> (1..:f(__)) == apply(f(__), (1..); # But I digress!
>
Correction (sorry). This should be:
> > $root->traverse( $sum += __ );
>
> There's a syntactic ambiguity here. I assumed that __ "poisons" an
> expression so that an entire parse tree gets transformed into a
> closure. If you isolate the parse tree based on expression precedence,
> then I'm not sure wh
> Yes! Yes!
>
> How about using a float (fractional second) instead of $msec, $nsec.
Works for me (it's for you anyways). ;-)
-Nate
> Returning an object is the most generally useful. Converting it to a
> string on the fly when you need a string, works best for me.
That's exactly what my RFC says. :-)
-Nate
On Sun, Aug 06, 2000 at 01:41:06PM -, Perl6 RFC Librarian wrote:
>$scalar = date; # scalar ctime date, same as current
>@array = date; # array of date/time values (new order)
>%hash= date; # hash of date/time values (new)
>$object = date; # object wi
On Sun, 06 Aug 2000 16:43:36 -0700, Peter Scott wrote (in part):
Peter> Call me old-fashioned, but I don't see what's wrong with
Peter> use overload '""' => sub { $_[0]->to_string };
Peter> for anything that wants to take such a relatively odd
Peter> action.
Larry's commented (in p5p) on his o
> Objects should have builtin string SCALAR method
>
Sorry if I'm just being dumb, but... don't we already have this by
overloading the stringifying operator q{''}? How is the proposed SCALAR
method different?
At 11:36 PM 8/6/00 +, you wrote:
>I suggest that objects provide a default method called C that
>determines what they produce in a scalar context. When stringified, an
>object would automatically call its C function and return the
>correct value.
I don't see in here how an object tells the di
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
BiDirectional Support in PERL
=head1 VERSION
Maintainer: Roman M. Parparov <[EMAIL PROTECTED]>
Date: 06 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 50
=head1 ABSTRACT
This paper
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects should have builtin string SCALAR method
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 06 Aug 2000
Version: 1
Status: developing
Mailing List: [EMAIL PROTECTED]
On Mon, 7 Aug 2000 05:41:10 +1000 (EST), Damian Conway wrote:
> > > $scalar = date; # scalar ctime date, same as current
> > > $object = date; # object with accessor functions (new)
> >
> > How are these distinguished?
>
>If $object is typed (my Date $object), then want()
I think I opened a bigger can of worms than I intended :-)
As MJD as pointed out to me in private email, if we are serious
about this feature, we probably want to go the whole hog and
look at Haskell's notion of list comprehensions. See
http://www.haskell.org/tutorial/goodies.html
speci
One of the major problems with Perl's OO, is something I haven't seen
mentioned in these lists, until now. So I'll bring it to your attention
here and now.
The problem is that you can't safely subclass a class, without examining
it's source, just to make sure that your instance fields don't clash
On 4 Aug 2000 22:13:59 -, Perl6 RFC Librarian wrote:
>Angle brackets should not be used for file globbing.
Loud cheers, throw hats in the air, whistle, stamp feet, etc.
In fact, anything with ambiguous (i.e. unpredictable) behaviour should
be put under real close inspection. Another example
Ken Fox wrote:
> Jeremy Howard wrote:
> > (..-1) == map -__ (1..);
>
> That really confuses me. If the sequence (-4..-1) is (-4, -3,
> -2, -1) then I don't see how your semantics are consistent. I'll
> admit (reverse map -__ (1..)) is the same as (..-1) but reverse
> on a stream is undefined. (I
On Sun, 06 Aug 2000, Gisle Aas wrote:
> How about using a float (fractional second) instead of $msec, $nsec.
Or in addition to.
The problem with fractional seconds is that you can't really tell
exactly how precise your measurements are.
Here, at least, you could have an undef for the measureme
On Sun, 06 Aug 2000, Johan Vromans wrote:
> Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
>
> > There are times when one may need (or desire) to change the shell used
> > for interpretation, as well as force shell interpretation, regardless
> > of optimization, for consitency's sake.
>
> p
On Sun, 06 Aug 2000 01:38:13 -0400, Dan Sugalski wrote:
>>Even in perl5 an XS module can do _anything at all_.
>
>It can't access data the lexer's already tossed out. That's where the
>current format format (so to speak) runs you into trouble.
Only if you insist on the identical syntax as it ha
> Functions like stat() and get*ent() return long lists of mysterious
> values. The implementation is assumedly easy: just push some values
> out of C structs into the Perl return stack.
. . .
> Firstly, who can remember which one of the stat() return values was
> the atime is or which is the 4t
/--- On Fri, Aug 04, 2000 at 05:58:44PM +0100, Piers Cawley wrote:
| > At 02:31 PM 8/4/00 +0200, dLux wrote:
| > > My suggestion is: declare "eval $scalar" as a bad guy.
| > It's not just string eval. It's also do FILE and require.
| > It's a powerful construct, though, and I wouldn't declar
Damian Conway <[EMAIL PROTECTED]> writes:
>
>> That's cool. I can also see calling a package's CLONE sub if you're
>> cloning something blessed into it.
>
> I like it. And CLONE is preferred to the specified (2nd arg) handler.
The newly released Storable-0.7 support this. Currently
[EMAIL PROTECTED] (Johan Vromans) writes:
> > A list of date/time values is returned. The ordering and format of these
> > values has been radically changed to reflect what most of us probably
> > view as "ordinary":
> >
> >($mday, $mon, $year, $hour, $min, $sec, $msec, $nsec,
> > $wday,
At 06:23 AM 8/7/00 +1000, Damian Conway wrote:
>
>> That's cool. I can also see calling a package's CLONE sub if you're
>> cloning something blessed into it.
>
>I like it. And CLONE is preferred to the specified (2nd arg) handler.
I'm tempted to say toss the second parameter entirely. If
> shadow $/ = "\n";
>
> seems to have the right implications to me.
Personally, I like this by far out of all the suggestions I've heard.
"save" seems to say "save THIS value" (the one you're setting, not the
global one you can't see). "hide" is a little too general (hide what in
what?). But
> I *really* like this idea. There should also be a default CLONE for
> the majority of classes that just want ordinary deep copying on
> whatever object representation they're using.
UNIVERSAL::CLONE.
Damian
> That's cool. I can also see calling a package's CLONE sub if you're
> cloning something blessed into it.
I like it. And CLONE is preferred to the specified (2nd arg) handler.
> Presumably it'd get the original
> as a parameter and return the new thing, or something of the so
At 04:13 PM 8/6/00 -0400, Dan Sugalski wrote:
>At 05:31 AM 8/7/00 +1000, Damian Conway wrote:
>>> >Another one for my wish list: deep copying support built in. A devil
>>> >inside me thinks this should be a new assignment
>>> >operator. Damian? Sounds like this is up your alley. I
> > The C<$time> specifier can be followed by a C<$timezone> argument,
> s/<$time>/<$format>/
Ooops! Thanks. :-)
> Allow numeric (e.g. minutes? seconds?) displacement?
> This would also allow
>
> $tomorrow = date(undef,undef,24*60*60);
Good call. The function could use a string as a timezon
At 03:30 PM 8/6/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 02:09 AM 8/6/00 -0400, Chaim Frenkel wrote:
> > > uplevel 0, $Perl:Warnings=1;# Hit everyone
> > > uplevel -1, $Perl:Warnings=0; # Hit my wrapper
> > Yeah, I can see that. We're going to need a mechanism to
At 05:31 AM 8/7/00 +1000, Damian Conway wrote:
>> >Another one for my wish list: deep copying support built in. A devil
>> >inside me thinks this should be a new assignment
>> >operator. Damian? Sounds like this is up your alley. I want to do a
>> >sanity check before taking up
> If $object is typed (my Date $object), then want() will be able to detect the
> difference.
I actually just put in an additional RFC on this as well. Check it out
for more details when it comes out.
Basically, as I said in the date() RFC, we'll be able to work this out
somehow, I'm sure.
-Nat
> On Sun, Aug 06, 2000 at 01:41:06PM -, Perl6 RFC Librarian wrote:
> >
> > $scalar = date; # scalar ctime date, same as current
> > $object = date; # object with accessor functions (new)
>
> How are these distinguished?
If $object is typed (my Date $object),
Dan Sugalski wrote:
> At 02:09 AM 8/6/00 -0400, Chaim Frenkel wrote:
> > uplevel 0, $Perl:Warnings=1;# Hit everyone
> > uplevel -1, $Perl:Warnings=0; # Hit my wrapper
> Yeah, I can see that. We're going to need a mechanism to hoist things to
> outer scope levels internally (f
> >Another one for my wish list: deep copying support built in. A devil
> >inside me thinks this should be a new assignment
> >operator. Damian? Sounds like this is up your alley. I want to do a
> >sanity check before taking up RFC space.
>
> Regardless of how this looks,
On Sun, 6 Aug 2000, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] (Johan Vromans) wrote:
>
> > I'd argue that
> >
> > ($year, $mon, $mday, $hour, $min, $sec, $msec, $nsec,
> >
> > is much easier to remember, since it is a series of continuous
> > decrasing
Jeremy Howard wrote:
> (..-1) == map -__ (1..);
That really confuses me. If the sequence (-4..-1) is (-4, -3,
-2, -1) then I don't see how your semantics are consistent. I'll
admit (reverse map -__ (1..)) is the same as (..-1) but reverse
on a stream is undefined. (It should be a run-time error
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> The C<$time> specifier can be followed by a C<$timezone> argument, which
> returns the date relative to that timezone. By default, the time is
> returned relative to the local timezone. You can get UTC, for example,
> by specifying C or C as the t
At 01:15 PM 8/6/00 +0200, Johan Vromans wrote:
>Peter Scott <[EMAIL PROTECTED]> writes:
>
> > @a = @b || @c should 'work'. In P5 it puts @b in scalar context and
> > thus evaluates as the number of elements in @b if there are any.
>
>Define 'work'.
See RFC 45.
> if (@b) { @a = @b } else { @a
At 02:09 AM 8/6/00 -0400, Chaim Frenkel wrote:
>Then a mechanism for uplevel manipulation of variables should be used.
>
> uplevel 0, $Perl:Warnings=1;# Hit everyone
> uplevel -1, $Perl:Warnings=0; # Hit my wrapper
>
>(I think something better was proposed, but I don't recall
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> There are times when one may need (or desire) to change the shell used
> for interpretation, as well as force shell interpretation, regardless
> of optimization, for consitency's sake.
print `fancysh -c 'your uninterpreted and unoptiomized sh
In message <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Johan Vromans) wrote:
> I'd argue that
>
> ($year, $mon, $mday, $hour, $min, $sec, $msec, $nsec,
>
> is much easier to remember, since it is a series of continuous
> decrasing magnitudes.
I was thinking much the same. It also means
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
I like this proposal, although I do have a lot of remarks.
Consider them constructive!
> The C<$time> specifier can be followed by a C<$timezone> argument,
s/<$time>/<$format>/
> which returns the date relative to that timezone. By default, the t
> For any result of grepping (1..) (with a predicate which always
> terminates, say), you can do this. If C is
> nonempty, then it has a first element; we can find this first element
> by running essentially this:
>
> for(my $n=1; ; $n++) {
> last if g($n)
> }
>
> Note that this eve
On Sun, Aug 06, 2000 at 01:41:06PM -, Perl6 RFC Librarian wrote:
>
> $scalar = date; # scalar ctime date, same as current
> $object = date; # object with accessor functions (new)
How are these distinguished?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace localtime() and gmtime() with date()
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 05 Aug 2000
Version: 1
Status: developing
Mailing List: [EMAIL PROTECTED]
Nu
On Sun, 06 Aug 2000, [EMAIL PROTECTED] wrote:
> On Sat, Aug 05, 2000 at 09:14:49PM -, Perl6 RFC Librarian wrote:
> >=head1 TITLE
> >
> >Request For New Pragma: Shell
>
> Pragmas have lower case names by convention, so this should be "use
> shell".
Yes, it's lc 'shell' everywhere but the titl
Peter Scott <[EMAIL PROTECTED]> writes:
> @a = @b || @c should 'work'. In P5 it puts @b in scalar context and
> thus evaluates as the number of elements in @b if there are any.
Define 'work'.
if (@b) { @a = @b } else { @a = @c }
$a[$_] = $b[$_] || $c[$_] foreach (0..max(@a,@b,@c))
...oth
> The solution is simple: return hashes instead of lists.
Hash ref, I may hope?
localtime->{year}
-- Johan
> I agree with Tuomas' assessment. We would certainly love to dispense
> with
> the need for PDL if perl6 offered something along these lines.
> But PDL is much more than an efficient memory representation for typed
> N-D arrays. Above Jeremy suggests that most of the rest of the PDL core
> is alr
In message <[EMAIL PROTECTED]>
Edwin Wiles <[EMAIL PROTECTED]> wrote:
> Endianness:
>
> /d - default, whatever your system uses normally
> /n - network
> /b - big
> /l - little
> /v - vax
>
> (??vax is sufficiently different to require it's own?? Or is this to do
> with bit order?)
VA
On 4 Aug 2000 17:30:35 -, Perl6 RFC Librarian wrote:
>Some people have suggested that unlink() is too Unix
>centric, that that it should be renamed to something
>like delete() or remove().
Gosh, even on a Unix system, the command is "rm" and not something
exotic like "ul".
Why does Perl nee
1 - 100 of 107 matches
Mail list logo
