...@conway.org
To:Tom Christiansen tchr...@perl.com
CC:Larry Wall la...@wall.org
Date: Sun, 08 Jul 2012 07:17:19 +1000
Delivery-Date: Sat, 07 Jul 2012 15:19:09
Subject: Re: my subs and state vars
In-Reply-To: 22255.1341691089@chthon
X-Spam
Father Chrysostomos via RT perlbug-comm...@perl.org wrote
on Sat, 07 Jul 2012 18:54:15 PDT:
Thank you. So the bar sub seems to be closing over the name @a (the
container/variable slot/pad entry/whatever), rather than the actual
array itself.
Since I don't have it installed, could you tell
Darren Duncan dar...@darrenduncan.net wrote on Wed, 24 Aug 2011 11:18:20 PDT:
Smylers wrote:
Could we have underscores and hyphens mean the same thing? That is, Perl
6 always interprets illo-figut and illo_figut as being the same
identifier (both for its own identifiers and those minted in
I have two points. First, this excerpt from Synopsis 6:
The :m (or :ignoremark) modifier scopes exactly like :ignorecase except
that it ignores marks (accents and such) instead of case. It is equivalent
to taking each grapheme (in both target and pattern), converting both to
NFD
Has anybody specifically looked at how Perl6 regexes might map to
the various requirements of UTS#18, Unicode Regular Expressions?
http://unicode.org/reports/tr18/
I ask because to my inexperienced eye, quite a few perl6isms are
*much* better at this than in perl5 obtain, and so I wondered
Patrick wrote at 12:15pm CST on Wednesday, 10 November 2010:
Sorry if this is the wrong forum. I was wondering if there was a way to
specify unicode
categorieshttp://www.fileformat.info/info/unicode/category/index.htmin
a regular expression (and hence a grammar), or if there would be any
Patrick wrote:
: * Almost. E.g. isL would be nice to have as well.
:
: Those exist also:
:
: $ ./perl6
: say 'abCD34' ~~ / isL /
: a
: say 'abCD34' ~~ / isN /
: 3
:
They may exist, but I'm not certain it's a good idea to encourage
the Is_XXX approach on *anything* except Script=XXX
Exegesis 5 @ http://dev.perl.org/perl6/doc/design/exe/E05.html reads:
# Perl 6
/ alpha - [A-Za-z] + / # All alphabetics except A-Z or a-z
# (i.e. the accented alphabetics)
[Update: Would now need to be +alpha - [A..Za..z] to avoid ambiguity
with
· Quoth Larry:
˸ So let’s not make the mistake of thinking something
˸ longer is always less confusing or more official.
⋮ I already have too much problem with people thinking the
⋮ efficiency of a perl construct is related to its length.
So you’re saying the Law of Parsimony has its uses…
In-Reply-To: Message from Mark Overmeer [EMAIL PROTECTED]
of Thu, 27 Nov 2008 08:23:50 +0100. [EMAIL PROTECTED]
* Tom Christiansen ([EMAIL PROTECTED]) [081126 23:55]:
On Wed, 26 Nov 2008 11:18:01 PST.--or, for backwards compatibility,
at 7:18:01 p.m. hora Romae on a.d. VI Kal. Dec
In-Reply-To: Message from Darren Duncan [EMAIL PROTECTED]
of Wed, 26 Nov 2008 19:34:09 PST. [EMAIL PROTECTED]
Tom Christiansen wrote:
I believe database folks have been doing the same with character data, but
I'm not up-to-date on the DB world, so maybe we have some metainfo about
On Mon, 06 Oct 2008 at wee small hour of 02:20:22 EDT
you, Michael G Schwern [EMAIL PROTECTED], wrote:
Darren Duncan wrote:
[2] Num should have an optional limit on the number of
decimal places it remembers, like NUMERIC in SQL, but
that's a simple truncation.
I disagree.
Any
In-Reply-To: Message from Nicholas Clark [EMAIL PROTECTED]
of Sun, 05 Oct 2008 22:13:14 BST. [EMAIL PROTECTED]
Studiously ignoring that request to nail down promotion and demotion, I'm
going to jump straight to implementation, and ask:
If one has floating point in the mix [and however
In-Reply-To: Message from Michael G Schwern [EMAIL PROTECTED]
of Sat, 04 Oct 2008 02:06:18 EDT. [EMAIL PROTECTED]
Larry Wall wrote:
The status of numeric upgrades in Perl 6 is fine. It's rakudo that
doesn't do so well. :)
As another datapoint:
$ pugs -e 'say 2**40'
1099511627776
$
I'm still somewhat ambivalent about this, myself. My previous
experience with hyphens in identifiers is chiefly in languages that
don't generally have algebraic expressions, e.g. LISP, XML, so it will
take some getting used to in Perl. But at least in Perl's case the
subtraction conflict is
On Tue, Mar 02, 2004 at 10:01:11AM +1100, Damian Conway wrote:
: That's a *very* interesting idea. What do people think?
I think anyone who does full justification without proportional
spacing and hyphenation is severely lacking in empathy for the reader.
Ragged right is much easier on the
When you write:
(1..Inf) equal (0..Inf)
I'd like Perl to consider that false rather than having a blank look
on its face for a long time.
The price of that consideration would be to give the Mathematicians
blank looks on *their* faces for a very long time instead. Certainly,
they'll be
You can define is very easily: two lists are equal if the ith element of
one list is equal to the ith element of the other list, for all valid
indices i.
The problem is that you've slipped subtly from a well-known creature, like
1..10, a finite set of ten distinct integers, to a quite a
Unless I'm very wrong, there are more whole numbers than natural
numbers. An induction should prove that there are twice as many.
We're probably having a language and/or terminology collision. By natural
numbers, I mean the positive integers. By whole numbers, I mean the
natural numbers plus
The IEEE-float-style infinities are quite sufficient for most purposes
One thing I agree is that writing 1..Inf is a *bit* sloppy since the
range operator n..m normally produces the numbers i for which
n = i = m while n..Inf gives n = i Inf
but I can live with it
I could sure save
Maybe there will be a Perl 6 rule forcing the keys to be quoted, but it
won't be because of the no barewords rule. If there were such a rule, I
presume you'd also apply it to the LHS of =?
There is another way to resolve the ambiguity of foo meaning either
foo or foo() depending on current
More generally, it seems to me that you're hung up on the description
of "*?" as "shortest possible match". That's an ambiguous
Yup, that's a bit confusing. It's really "start matching as soon as
possible, and stop matching as soon as possible". (The usual greedy
one is, of course, "keep
Have you thought it through NOW, on a purely semantic level (in isolation
from implementation issues and historical precedent),
I've said it before, and I'll say it again: you keep using
the word "semantic", but I do not think you know what that word means.
--tom
POD, presumably. Or maybe son-of-POD; it would be nice to have better
support for tables and lists.
We did this for the camel. Which, I remind the world, was
written in pod.
''tom
No-one ever did suggest adding « and » to the list of matched delimiters
that q() etc support, did they? :-)
I did.
Does Unicode define bracket pairings for character sets? ducks
$ grep ^Prop /usr/local/lib/perl5/5.6.0/unicode/Props.txt
does not seem very helpful, but this may not be much of
- Done right, it could be easier to write and maintain
Strongly disagree.
- Why make people learn pod, when everyone's learning XML?
Because it is simple. It is supposed to be simple.
It is not supposed to do what you want to do.
In fact, it is suppose to NOT DO what you want to do.
- Pod
It really is not feasible to relax the pod
requirement that pod diretives begin with
an equals to allow them to begin with a
pound sign as well, for to do so would expose
an untold number of programs to unpredictable
effects. I also don't really see any advantage.
And yes, I'm sure I'm days
It is unreasonably complicated to do single-character
input in a portable fashion. We should therefore
include the Term::ReadKey module in the standard
distribution.
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the
I consider recursive regexps very useful:
$a = qr{ (? [^()]+ ) | \( (??{ $a }) \) };
Yes, they're "useful", but darned tricky sometimes, and in
ways other than simple regex-related stuff. For example,
consider what happens if you do
my $regex = qr{ (? [^()]+ ) | \( (??{ $regex }) \)
This RFC still has silly language that discounts what
has been said before.
1) It calls
uc($a) eq uc($b)
"ugly", despite their being completely intuitive and legible
to even the uninitiated.
2) It then proposes "eq/i" without the least blush, despite
how incredibly ugly and
As we sneak under the wire here, I'm hoping someone
has posted an RFC that alters the meaning of my/local.
It's very hard to explain as is. my is fine, but local
should be changed to something like "temporary" (yes, that
is supposed to be annoying to type) or "dynamic".
Visit our website at
Try thinking of it this way: it's only a bareword if
it would make use strict whinge at you. Thus, the
constructs you cited are all non-uses of barewords,
such as in use Foo or require Foo or Foo = 1, or
even $x{Foo}. And I have proposed (nonRFC) that
Foo-bar() also be not a bareword. Yes, I
I strongly agree with the opinion that we should try and get away from
special variables and switches in favor of functions and pragmas.
Witness 'use base' instead of '@ISA', 'use warnings', and so on.
Huh? Why??? Perl's use of @ISA is beautiful. It's an example
of code reuse, because we
So what's left?
print STDERR "Foo";
We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
through.
It is? I certainly hope not. It makes as much sense to
do that as to force a dollar sign on subroutines.
sub $foo { ... }
or
sub 'foo' { ... }
Heck, maybe
Certainly numbers should never be "zero-padded"!
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
This is screaming mad. I will become perl6's greatest detractor and
anti-campaigner if this nullcrap happens. And I will never shut up
about it,
either. Mark my words.
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the
./sun4-solaris/POSIX.pm:sub isatty {
./sun4-solaris/B/Deparse.pm:sub is_scope {
./sun4-solaris/B/Deparse.pm:sub is_state {
./sun4-solaris/B/Deparse.pm:sub is_miniwhile { # check for one-line loop
(`foo() while $y--')
./sun4-solaris/B/Deparse.pm:sub is_scalar {
./sun4-solaris/B/Deparse.pm:sub
You suggested:
file($file, 'w'); # is it writeable?
That's really insane. The goal was to produce code that's legible.
That is hardly better. It's much worse than is_writable or writable
or whatnot. Just use -w if that's what you want.
--tom
Visit our website at
grep -l Class::Struct */*.pm
Class/Struct.pm
File/stat.pm
Net/hostent.pm
Net/netent.pm
Net/protoent.pm
Net/servent.pm
Time/gmtime.pm
Time/localtime.pm
Time/tm.pm
User/grent.pm
User/pwent.pm
Please check those out for precedent and practice.
Visit our website at http://www.ubswarburg.com
This
One doesn't remove useful and intuitive syntax
just because Mr Bill never put it into MS-BASIC!
I merely passingly suggested that there be a
use English style alias for these. They are, however,
wholly natural to millions of people, and should not
be harrassed. (NB: 10 million Linux weenies
The -wd syntax (writeable directory) is nicer than file($file, "wd").
But anyway, there's hardly anything wrong with -w -d. Don't
understand
the complaint.
One thing I would really like to see is better security support. Look
at the Camel-III's security chapter, File::Temp, and the is_safe
Don't change "use less" to "use optimize". We don't
need to ruin the cuteness.
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate,
Goodness, no, don't call it "PRAYER". The blessing
is one of corporate approval, not ecclesiastical deprecationem.
Please don't piss people off.
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If
No, in that wonderfully consistent Perl documentation, it's "undef" not SNIP
is only used to refer to (as you pointed out in another post)
the null string
the null character
the null list
Those use null as an adjective. This RFC proposes an addition to Perl tSNIP
the null
This
In Perl, this is the null string:""
In Perl, this is the null character: "\0"
In Perl, this is the null list: ()
In RFC 263, this is the null: null
That's a different word for a different concept. No conflict, if you
learn the way the RFC speaks.
Wrong. Just plain wrong.
It's
By your "reasoning", we can just add infinitely more things that
take twice a few pages to explain.
You took that to an illogical extreme conclusion. Clearly you can't add
everything to the language. However, it is clear by the set of currently
submitted RFCs that more people think
Could the prototype people please report whether Tim Bunce's issues with
prototypes have been intentionally/adequately addressed?
I'm not a prototype person (in fact RFC 128 makes it a hanging offence
to use that confusing word in connection with parameter lists! ;-)
Could someone
Russ:
About the only piece of code of mine that this would affect are places
where I use ++ on an undef value, and that's not a bad thing to avoid as a
matter of style anyway (usually I'm just setting a flag and = 1 would work
just as well; either that, or it's easy enough to explicitly
How can you convince anyoone if you say you would not use it. For any feature
enhancement to perl, unless there is a strong case for how it makes
the labguage easier and better it is just not going to happen.
It's not as though Tim Bunce has been hollering for this, which is a
bad sign.
--tom
ess pragma.
use less 'memory';
etc. Right now, you can say silly things.
use less 'sillyiness';
What about use more? Or is that just no less
use less 'magic';
no more 'magic';
=item perl6storm #0104
Look at the deep magic seen in some of the examples in Camel-3's
OO and tie chapters and in perltootc. Consider what to canonize
into a simpler-to-get-at mechanism, just as plum engendered much
in perl5.
=item perl6storm #0105
Learn to count in decimal.
=back
=head1 BUGS
None. These are features.
=head1 AUTHOR
Tom Christiansen
=item perl6storm #0106
Safe "signals"! (not syssigs,really)
Now, that's not accurate either. "NUL" is simply a normalized form of "null",
because all the ASCII special characters have three upper-case letter names.
There is no doubt that the ASCII guys meant "null" by this.
All other matters aside, kindly consider this simple one: If ever
you thought
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Could you explain what the problem is?
TC /$/ does not only match at the end of the string.
TC It also matches one character fewer. This makes
TC code like $path =~ /etc$/ "wrong".
Sorry, I'm missing it.
I know.
On
That was my second thought. I kinda like it, because //s would have two
effects:
+ let . match a newline too (current)
+ let /$/ NOT accept a trailing newline (new)
Don't forget /s's other meaning.
--tom
What I said was: making length(@array) "work" would be catering to
novice people *coming from C*. We shouldn't. Not that much. In Perl, a
string is not an array.
I'm pretty sure it's not just the people coming from C who expect this.
This all points to the bug^H^H^Hdubious feature which is the
This will make programs highly nonportable. You can't easily know what
modules they really need.
--tom
And what about $$x?
Dang, are we back to this incredible confusion about what it is to be
defined in Perl.?
undef $a;
That is now UNINITIALIZED. So is this:
$a = undef;
You have initialized it to undef. There is no reasonable difference.
Solution:
Remove all references from
Nathan Wiger wrote:
...a "use tristate" pragma which obeys blocks
bka "lexically scoped". If I'm not mistaken, pragmas *are* lexically scoped.
They *can* be. They needn't be.
--tom
The semantics for NULL is different, read the SQL standard.
Perl has no business contaminating itself with SQL.
--tom
Unlike undef, which gets assigned to uninitialized variables, NULL is only
used by choice. So you only need deal with NULL when there is the
possibility that it needs to be handled in some special way, and might exist
as a value in the expression being handled.
This can be done without being in
no strict;
$a = undef;
$b = null;
Perl already has a null string: "".
--tom
Perl has *one* out-of-band value. It doesn't need more. That
doesn't mean that perhaps some rare sorts of programming might not
benefit from fancy weirdnesses. That's what modules are for.
You don't need to complicate the general language to get what
you want. Don't make others pay for your
$a = null;
$b = ($a == 42);
print defined($b)? "defined" : "not defined";
would print "not defined", maybe?
In a sane world of real (non-oo-sneaky) perl, the "==" operator returns
only 1 or "". Both are defined.
--tom
It only takes a few pages, and a few truth tables to explain NULL.
It should only take a few pages and a few examples, to explain the
difference between undef and null.
Ah, so the cost of this is twice a few pages of explanation, plus truth
tables and examples? Are you mad?
I can think of no
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
no strict;
$a = undef;
$b = null;
Perl already has a null string: "".
Looks more like a string of no length than a null string.
Well, it's not. That's a null string. You're thinking of "\0",
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Currently many programs handle error returns by examining the text of
the error returned in $@. This makes changes in the text of the error
message, an issue for the backwards compatibility police.
TC eval {
That's not much different than the cost of undef, so I fear it proves
nothing, universally.
YOU OVERQUOTEDsen wrote:
YOU OVERQUOTEDkes a few pages, and a few truth tables to explain NULL.
YOU OVERQUOTEDonly take a few pages and a few examples, to explain the
YOU OVERQUOTED between undef and
For example, assuming this code:
$name = undef;
print "Hello world!" if ($name eq undef);
So don't do that. Use Cdefined $name if you want to ask that question.
That's why I want to change the names of these things. The current
situation invites errors such as seen previously.
Tom Christiansen wrote:
no strict;
$a = undef;
$b = null;
Perl already has a null string: "".
That's an empty string. In any case, if you really want to call it a
null string, that's fine, just a little more likely to be
misinterpreted.
In Perl, this is the n
I'm not happy with your use of "coerce". There's no mutation. It simply
*is* those things.
Fine. So, in particular, it _isn't_ null.
Of course it's null. That's why it has length zero. Stop speaking
SQL at me. I'm speaking Perl.
4) The antiïinitialized value is autovivified to a true
But that doesn't even matter that much here; I'm saying that if the
compiler can definitely determine that you are using an uninitialized
variable, it should warn.
...
$x is a global. The compiler cannot detect all possible assignments to
or accesses of globals, so it never warns about them.
Which is silly, because you shouldn't have to say '$x = $x = 3' when you
mean '$x = 3'. Just because there's a real reason behind it doesn't make it
any less silly.
I'd like to see where this can happen. Sounds like someone forgot to
declare something:
our $x;
$x = 2;
--tom
Anything else? Any opinion on whether eval "" should do what it does
now, and be invisible for the purposes of this analysis; or if it should
be assumed to instead both use and initialize all visible variables? The
former produces more spurious warnings, the latter misses many errors.
You have
It happens when I don't bother to declare something. My company has
several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
a pain. As is $My::Package::Name::x.
Far, far easier to fix behavioral problems than to hack Perl.
--tom
Ok, so you want message catalogues, and not solely on Perl but anything
in the distribution. You should say that.
--tom
Tom Christiansen wrote:
Anything else? Any opinion on whether eval "" should do what it does
now, and be invisible for the purposes of this analysis; or if it should
be assumed to instead both use and initialize all visible variables? The
former produces more spurious warnings,
Tom Christiansen wrote:
It happens when I don't bother to declare something. My company has
several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
a pain. As is $My::Package::Name::x.
Far, far easier to fix behavioral problems than to hack Perl.
--tom
Not sure what
But I see code in the XML modules that check defined (@array)
They're buggy and wrong.
--tom
Have a nice day. And thanks for all the fish.
What can be done to make $ work "better", so we don't have to
make people use /foo\z/ to mean /foo$/? They'll keep writing
the $ for things that probably oughtn't abide optional newlines.
Remember that /$/ really means /(?=\n?\z)/. And likewise with \Z.
--tom
It's hard to remember the sequence of values that the following
builtins return:
stat/lstat
caller
localtime/gmtime
get*
and though it's easy to look them up, it's a pain to look them up
Every Single Time.
Moreover, code like this is far from self-documenting:
On 19 Sep 2000, Perl6 RFC Librarian wrote:
Distinguish packed binary data from printable strings
What defines a "printable" string? What if I'm working in an environment
that can "print" bytes that yours can't? Specifically I'm wondering how
this proposal handles Unicode.
Perl should fly
This RFC proposes that the internal cursor iterated by the Ceach function
be stored in the pad of the block containing the Ceach, rather than
being stored within the hash being iterated.
Then how do you specify which iterator is to be reset when you wish
to do that? Currently, you do this by
Perhaps what you're truly looking for is a generalized tainting mechanism.
--tom
Just to note: in version 2 of the RFC, it's associated with the pad of
the block in which the Ceach appears.
then what are you going to do?
The short answer is that there is no "manual" reset of iterators.
I am concerned about that.
sub fn(\%) {
my $href = shift;
Tim Conrow wrote:
Tom Christiansen wrote:
Perhaps what you're truly looking for is a generalized tainting mechanism.
Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers?
RFCs? Examples? Hints?
Sorry for the clutter, but I didn't want to come off too clueless. I
$sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
Note with the || that way, it'll die immediately if @numbers is empty,
even before destroying the universe.
Yes, but why are you passing the size of the array in there?
--tom
Why not just check @numbers?
--tom
Following Glenn's lead, I'm in the process of RFC'ing a new null()
keyword and value
As though one were not already drowning in a surfeit of subtly
dissimilar false values.
--tom
Ummm...Maybe I'm missing something, but how does reduce() know the
difference between
$sum = reduce ^_+^_, 0, @values;
unshift @values, 0;
$sum = reduce ^_+^_, @values;
You know, I really find it much more legible to consistently write
these sorts of thing with braces
The warning for the use of an unassigned variable should be "use of
uninitialized variable C$x".
The problem with that idea, now as before, is that this check happens
where Perl is looking at a value, not a variable. Even were it possible
to arduously modify Perl to handle explicitly named
Currently many programs handle error returns by examining the text of
the error returned in $@. This makes changes in the text of the error
message, an issue for the backwards compatibility police.
eval { fn() };
if ($@ == EYOURWHATHURTS) { }
sub fn { die "blindlesnot" }
Currently, Perl has the concept of Cundef, which means that a value is
not defined. One thing it lacks, however, is the concept of Cnull,
which means that a value is known to be unknown or not applicable. These
are two separate concepts.
No, they aren't.
--tom
I doubt anyone's arguing that they're not function calls. What I find
"surprising" is that Perl doesn't DWIM here. It doesn't encourage data
encapsulation or try to make it easy:
my $weather = new Schwern::Example;
print "Today's weather will be $weather-{temp} degrees and sunny.";
As Nate pointed out: print "$hash-{'f'.'oo'}" already works fine and
the world spins on.
That is no argument for promoting illegibility.
--tom
Subroutines calls should interpolate in double-quoted strings and similar
contexts.
print "Sunset today is at sunset($date)";
interpolates to:
print 'Sunset today is at '.sunset($date);
Huh? And what if it's a built-in? What if it's not quite a built-in,
but an import? What if you
Surely the next request will be to make anything that works outside
of quotes work inside of them, completely erasing the useful visual
distinction. Why should operators, after all, be any different
from functions?
print "I have Fooey-fright($n) frobbles.\n";
print "I have snaggle($n)
[This somewhat elderly draft was found lying about an edit
buffer, but I do not believe it was ever sent yet.]
Now, the possibility to either pass individual scalars to a sub, or an
array, (or several arrays, or a mixture of arrays and scalars) and Perl
treating them as equivalent,
foo-bar($baz, $coon)
should be made synonymous with
foo-bar $baz, $coon
I can see no ambiguity in this call, but it not always works with Perl5.
Arrow invocation does not a listop make. Only indirect object invocation
style does that.
print STDOUT $foo, $bar, $glarch;
is a list
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
From: Jarkko Hietaniemi
I find this urge to push exceptions everywhere quite sad.
Rather.
Languages that have forgotten or dismissed error returns, turning
instead to exceptions for everything in an effort to make the code
"
1 - 100 of 273 matches
Mail list logo
