"Jeremy Howard" <[EMAIL PROTECTED]> writes:
> Ariel Scolnicov wrote:
> > <...infinite lists...>
> > This (and your preceeding messages on the subject) is unfortunately
> > not possible to do in a clean manner; for that matter, neither is the
> > (..0) proposal. The I in which results are produce
On Sun, 6 Aug 2000, Dan Sugalski wrote:
> At 01:21 AM 8/6/00 -0400, Chaim Frenkel wrote:
> >I think there are two problems. One is the naming convention, the
> >second, the global effects.
> >
> >Why not split them. The names could be improved.
> >
> >And the global nature (of the name) abolished
> Ariel Scolnicov wrote:
> Consider C. Clearly, this
> "should" generate the "list" C<(..0)>. But it doesn't! Here's what
> really happens: Perl says to itself "1 is not nonpositive, 2 is not
> nonpositive, 3 is not nonpositive, ..."; it B reaches the point
> where it starts saying "0 is nonpos
Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 10:55 AM 8/2/00 +0200, Gisle Aas wrote:
> >>All functions that return time values (seconds since epoch) should use
> >>floating point numbers to return as much precision as the platform
> >>supports. Al
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 09:34 PM 8/5/00 +, Nick Ing-Simmons wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> writes:
> > >At 10:55 AM 8/2/00 +0200, Gisle Aas wrote:
> > >>All functions that return time values (seconds since epoch) should use
> > >>floating point numbers to ret
"Jeremy Howard" <[EMAIL PROTECTED]> writes:
> > Ariel Scolnicov wrote:
> > Consider C. Clearly, this
> > "should" generate the "list" C<(..0)>. But it doesn't! Here's what
> > really happens: Perl says to itself "1 is not nonpositive, 2 is not
> > nonpositive, 3 is not nonpositive, ..."; it B
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
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
> 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
> The solution is simple: return hashes instead of lists.
Hash ref, I may hope?
localtime->{year}
-- Johan
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
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
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.
> 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
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
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:
> 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
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
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
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
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
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
> >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,
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
> 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),
> 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
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
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
> > 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 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
> 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
> 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
> 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
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
[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,
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
/--- 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
> 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 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, 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
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 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
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
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
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()
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
> 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?
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
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
> 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
> Yes! Yes!
>
> How about using a float (fractional second) instead of $msec, $nsec.
Works for me (it's for you anyways). ;-)
-Nate
> > $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
> (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:
> 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
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
> 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
> 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
> 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
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
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
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
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
> 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,
> 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
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?
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
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(__
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?
> > 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
> >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?
> 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
Okay. I'll rework the proposal with the consensus syntax.
Damian
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
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
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
> 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
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
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
> 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
[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 necessaril
> > 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
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
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
> $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
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
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
> 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
> >{
> > 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
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
> 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
> > 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!
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
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
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
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
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
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:
> 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
"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
1 - 100 of 107 matches
Mail list logo
