Glad to see the tide of sentiment towards making strictness the default
:-) To feed my personal fetish for optional site policies prohibiting
disabling certain strictness, can anyone enumerate circumstances when you
*cannot* currently achieve something desirable under one of the
On Wed, Aug 02, 2000 at 07:36:09PM +0100, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Gisle Aas [EMAIL PROTECTED] wrote:
The upcoming Python (v2.0) introduces a builtin called zip() that does
the same thing:
for a,b,c in zip(aa,bb,cc):
...
There are also
On Thu, Aug 03, 2000 at 06:31:38AM +, Martyn J. Pearce wrote:
And I feel that by being able to iterate over lists with map, grep,
fold[rl]/reduce{,_r}, whatever, _without pre-flattening the list_, we
could drastically increase the applicability of these constructs.
Having iterators
On Aug 2, 4:37pm, Ted Ashton wrote:
With all due respect, it appears that you are trading two characters for
six with little to show for it. Currently, we have
@array -- the array as a whole
[...]
$array__list -- the array as a whole
I didn't make that part clear. I was simply
Graham Barr said:
...
So there probably should be an RFC to add iterators to the language and
be avaliable from perl, not just C. But I have no idea how they
should look etc.
More generally, I wonder whether there should be an RFC on the changes
required to make perl a more friendly
...and have some_func know it is being called in an iterator context
and be able to create it's own iterator. foldr could then be
done as...
I think may have not only list,scalar,iterator context. But some way to
define CONTEXT itself, I don't have idea how ?
array context, boolean
Actually, open() currently CAN have just one parameter. What it does, is
use a filehandle and a scalar variable with the same name, so
Nope. Get rid of it! (p.s. Has anybody ever actually used this feature,
Yes, of course. That isn't an argument for its persistence, however.
--tom
Modify open() and opendir() to return filehandle objects
Here are some things that that will be a problem for:
open(SESAME, "| output-pipe-command") # set up an output filter
open(SESAME, "input-pipe-command |") # set up an input filter
open SPOOLER, "| cat -v | lpr -h
On Thu, 3 Aug 2000, Hildo Biersma wrote:
Reply
I'd either leave that as (localtime)[3,4,5] (please read the man page for
Time::Object), or understand that there's absolutely no need to separate
off the variables like that in an object oriented interface:
Ah, but we could make the
I'd either leave that as (localtime)[3,4,5] (please read the man page for
Time::Object), or understand that there's absolutely no need to separate
off the variables like that in an object oriented interface:
my ($day, $month, $year) = (localtime)[3,4,5];
becomes:
my $date = localtime;
On Thu, Aug 03, 2000 at 06:27:13AM -0600, Tom Christiansen wrote:
It seems that this issue is definitely worth a quick RFC - something
like "proposal to return filehandles from open/opendir rather than supply
as arguments".
What about the pids that come back from begotten processes, as in
On Thu, Aug 03, 2000 at 06:57:27AM -0600, Tom Christiansen wrote:
On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote:
Modify open() and opendir() to return filehandle objects
Here are some things that that will be a problem for:
I did not see any that would be a problem.
On Thu, Aug 03, 2000 at 06:39:02AM -0700, Randal L. Schwartz wrote:
Nope. Sometimes my brain prefers the EXPR if EXPR form because of
the much smaller punctuation footprint. Removing the comma
doesn't seem to serve anything but making Perl less powerful, and
not confusing Chaim quite as
On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
If functions could distinguish between
'wantarray' and 'wanthahs' this would be easy to do.
Due to the recent "rename local()" and "can't return an array"
discussions here, we should also consider "rename wantarray()"
as well.
Graham Barr wrote:
I was simply repeating a conversation. I was not implying any
name. If many other languages call it zip() then lets call it zip()
No, we can't call it zip, because that's what python calls it;
and that would make perl equivalent to python.*
[*being facetious. hopefully
On Thu, Aug 03, 2000 at 10:02:44AM -0400, Tad McClellan wrote:
On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
If functions could distinguish between
'wantarray' and 'wanthahs' this would be easy to do.
Due to the recent "rename local()" and "can't return an array"
On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
Ah, but we could make the language support this:
localtime-{'day', 'month', 'year'}
in hash-slice fashion.
That's really scary and I like it a lot.
That already has a meaning, thank you very much. :-(
--tom
[EMAIL PROTECTED] wrote:
Perl's similarity to English is one of the things that makes it Fun.
OTOH, being fun (which I admit it is) is one of the reasons many
people don't want to think Perl is a serious language.
So what?
--tom
On Thu, Aug 03, 2000 at 11:15:17AM -0400, Clayton Scott wrote:
Why not context()?
Sure, that works too. Although for want(), I can see this instead:
if (want 'hash') { return %hash } # rather than eq
and that reads better than
if (context hash) { return %hash }
Hmm.
want = 'hash';
On Thu, Aug 03, 2000 at 12:51:10PM +1000, [EMAIL PROTECTED] wrote:
Programer Modifiable Warnings and Error Messages
Brust, Corwin" [EMAIL PROTECTED]
. . .
Removing/fixing $[line noise here] variables
Corwin Brust [EMAIL PROTECTED]
That second is actually mine. Barring
Bart Lateur wrote:
On Wed, 02 Aug 2000 12:22:09 -0700, Glenn Linderman wrote:
[ 'bar' = 'integer32', 'baz' = 'integer32', 'count' = 'integer32' ]
[ 'var1' = 'int32', 'var2' = 'int16', 'var3' = 'int8' ]
That doesn't reconsider BigEndian vs. LittleEndian, AKA pack/unpack 'N'
vs.
The message below gives the context for this diatribe.
A perl script is probably written in a particular language, probably for
users of that language, possibly for users of a second language. Unless
there are lots of I18N type features added into Perl to allow extracting
all string constants
Glenn Linderman wrote:
Stick with characters in the normal character set of the author of the
script, except for forays into the language of the users of the script.
Good advice for the programmer, perhaps; but it should not be perl's
job to enforce that discipline.
--
John Porter
Tom Christiansen wrote:
OTOH, being fun (which I admit it is) is one of the reasons many
people don't want to think Perl is a serious language.
So we shouldn't argue for a feature simply because it's fun,
especially when the counterargument includes increased acceptability.
--
John Porter
Thus it was written in the epistle of Andy Wardley,
I'm not assaulting Perl's flexibility or syntax. Nor am I suggesting
that you, Randal or anyone else is particularly confused by this. I'm
simply making a Request For Comments on a suggestion on how some of
Perl's syntax might be made
John Porter wrote:
Glenn Linderman wrote:
Stick with characters in the normal character set of the author of the
script, except for forays into the language of the users of the script.
Good advice for the programmer, perhaps; but it should not be perl's
job to enforce that discipline.
..at least if new newsgroups appear, you get notified about it!
Speaking of which, I believe the plan was to announce new list
creations on perl6-announce; can someone confirm that this is
actually happening?
--
John Porter
At 09:01 AM 8/3/00 -0600, Tom Christiansen wrote:
On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote:
No, that's gross. A failed constructor should return undef. See my
later message.
That has always been my view. But then people say "but why did it fail"
and having global
From: John Porter [mailto:[EMAIL PROTECTED]]
..at least if new newsgroups appear, you get notified about it!
Speaking of which, I believe the plan was to announce new list
creations on perl6-announce; can someone confirm that this is
actually happening?
I'm getting them.
John
At 11:00 AM 8/3/00 -0400, Dan Sugalski wrote:
At 03:03 PM 8/3/00 +0200, Johan Vromans wrote:
On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
If functions could distinguish between
'wantarray' and 'wanthash' this would be easy to do.
This reminds me -- once there was a proposal
Larry Wall [EMAIL PROTECTED] writes:
Theoretically, we'd like to make subs run as fast as ops.
I'd say that the distinction between subs and ops should be dropped
completely. Ops can be used as subs, subs as ops. The only
distinction in the way either is used.
We may need a better way to
Damian Conway [EMAIL PROTECTED] writes:
Of course, that example might in itself be sufficient reason
to completely redesign the regex syntax!
Perl uses the term "pattern matching" since day one. This opens the
possibility of extending pattern matching with other, not neccessarily
regex based,
Dan Sugalski [EMAIL PROTECTED] writes:
More importantly, the more primitives that perl provides, the wilder
and more useful things people will be able to do.
Not quite. Its the functions that are provided that matter, not
whether they are primitives or not[1]. A small set of primitives with a
Thanks for the feedback, everyone. I now believe that what we
really want is what so many have suggested, i.e., making strict 'vars'
the default (in essence, at least).
I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of
On Thu, Aug 03, 2000 at 09:39:30AM -1000, Tim Jenness wrote:
Reading through the docs for perl prototypes I see that there is a
reference to "named parameters" being a possibility in future versions of
perl.
Does anyone have a more concrete example of what was intended there?
sub marine
If we were to agree to make the basic syntax of open() something like:
$object = open [$filename], [$class];
There's a lot of cool stuff we could do. In the simplest "mostly looks
like Perl5" cases, open() can work like shown above. In fact, I'd be
plenty happy with just this, since it makes
This is not quite finished yet, as I read the rest of the C-- garbage
collection paper.
-John
=head1 TITLE
Elements of @_ should be read-only
=head1 VERSION
Maintainer: John Tobey [EMAIL PROTECTED]
Date: 3 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number:
=head1
At 08:18 PM 8/3/00 -0400, John Tobey wrote:
Unprototyped subs should not be allowed to modify their callers' data
simply by assigning to elements of the arg array. This form of
passing by reference is obsolete now that Perl has hard references and
C\$ in prototypes. The feature is confusing,
I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of this change,
meaning that in future Perl documentation (books, manpages, classes (I
hope)) new Perl users will first be presented with variables declared
as lexicals with
While a function style or quoted form
comment might seem clever, and even Perlish due to its syntax, it doesn't help
the author of the code/comments readily distinguish them. What good are
comments if you can't find them when you need them?
Sounds like an argument for :10,20s/^/###/ style
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
On Thu, 3 Aug 2000, Nathan Wiger wrote:
sysopen() should probably be included in the list as well.
Good point.
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
What would be the method to _avoid_ emitting something?
What would be the result of
open(Foo, "Bar")# Prints FILEHANDLE=0xdeadbeef
$x++; # Prints 3
What makes something a 'real' void so that it would print. Vs. not
having something that would catch the
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
Nathan Wiger writes:
I argue we should fundamentally shift this thinking in Perl 6. Let's
truly have "lexical variables made default".
Ugh. Baby, bathwater.
If I'm writing a big program, then I want to have to declare all
variables so that Perl can catch errors for me. That's the big
Thus it was written in the epistle of Nathan Wiger,
I don't know of an easy solution. I don't think we should touch chomp or
chop. Maybe someone should write a module that offers alternate versions
for those that want them?
How often does the return value from chomp or chop get used? The
=head1 TITLE
Lexical variables made default
=head1 VERSION
Maintainer: J. David Blackstone [EMAIL PROTECTED]
Date: 1 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 6
=head1 ABSTRACT
Prior to version 5, all implementations of Perl were designed with
only dynamic (global)
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
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.
I'll have a proposal out
However, I do think there's something to be said for a "quick-and-dirty"
script out of the box that can distinguish between sub{} vars and other
vars ala C:
$user = 'nwiger';
sub whois {
($user) = @_;# different var
# ...
}
=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
Peter Scott wrote:
I'll say up front that I have no good idea as to how to implement this,
hence the lack of RFC, but I think it's worth getting the ball rolling to
see if there's enough collective intelligence and inclination to make
something happen.
OO inheritance is well defined and
OK, here's my summary of language RFCs as they currently stand. As
I said before, this list will always be available from
http://infotrope.net/opensource/software/perl6/
I would appreciate if people could do the following:
1. put their hands up to write the "up for grabs" RFCs
2. work towards
Before jumping in on this, keep in mind that Larry Wall has already
stated his intent to just plain _eliminate_ many of these special
variables. Most of them suffer from the "action-at-a-distance"
problem, meaning you change something somewhere and unexpected changes
occur elsewhere.
For
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"
Ask, can we please have the following list:
Name: perl6-language-strict
Chairs: J. David Blackstone [EMAIL PROTECTED]
Daniel Chetlin [EMAIL PROTECTED]
Charter:Discuss the use of the strict pragma in Perl 6
Timescale: 2 weeks (finish August 18th)
On Wed, Aug 02, 2000 at 11:40:09PM +0100, [EMAIL PROTECTED] wrote:
On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote:
http://windows.oreilly.com/news/hejlsberg_0800.html
Impressive. Quite deeply impressive.
Careful! Don't be overwhelmed by the marketing spin. Don't
At 01:11 PM 8/3/00 -0500, Jonathan Scott Duff wrote:
BTW, I propose that RFCs have a Status: field as part of the VERSION.
Here are some possible values that I can see:
Status: accepted # we all agree that it should go in
Status: rejected # we all agree that it shouldn't go in
Status:
Tom Christiansen wrote:
#if 0
...
#endif
Ahem, has somebody already mentioned -P (perldoc perlrun)?
If you want 'em, you already got 'em!
I'm in the choir, preacher! IWTFM. :-)/3
--tom
Versions, dear boy. Versions. Don't forget versions.
We will need them.
(This really belongs on -internals. Reply-to: adjusted)
And while were here, does anyone understand kpathsea? Would it be a
win. I think it would.
chaim
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS lexer saw a
At 08:27 AM 8/3/00 -0400, Tad McClellan wrote:
On Wed, Aug 02, 2000 at 10:09:04PM -0600, Nathan Torkington wrote:
I'm about to push the button that will send my private set of RFCs
off to the archive and mail them to perl6-announce. Fingers crossed.
The RFC archive is at
What about updating RFCs? Should I increment the version number and send
each new revision to perl-rfc? Do I need to be careful about the RFC
number when submitting updates?
Also, I assumed the intention of the RFCs was to stimulate focused
discussion and to keep a record of the decisions made
Steve Simmons writes:
This idea is both important and more general. If we go thru a huge
discussion of, say, multi-line comments and decide *not* to do it,
we don't want to have the whole thing repeated with perl 6.1, 7.0,
etc, etc. When something reaches RFC stage but is rejected, part of
On Wed, Aug 02, 2000 at 10:09:04PM -0600, Nathan Torkington wrote:
In the future, if you want to submit an RFC mail it to
[EMAIL PROTECTED] only. The automated process will send it to
the correct list as well as to -announce. This will also prevent
perl6-librarian being CC:ed on followups.
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
On Thu, Aug 03, 2000 at 11:40:24AM +0900, Simon Cozens wrote:
On Wed, Aug 02, 2000 at 07:34:36PM -0700, Nathan Wiger wrote:
That Perl should stay Perl
Do we need an RFC for this? Seems like this is more of a "guiding
concept" that should be intergrated into everything. Just my opinion.
Matt Sergeant wrote:
[I might join perl6-language some day, but until then, please CC me on all
Time::Object related messages]
Original from="Bart Lateur"
On Wed, 2 Aug 2000 08:14:22 +0100 (BST), Matt Sergeant wrote:
I used to be a C programmer myself (well OK, I was a C++
74 matches
Mail list logo
