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
In-Reply-To: Message from Daniel Carrera dcarr...@gmail.com
of Fri, 31 Dec 2010 20:20:33 +0100.
For amusement, below I include the same program
in FORTRAN II and Fortran 90.
That was delightful -- thanks!
--tom
The 'Is' prefix can be used on any property in 5.12 for which there is
no naming conflict. The only naming conflicts are certain of the block
properties, such as Arabic. IsArabic means the Arabic script. InArabic
means the base Arabic block. Personally, I find Is and In unintuitive,
and
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
Why isn't that:
/+ alpha - [A-Za-z]+ /
If you're asking why it's mentioned in the Update: section
instead of the pattern in question just being rewritten, I don't know.
What got me most was the assumption that subtracting A-Za-z from Alphas
yielded accented characters, as though Alpha meant
Larry wrote:
» Indeed, that preference is why Perl 6 can (we hope) get away with
» autochomping, where Perl 5 can't (as easily). Or more accurately,
» we choose not to special-case while () as Perl 5 does (because
» even Perl 5 has difficulties with files that are accidentally
» autochomped by
· 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 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 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
$
In-Reply-To: Message from Geoffrey Broadwell [EMAIL PROTECTED]
of Wed, 24 Sep 2008 16:47:44 PDT.
[EMAIL PROTECTED]
On Wed, 2008-09-24 at 18:09 -0500, Patrick R. Michaud wrote:
On Thu, Sep 25, 2008 at 12:10:35AM +0200, Reini Urban wrote:
2008/9/24 Patrick R. Michaud [EMAIL PROTECTED]:
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
I made a mistake in phrasing it this way, because it seemed to suggest that
I thought it was an implementation bug that it returns "d" instead
of "bd". I didn't make it clear that I was trying to approach this as
a purely SEMANTIC question, considered in isolation from the
I meant that I've never seen
a concrete, realistic example where the current behavior is more beneficial
to the programmer than my proposed behavior.
Absense of evidence is hardly evidence of absence.
`cat /vmunix` =~ /\w+/
I just love guaranteed worst-case behavior. NOT.
It is good to
I want the maximum level of OVERALL consistency for regular expressions as
We're there, thank you very much. "Find a match" is the over-riding
sentiment, the principle semantic. It is completely consistent with
this. You've got greed/nongreed very wrong.
a whole, rather than immutable
Really? I haven't taken a survey, but I did ask one co-worker for his
first impression of what the regexp (from my example) would match. Not
being an experienced Perl programmer, but being familiar with regular
expressions, he believed he understood the idea of non-greedy matching.
His
We may have to "agree to disagree".
I shan't be doing that.
I'm understand why people believe in
the current semantics, but I've seen no indication that anyone else
understands why I believe in these alternative semantics, or has tried.
(Disagreeing with my conclusion doesn't preclude
Actually, I'm not sure -- it's conceivable that the ending point would ALSO
move inward for a different starting point within the original match. But
the ending point should NEVER be advanced further -- that's where the
"leftmost over nongreedy" rule should apply instead...
Please show us your
On Fri, 15 Dec 2000, Tom Christiansen wrote:
As for special-case rules, I believe that my proposed modification would
REMOVE a special-case semantic rule, at the cost of added complexity at the
implementation level.
What is this alleged "special-case rule" you are tal
That would be a strange regexp, but I never suggested it. I suggested the
regexp /b.*?d/ and pointed out that I believe "bd" is a more intuitive
match than "d". That was the matching text, not the regexp, sorry
if I didn't make that clear.
Fine. What you said is
first
At worst, this should take no more than double the amount of time that the
single pass did, probably less. Hardly a cause to concern ourselves with
the heat death of the universe.
Oh really? We have shown that for the kind of global overall
analysis that you are asking for, that in the general
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
Take. It. To. Private. Email. Please.
I'm going to do better. I'm taking it to /dev/null.
It's not worth my wasting my life over. Nobody
agrees with this guy, so it doesn't matter.
--tom
Does anyone disagree with the premise, and believe that "d" is the
CORRECT match for the non-greedy regexp above?
Yes. The Camel's regex chapter reads:
You might say that eagerness holds priority over greed (or thrift).
For what it's worth, here's a quote from a Perl 5.005_03
No question that's how it's been implemented. But WHY would anyone want
such behavior? When is it beneficial?
It is beneficial because this is how it's always been, because it
is faster, because it is more expressive, because it is more powerful,
because it is more intuitive, and because it is
Sean M. Burke wrote:
The current behavior makes trailing empty fields non-existent, and that's a
bizarre and nonintuitive thing to have be a default;
Only to some people; and besides, it's well documented.
Well, Sean is right in that it is very bizarre to many people.
I know that when I
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
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 }) \)
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
This seems very complicated. Did you look at the Ram:6 recipe on
expressing AND, OR, and NOT in a regex? For example, to do
/FOO/ /BAR/ you need not write /FOO.*BAR|BAR.*FOO/ -- and in
fact, should not, as it doesn't work properly on some pairs!
For example, /CAN/ /ANAL/ can't be written
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
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
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
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)
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
I don't think that the documentation should be removed from the core
distribution, BUT I do think that there should be an "easter egg" that
allows people to build a Perl distribution without documentation or
whatever else they choose. There have been times that I've
wanted/needed to build a
We've had prototyping (context coercing) for methods as long as we've
had them for "ordinary" subroutines.
Sure -- they just don't work.
Method calls are indirect function calls. As such, they are not
resolved until run time. Context coercion, however, is set at
compile time--if at all.
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
So this would break any code which interacts with pod: Pod::Usage, perlman,
perlhelp, etc.
NB: perlhelp == perlman with a particular metapage named perlhelp,
which knows to search the pod library linewise.
Which I suppose just adds weight to the don't go there,
highly discouraged ultimatum.
I gather you're talking about //s making perl ignore the setting of $*.
You're right, I didn't know that. But I doubt if it's that important,
this variable already has been marked as deprecated since Perl5 came
out, about 5 years ago. It's a good candiadte to be removed in Perl6.
Agreed.
My
"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
* 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",
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
"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 {
Tom Christiansen wrote:
Don't forget /s's other meaning.
Do you enjoy making people ask what you're talking about?
Of course not. I enjoy giving people enough pointers to help them
learn things for themselves.
What other
meaning did you have in mind, overriding $*?
Yes.
--tom
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
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,
Have a nice day. And thanks for all the fish.
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
Here's something you and Glenn don't seem to understand:
it doesn't *matter* what the human meaning of undef is.
Call it undefined, uninitialized, unknown, etc. etc.
What matters is that in the perl machine, it's a different
kind of value that a scalar can have, besides string, number,
reference,
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'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:
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
I would be opposed to any mechanism that could allow people
to have their code without its attendant documentation.
--tom
(SE), AFAIK, and therefore the man pages should be an option that could be
deleted to save space.
This is already an option, and has been for years. I don't imagine that
would change in perl6.
I should much prefer to see random modules deleted instead.
--tom
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC I would be opposed to any mechanism that could allow people
TC to have their code without its attendant documentation.
Why?
What if I have one or two development boxes, and two handfuls of
production machines. I don't need doc
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
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
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
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
If the original list has no elements, Creduce immediately throws an
exception.
What do you mean by exception, die ? No other builtin dies like that at
runtime.
Well, more can trigger run-time exceptions than people usually notice,
but I don't know of one that does so on an empty list.
These
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
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
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
Tom suggested:
Why not just check @numbers?
Hear, hear:
$sum = @numbers ? reduce ^_+^_, @numbers : 0;
Although we're back to the pain of what happens when @numbers is
really fn(). This is unsatisfactorily nonidempotent (aliapotent? :-)
$sum = fn() ? reduce ^_+^_, fn() : 0;
$IO::STDERR-print @stuff;
print $IO::STDERR @stuff;
You know, I already resent having to use STDERR instead of stderr.
Adding five noisy characters, or seven, is way, way over the top.
As for system globals, when one suggested to Larry that these be
something on the order of SYS::ARGV or
Oh joy: now Perl has nested quotes. I *hate* nested quotes.
Those are single-quotes inside double-quotes.
Yep: nested, with varying semantic effects. Completely nasty.
-tom
It hurts me to do this when there's even a little bit of data, since it
ends up spanning lines really quickly. And it's harder to read and
figure out how everything lines up. Honestly, which is easier to read
and code?
print "Thanks, ", $q-param('name'), " for your order of ",
$q-param('amt'),
So what about
print "Thanks, $user-{'first name'} for your order!";
Which needs nested quotes already?
printf() is more readable in such cases.
--tom
This RFC proposes that rather than three separate mechanisms (in three
separate namespaces) to determine object typing information, Perl 6
simply extend the Cref function to return all the necessary
information in a list context.
That sounds nice. It would also cure the funny business I tacitly
1 - 100 of 326 matches
Mail list logo
