"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 Iorder in which results are produced
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.
I'm not
Ariel Scolnicov wrote:
Consider Cgrep {$_ = 0} (1..) . (map {-$_} (0..)). 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 Bnever reaches the point
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. All functions
"Jeremy Howard" [EMAIL PROTECTED] writes:
Ariel Scolnicov wrote:
Consider Cgrep {$_ = 0} (1..) . (map {-$_} (0..)). 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
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?)
VAX is either
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 already
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))
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.au/
For any result of grepping (1..) (with a predicate which always
terminates, say), you can do this. If Cgrep { g($_) } (1..) 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
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 time
is
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 you can
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 shell
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 what
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 CUTC or CGMT as the
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 magnitudes.
I
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, it has
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 (for
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 RFC space.
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 timezone, or a number
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 I
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 the
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 deep
/--- 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 declare
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 4th
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.
print
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
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. (It
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
At 11:36 PM 8/6/00 +, you wrote:
I suggest that objects provide a default method called CSCALAR that
determines what they produce in a scalar context. When stringified, an
object would automatically call its CSCALAR function and return the
correct value.
I don't see in here how an object
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 own
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 with
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 why the
(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 one
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 discussion,
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 -
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-order
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]
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
it
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?
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?
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 you use it
Okay. I'll rework the proposal with the consensus syntax.
Damian
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
[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 Chide ?
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
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). Have a
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
$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 see
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
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 misleading.
I
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!
Seems to me
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 has
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 perhaps
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 Chide ?
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 in.
"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 encourage
"Jeremy Howard" [EMAIL PROTECTED] writes:
Oops, a correction. [..] should mean 'the set of all integers'. _Not_ the
univeral set. So my code snippet should be:
@i = [..];# @i contains the integers
$s = sum (grep 0__=100 @i);
print "The sum of the 1st 100 integers is: $s";
Tuomas Lukka wrote:
Do we really need PDL objects in perl 6? How about we investigate building
compact arrays into the language? We're already talking about how we can add
typing to the language--I would have thought that if these semantics make it
in, we could look to optimise how
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 Iorder in which results are produced depends on
the order in which you generate the
70 matches
Mail list logo
