Damian Conway wrote:
Ah, but there's definitely a confusion as to whether it's *meant*
to be assignable.
What if I (as the class designer) want to give you read access but not
write access to an object's name?
I think this misses the mark. We're talking about functions, right?
:lvalue
Peter Scott wrote:
Can someone knowledgeable on this issue speak to it?
Will $| $/ $\ et al be retired, or be valid for some default filehandle?
Will there still be default filehandles?
There's been a big debate on the -io list about this. No clear decisions
yet, but looks like the
Larry Wall wrote:
Oh, gee, where's your sense of history? (As in creating our own. :-)
Maybe we should invent our own epoch, like the year 2000. Or use a
really standard one, like the year 0 AD (aka 1 BC).
I don't know about this. Sounds cool, but I think we should stick to
something that
Jonathan Scott Duff wrote:
Well, now it's my turn to suggest something ;- How about we give
perl the ability to look for a .perlrc file? (Yes, I know the reasons
against, but everything is up for grabs now right? :-)
If we do this, it should be off by default. csk/ksh make you turn it
Jonathan Scott Duff wrote:
standard like 0 AD isn't bad.
Standard for whom? I bet there are *millions* of Jews for whom "0 AD"
is meaningless. s/Jews/any other group of people who have their own
calendar that predates christianity/
Good point.
Unix epoch it is! :-)
-Nate
What does that mean? When the handler is invoked, what does it see?
$fh = open myhttp "http://www.perl.com", "fred", "barney";
Does that result in a call like this?
myhttp::open("http://www.perl.com", "fred", "barney");
Exactly. Or to be "more correct"
No posts we recorded on the mailing list perl6-language-unlink, which
was setup to discuss RFC 29.
As such, the issue is assumed closed per the existing RFC 29. It will be
frozen as-is.
-Nate
I'm not sure anyone does that much in the way of time/date work that it'd
make a difference. Besides, we're talking internal here--time() may still
return Unix epoch seconds for compatibility reasons.
Blah! I saw the prosal for an mjdate() routine and thought it was at
the language
Anyway, it doesn't matter; it's a lot more widely used than any other
epoch, and epochs are completely arbitrary anyway. What's wrong with it?
I think the "What's wrong with it?" part is the wrong approach to this
discussion. Personally, I'm a 100% UNIX head. All I work on is UNIX
(thank
And how do we make it easy to pass in a name to open?
In an email I sent to Jarkko off-list, I suggested this:
If we embedded full URI support into Perl, then people could write
portable scripts using URIs, or non-portable ones using native syntax.
*Internally*, both could be converted into
I think the idea that = is "just another comma" is pretty widespread
now.
Just for the record I've always thought this was stupid. That's just my
opinion, true, but there's a fine line between TMTOWTDI and pure
confusion.
IMO, if you're going to have a different operator, make it do something
Notice that the hours/mins are always padded but the rest isn't.
I think you meant minutes/seconds.
Yep, oops. Thanks.
if you're going to have an object interface, perhaps the constructor
can take the strftime string for use as the default scalar output?
That's exactly what happens:
With zip/unzip/partition
I really gotta say, those functions *need* to be renamed, for a variety
of reasons. First, they have well-established computer meanings
(compression, disks). Second, "partition" is too long anyways.
I've seen numerous emails from other people saying the same thing. If
# Open a remote webpage
$http = open http "http://www.perl.com/", GET;
^
1) The URL says that it's a http resource, so why do we have
to tell open to use a http handler?
a) Allows custom handlers:
open myhttp
[cc'ed on internals as FYI]
=item 36 (v1): Structured Internal Representation of Filenames
I think this should be discussed a good amount. I think URIs are cool,
but too much trouble for simple stuff. I don't want to have to write
"file:///etc/motd" everytime I want to address a file. Too
How would this take into account stuff like this:
sysopen(HANDLE, "/etc/motd", O_RDWR|O_CREAT, 0644);
The "O_RDWR|O_CREAT" part is what I'm talking about here. This is a
constant w/o suffix. We'll either have to:
1. Change it to $O_RDWR|$O_CREAT or $O{RDWR}|$O{CREAT}
Maybe for
Replace localtime() and gmtime() with date() and gmtdate()
I think to be politically acceptable to all that should be utcdate()
Me too. Actually, this was my first choice, believe it or not.
The problem is, many people on this list claimed that GMT != UTC, and
that machine time is only in
I know other languages call it zip, but personally I dislike
that name as zip() is commonly used with reference to compression.
Ditto, I really dislike zip() and unzip(). They're PC and even UNIX
commands on several platforms now, increasing confusion.
Here's two names: mix() and unmix().
well, if it is only a string, why use . as the separator? use something
else like : and no one will try any fancy math tricks on it.
Agreed. I like :, it's a common separator.
Also, how about just $@-id? Shorter and I would argue the "unique_" is
really redundant (id's are usually unique,
The difference is how they group:
@unzipped_list= unzip(3, (1,2,3,4,5,6)); # ([1,3,5],[2,4,6])
@partitioned_list = partition(3,(1,2,3,4,5,6)); # ([1,2,3],[4,5,6])
Let me make an observation, having done tons of matrix stuff: We're
going to wind up with 200 functions, all of which
Chaim Frenkel wrote:
"NW" == Nathan Wiger [EMAIL PROTECTED] writes:
NW Also, how about just $@-id? Shorter and I would argue the "unique_" is
NW really redundant (id's are usually unique, hence the name
NW "identifiers").
Not really.
Consider: Chaim is
point: the convention of the upper case name indicates that they
probably will be called automatically. "import" does not adhere to that
convention.
Don't get me wrong, I'm all for it. I just thought the RFC glossed over
some important details so was trying to clarify some facts. They should
How about any variable created in UPPER case is a constant?
Well, Perl does something similar now, just that they're not readonly.
But as everyone knows messing with @ISA, %ENV, BEGIN, FETCH, etc, etc,
etc will definitely alter your program.
Do we really need constants in Perl? I've always
Proposal to rename Cimport and Cunimport
The problem with this is that they rely on the indirect object notation,
same as new(). So:
import Module; # calls Module-import
new Module;# calls Module-new
bob Module;# calls Module-bob
So import and unimport aren't
How about this?
open '/etc/passwd'; # file
open '/usr/local/bin/'; # directory (note the trailing '/')
open 'ftp://ftp.perl.org/'; # ftp
open 'http://www.yahoo.com/'; # http
open 'ldap://ldap.bigfoot.com/';# ldap
I think
This is nutso... shall we open-ssh and open-telnet and
open-any_protocal_under_the_sun in the core?
Well, just because the hooks are there doesn't mean all the member
modules have to be in core. The idea would be, as Tom Hughes suggests:
That is if the core provides a way for modules to
I think, if you look in the archives and the Camel, you'll find that turns
out not to be the case.
I really don't like putting words in other people's mouths, so I'll
refrain. However, I have read comments from Larry and others in Camel
and perl5-porters that say something akin to this:
1.
I do agree that the internals shouldn't drive the language (otherwise a
crack team of Ninja would've already taken care of that Conway guy... :),
but neither can they be completely ignored.
Agreed. Which reminds me, we should call off those Ninja... :-)
Honestly, I'd rather you put
True.
I wonder if we could change '=' to always quote the lhs, even if
prefixed by '$', '@', or '%' (maybe we should only enable this
behaviour inside parameter lists?) That would allow us to do this.
That's gonna take some digestion time.
In the meantime, is there a reason the
Er, I thought we were talking about setting named parameters, not
default values.
sub foo ($name = 'Fred', $age = 32) { # defaults
# do stuff with $name and $age
}
foo('Barney', 31); # Positional assignment
foo($age:31,
While I think Time::Object is a really great module, and following these
discussions I'm thinking of adding a date() function to it
Aaah! Please don't. :-) Name it something else, por favor (or at least
wait until this is finalized and make the interface the same).
date arithmetic...not
How usable is this ?
I may be missing something, but if every variable mentioned in an anonymous
block is assumed to be declared with my, then how do you access or modify
the value of any variable outside the block ?
Graham.
I knew someone was going to ask this; after I sent it I
fluid-let should *really* be called `now'),
Agreed (about the `now' part)
Will this also apply to `use scope 'subs''?
No. Only subs are affected, which is a clear and easy dividing line I
believe.
I, for one, will *never* use such a construct. It provides the user
with the dangers of
Do you mean the whole thing, or just the `blocks' part?
Any feature which subverts "use strict" by attempting to declare my
variables for me. In this case -- `blocks'. But also `subs' scope,
since that makes anonymous subs useless.
As the RFC notes:
=head2 Incompatibility with strict
If you're going to use a convention, rather than a syntax, then the current
convention of all CAPS reserved to Perl is easier to understand, more
pleasing to the eye, and backwards compatible.
Good point. Maybe we're getting a little "fix-happy". :-)
-Nate
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
But surely not as a part of the core language?
Exactly. In fact, I'm going to chop a lot of the original proposal out.
It's too bloated for core.
There's a lot of cool time/date stuff, but
So is this a consensus?:
It is proposed that Perl introduce a new prefix '^', which indicates a
placeholder. This can be used in any of the following ways:
- ^identifier: named placeholder
- ^_: anonymous placeholder
- ^0, ^1, ...: positional placeholder.
I think this sounds good -
I'd agree to the contrapositive: if we have named placeholders, I don't see the
need for positional ones too. But I'm willing to be convinced. The below, with
positional only, is total gibberish, as Ken points out.
To most, probably, but I say let the user decide. Like Jeremy points
out:
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
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
Yes! Yes!
How about using a float (fractional second) instead of $msec, $nsec.
Works for me (it's for you anyways). ;-)
-Nate
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
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,
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
$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
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
Personally, I don't think I've ever used any of these, but I really
don't want to speak for everyone.
Maybe an RFC "Functions and Variables to Remove in Perl 6" ?
-Nate
Jonathan Scott Duff wrote:
Here in my pre-caffiene morning trance it occurs to me that a few of
the "fringe" features of
Probably not with tie, but with function calls in general, sure. We can do
some flow control analysis on the subs and propagate it outwards so we
might know, for example, that:
sub foo {
my (@vars) = @_;
return scalar @vars;
}
doesn't change its args or any globals, so
Thats just because IO::Socket is done wrong
Maybe we should address this? If we're keeping syscalls just because a
possible replacement module is just written wrong, we should fix this.
I don't like giving up low-level control either, but imagine something
like this:
$port = shift ||
IME, I find it more dangerous to do behind-the-scenes hand holding than
to simply teach them the hows and whys of the "right way."
Exactly.
The key word above is "encourage". You're not really encouraging
anything - you're now having the language mandate particular constructs,
without
Tom Christiansen wrote:
Thats just because IO::Socket is done wrong
Maybe we should address this? If we're keeping syscalls just because a
possible replacement module is just written wrong, we should fix this.
Why would we ever remove a syscall!?!?
Sorry, wrong verbage. I meant "the
I say this as a Unix weenie, albeit a Unix *user* rather than a Unix
*programmer*. I'm quite used to navigating the Unix filesystem but,
having never braved Unix systems programming, had no conceptual link
between deleting/"rm"ing files, and the term "unlink". It tooks me
quite a bit of
Sorry for the broadcast, but anyone else having problems with perl6-rfc?
I sent two separate RFC's in from separate mail servers but haven't seen
anything happen with them. It's been a good hour, too.
Thanks,
Nate
I think this is a good candidate for recording why we decided not to do
something.
Did we even reach consensus on how to do this? Put a Status: header in
VERSION?
For recording purposes, maybe once the Status: line is added we should
add an additional section. Maybe STATUS, JUSTIFICATION,
I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of this change
First off, I think this is a great idea in principle. However, I don't
think it goes nearly far enough in the implementation. I'd like to
propose something
sysopen() should probably be included in the list as well.
Good point.
-Nate
What lexical scope should $x be _implicitly_ declared in? Maybe, just
maybe, we need a my $x at the top to tell us it is outside the scope of the
first reference. Otherwise we get three different lexical variables, and an
undefined value warning at run time.
You're right, great point.
Are you saying they don't look Perlish now?
And no, all you guys, I'm not trying to shoot down a monadic,
object-returning open. Please don't assume that.
As funny as it sounds, yes. Mind you, they're not really too weird. But
compared to how most other functions have turned out working,
In fact, you may as well go the whole way and say that all IO is done via
optimised IO objects (ie include sockets etc). IO::File and friends
without the overhead. All of the current open functions simply pass these
objects around.
I'll stick this in there, definitely. This is just what I
if (want 'hash') { return %hash } # rather than eq
I like this alot.
-Nate
I'd've written that more like
$data_axed = chop($var);
$charcount = chomp($var);
Or something. People really do find those two functions confusing.
Is this something we'd like to address by having versions that don't
take LVALUES?
I don't know. It is true that this is somewhat
The suggestion was the open() return a filehandle object, so may
I suggest
$fh = open("| cat -v | sort | lpr") or die ;
$pid = $fh-pid;
I like. I'll add it.
Version 2's gonna be *huge*...
-Nate
Fair enough. If we were going to do it I would like to see it extend to:
sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
}
Is there an RFC for this yet? If not, I think there needs to be. I think
this would be really cool.
Because it has opportunity for bloat, I would suggest it
=head1 TITLE
Keep default Perl free of constraints such as warnings and strict.
I second this. If the current definition of "lexical" remains unchanged
(which I strongly suspect it will), I think Perl should remain loosely
typed by default. Make people add
use strict;
use warnings;
Besides, named arguments will solve this (in fewer chars even :-)...
$user = 'nwiger';
sub whois ($user) {
# ...
}
Damian
Great point. I'll "settle" for that (it's what I'm looking for anyways).
:-)
So will these be "automatically-my()ed"? Or will you
1. put their hands up to write the "up for grabs" RFCs
I'll grab:
unlink() renamed
I believe the "Renaming line noise" one is already covered in RFC 17.
The localtime() one's still coming, I promise! It'll be good (I hope),
lots of great input.
I'm *very* close to suggesting a "strict"
Several people have requested strong typing as a feature, but have been shot
down with reasons such as "it's un-Perl-like", with an added "it'll slow
everything down for those who don't want it".
Definitely.
Unfortunately, accessing and manipulating tied variables is incredibly slow,
so
Wanted to get this out as an idea that could encompass lots of the
concerns I'm seeing about warnings and such:
=head1 TITLE
Warnings and Tainting should be reimplemented as pragmas.
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 2 Aug 2000
Version: 1.0
Mailing-List: perl6
Warnings and Tainting should be reimplemented as pragmas.
What part of warnings(3) and perllexwarn(1) are you in disagreement with?
Not yet fully-versed on everything having todo with 5.6, appears I made
a bit of an oversight (i.e., as you mention 'use warnings' is already in
5.6)! So while
No: lists are the plural whatzitzes, containing zero or more singular
whatzitzes. They are ordered. Arrays hold lists.
I tend to agree with Tom's argument here. open() is kind of funny
anyways. Why couldn't it work like this, similar to FileHandle:
$fh = open $filename;
print $fh
Reimplement Warnings and Tainting as Pragmas
Nathan Wiger [EMAIL PROTECTED]
You can delete this one. 'use warnings' is already in 5.6 (sorry!) and
tainting looks near-impossible (thanks Larry for the insight!). I might
(after tons of research) resubmit something on tainting
Um, what stops open returning undef on failure (and setting $!), so I could do
$fh = open $filename or die "open $filename failed: $!\n";
Exactly. You don't lose anything because open() will still return "true"
(a handle) or "false" (undef).
-Nate
Tom Christiansen wrote:
Except that you can test for failure by checking to see if $fh is defined.
Let your true be true and your false be false.
open($fh, "", $filename) || die;
--tom
Not sure I agree with that. I think one point of confusion / perceived
difference between
=head1 TITLE
Modify open() and opendir() to return filehandle objects
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 2 Aug 2000
Version: 1.0
Mailing-List: perl6-language
=head1 ABSTRACT
Currently, open() and opendir() are given handle arguments, whose values
are twiddled
Please don't reply to this one or threadlists will be screwed up! Reply
to the second (auto-generated) one later in the perl6-language mailbox.
(Hit the button a second before Nat's email! Oh, well...)
Nathan Wiger wrote:
=head1 TITLE
Modify open() and opendir() to return filehandle
Ariel Scolnicov wrote:
Unfortunately, this would mean your example above doesn't quite work.
One possibility is to say that $^T controls taint *checking*, but not
tainting itself[1]!
This is actually a good distinction that's worth some more discussion.
One could set the implementation so
C is, at times, less than logical. Witness the localtime fun: some of it's
zero-based, some of it's one-based, and some of it's -1900-based. All from the
same function. The localtime concept is needed, the localtime brain damage is
really not.
I agree completely. I take issue with changing
Another note: your examples with:
local ($^T) = 0;
$ENV{PATH} = read_config_file();
local ($^T) = 1;
is only using local() to confuse; it should be written with a block,
correctly restoring the old value of $^T.
Sorry about that - I contemplated taking it out
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 31 July 2000
Version: 1
Mailing List: perl6-internals
Number: 1
=head1 Abstract
Currently, Perl requires that tainting be invoked along with the Perl
interpreter, via the -T switch. It would be nice if tainting could be
turned on and off
301 - 380 of 380 matches
Mail list logo
