Right you are. I'm still living in the 20th century :-)
So are all of us -- just give it a few months, though. :-)
--tom
Still think Cmerge and Cemerge are cuter. :-)
Except that that pair looks like "munge" and "emunge" (and probably
sounds like them too in certain accents :-), which are actually
synonyms of each other. :-(
--tom
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Special cased for postfix modifiers, or generalized? If so,
what's the return value?
$x = TERM OP do { BLOCK } OP TERM;
Actually, these are all pretty similar in
Tom Christiansen writes:
However, I really don't want to see 'return' become a kind of 'last'
for do{}. How would I return from a subroutine from within a do loop?
You already can't do that (as it were) from within an eval.
Yes, but 'eval' has the semantics "run this code but don'
Think of it this way: you're asking that when you write
return WHATEVER;
(for various values of WHATEVER) that *sometimes* it's context
dependent, and sometimes it's not. Right now, it always is,
which is more consistent, predictable, and explainable than the
alternative.
Or maybe you're
Then please explain why scalar(return (1,2,3)) doesn't do what at first
glance it seems it should.
Because X(Y) != Y(X). You should have written "return scalar" if you
wanted to return a scalar.
And for the life of me I can't see how
$x=(1,2, (3,4,fn,6) )
fn ends up in scalar
package main;
sub fn { return (3, 5, 7) }
tie $x, 'MaiTai';
$x = fn;
$ /tmp/foo
STORE: 7
Why don't I see three STOREs?
Because Perl is too clever to bother. :-)
--tom
Hey, waitaminute. That isn't a list in sub fn in the first place; it's
three expressions separated by scalar commas. Why is there no complaint
about useless use of a constant in void context?
$ perl -Mstrict -wle 'sub f{return(3,5,7)} my $x = f()'
$ perl -Mstrict -wle 'my $x = (3,5,7)'
Perl supplies an operator for line input - angle brackets. This is no
analogous operator for output. I propose "inverse angle brackets":
"Print this line.\n";
Perl already *has* a print operator: "print". :-)
The problem with what you have there is that it hides the act of
output within
This is what I'd consider good style:
my @output =
map { $_-[0] }
sort { $a-[1] cmp $b-[1] }
map { [$_, expensive_func($_)] } # print original lines
;
(Modified from http://www.perlmonks.org/index.pl?node_id=9108)
The main point of this statement is the Schwartzian
On Tue, 05 Sep 2000 18:37:11 -0600, Tom Christiansen wrote:
Those are not the semantics of print. It returns true (1) if successfSNIP
false (undef) otherwise. You cannot change that. If I write print "0", it
bloody well shan't be returning false.
Oh, why not? Does anybody actu
* Have to use ugly globref syntax to pass them around reliably.
No, you don't. You can use globs. But only if you don't have
prototypes, like sub opt(*).
* Not first-class objects, so you can't subclass them.
That's not a good argument. I can't subclass a number, either, nor
So why not allow undecorated variables a larger existence?
We already have them. You can use a sub name or a package name
where you mean an "undecorated variable". In fact, you can have
things generate/populate new subs or packages as you like it.
use Funny_Business;
frob Funny
What if it's an anonymous stream?
How do you open an anonymous stream?
Me? This way:
local(*HITHER, *THITHER);
pipe(HITHER, THITHER) ..
or, I suppose,
my($hither, $thither);
pipe($hither, $thither) ..
or even
pipe(my $hither, $thither) ..
Why, how do
This is already allowed. It's called "passing in a bareword".
And barewords are just strings. Are you proposing
that "a bareword should now mean a filehandle", so that
copydata(STDIN, STDOUT);
means something different from
copydata('STDIN', 'STDOUT');
or
The whole notion of blessing is non-obvious enough already.
It's the benedictory (con)not(at)ion of blessing, not the bless()ing
itself that so confuses people, I think.
It bless() were instead named something like
mark
stamp
label
brand
retype
denote
notate
exists (sometimes causes autovivification, which affects Ckeys)
That's not technically accurate--exists never causes autovivification.
print keys %hash, "\n";
exists $hash{key}{subkey};
print keys %hash, "\n";
Or did that get fixed when I wasn't looking?
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
exists (sometimes causes autovivification, which affects Ckeys)
That's not technically accurate--exists never causes autovivification.
print exists $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper
Method calls should interpolate in double-quoted strings, and similar
locations.
print "Today's weather will be $weather-temp degrees and sunny.";
Would deparse to:
print 'Today\'s weather will be '.$weather-temp().' degrees and sunny.';
So, the - operator is supposed to get expanded
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
those early perl3 scripts by lwall floating around in /etc were poorly
written. i am glad they are finally out of the distribution.
Those weren't the scripts I was thinking about, and it is *NOT*
ipso facto true that something which uses $ or $` is poorly
written.
--tom
All in all, though, you're right that neither set of features is particularly
well-known/used outside of p5p followers. At least from what I've seen.
Virtually every person I've worked with since 5.6 came out has been surprised
and amazed at the REx eval stuff.
The completely reworked regex
I propose that this 'last successful match' behavior be discarded
entirely, and that an empty pattern always match the empty string.
I don't see a consideration for simply s/successful// above, which
has also been talked about. Thas would also match expected usage
based upon existing editors.
This is useful in that it would stop being number dependent.
For example, you can't now safely say
/$var (foo) \1/
and guarantee for arbitrary contents of $var that your you have
the right number backref anymore.
If I recall correctly, the Python folks addressed this. One
might check
Have you ever wanted to count the number of matches of a patten? s///g
returns the number of matches it finds. m//g just returns 1 for matching.
Counts can be made using s//$/g but this is wastefull, or by putting some
counting loop round a m//g. But this all seams rather messy.
It's
Simple solution.
If you want to require formats such as m/.../ (which I actually think is a
good idea), then make it part of -w, -W, -ww, or -WW, which would be a perl6
enhancement of strictness.
That's like having "use strict" enable mandatory perlstyle compliance
checks, and rejecting the
That empty list to force the proper context irks me. How about a
modifier to the RE that forces it (this would solve the "counting matches"
problem too).
$string =~ m{
(\d\d) - (\d\d) - (\d\d)
(?{ push @dates, makedate($1,$2,$3) })
}gxl;
$count =
If we want to use uppercase, make these unique as well. That gives us
many more combinations, and is not necessarily confusing:
m//f - fast match
m//F - first match
m//i - case-insentitive
m//I - ignore whitespace
And so on. This seems like
tr///e is the same as s///g:
tr/$foo/$bar/e == s/$foo/$bar/g
I suggest you read up on tr///, sir. You are completely wrong.
--tom
p.s. Has anybody already suggested that we ought to have a nicer
solution to execute perl code inside a string, replacing "${\(...)}" and
"@{[...]}", which also won't ever win a beauty contest? Oops, wrong
mailing list.
The first one doesn't work, and never did. You want
@{[]} and
($foo = $bar) =~ s/x/y/; will never make much sense to me.
What about these, which are much the same thing in that they all
use the lvaluability of assignment:
chomp($line = STDIN);
($foo = $bar) += 10;
($foo += 3) *= 2;
func($diddle_me = $protect_me);
$n =
What about these, which are much the same thing in that they all
use the lvaluability of assignment:
And don't forget:
for (@new = @old) { s/foo/bar/ }
--tom
Uri Guttman wrote:
TC ($this = $that) =~ s/foo/bar/;
TC for (@these = @those) { s/foo/bar/ }
TC You can't really do those in one step without it.
RFC 164 v2 has a new syntax that lets you do the above or, if you want:
$this = s/foo/bar/, $that;
@these = s/foo/bar/,
I am working on an RFC
to allow boolean logic ( and || and !) to apply a number of patterns to
the same substring to allow easier mining of information out of such
constructs.
What, you don't like: :-)
$pattern = $conjunction eq "AND"
? join('' = map { "(?=.*$_)" }
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
"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
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 }) \)
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
$x and $y are in the same scope. This is good, but also bad. For one
thing, you can hang yourself real easily if you come from a C background
and expect this to keep stuff private:
$x = 10;
sub square {
($x) = @_;
$x *= $x;
}
$ans = square($x);
print "$x squared is
[Quoting David L. Nicol, on August 21 2000, 23:06, in "Re: RFC 132 (v1) sub"]
Looks like a case for automatic dereferencing!
Which Perl has always stated it would _never_ do.
Kinda.
To be honest, Perl does do autoderef in at least two places.
1.
$fh = *FH;
$fh = \*FH
can be used
A main goal for Perl 6 is to make it faster, more compact, and lighter
weight. This means moving lots of former core functions into modules.
Andy D once posted something showing empirical evidence
that this hypothesis is in fact *FALSE*. And I was taught
that given a false hypothesis, nothing
You maybe want to at least SEE ALSO reference the pair of docs by
me and by Tim Bunce about the current state of prototypes.
--tom
Nathan Wiger writes:
Brainstorming off the top of my head:
sub length (($|@)) {
}
That is, use a regex-like "(x|y)" - or maybe [$@%] ?? - for alternative
context coercions.
The only RFC on prototype extensions we have is Andy Wardley's #57.
I suggest you ask him to add this
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
Perl isn't a programming language - Perl's grammar is much more like
a natural language than a computer one.
Well, $I wonder if anyone except @computers can find it natural to put a
f... $dollar_sign in front of every $noun you use.
Grammar != vocabulary.
You're right. Strictly
Thank you for your compliments.
Would you be willing to give us a first shot at what Perl *is* to get the
discussion going?
Only as slogans; deep analysis will require ascending a nearby summit.
"Perl is a language you already know, but that you just don't
know that you know."
One argument *against* intra-token-sequence multiline comments is that they
are harder to see, and thus render readers of the code more prone to
misunderstand it. Is this worth really promoting?
The extant pod-based multiline comment solution does not suffer from this,
as it is quite easy to
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
Anything one chooses potentially conflicts with the user's namespace, but
probably save() or temp() would be better, or even savetemp() or tempsave()
or scopetemp().
How about deliver() or preserve()?
I can slightly grok
I believe that under the current proposal, any unqualified and
hitherto undeclared variables would be implicitly declared to be
lexicals in the current scope. This is to be contrasted with the
status quo, under which such variables are implicitly dynamics in
the current package.
I am not wholly
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
What then do you propose? my() and our() were chosen for their brevity.
I might suggest that one look to Python's use of locals() and
globals(). Currently, globals() is something like keys %{ __PACKAGE__
. "::"},
It nice to be able to bounce on % in vi, too:
=#{
comment
=#}
You easy to do this already:
=begin comment {
=end comment }
--tom
The warning message "use of uninitialized value" should also
disappear, to be replaced with "use of undefined value", and the
warning for the purpose described in this RFC should be "use of
uninitialized variable C$x".
What about if there's only an expr, not a variable?
For example:
print
This seems like an acceptable variation on what has been suggested so far. I
deally one would be able to safely block comment any large section of a Perl
6 script and not worry about any other block comments within (the outermost
block comment takes precedence).
I still like this solution
What is wrong with
if (0) {
}
(and of course teaching op builder not to build them in this case).
Funny, I was going to mention that I always use
#if 0
...
#endif
in C for nesting, block comments. Which is rare anyway, rarer perhaps
than this discussion would seem to merit.
Proposal: here-docs specified with regexes, and no special
meaning for newlines.
comment /EOC/; this is an arbitrary comment. EOC
Smack--the lexer cowers before you!
--tom
The way I see it Santa (aka Larry) has asked for our wish list. This is not
the time to dwell on all the ways we can make due with our old toys.
I still think saying :10,20s/^/##XXX## / is the cleanest and most
visually apparent block comment.
PS I'm all for a new list. How do I get one?
I see
. You misunderstand; I am *not* addressing the
perennial complaint that the "use of uninitialized value" doesn't
identify the source of the undefined value.
Ok.
"symbol $main::x used only once" - "use of uninitialized variable
$main::x"
"use of uninitialized value" - "use of undefined value"
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
Scalars, hashes, arrays. There's actually more than one type of plural here,
gramatically:
scalars hashes arrays
singulardualplural
(Or am I the only one left who did Ancient Greek? :)
Nope: pudge and larry, at least.
(and don't say, "because plural *means* more than
If the prefix-less form of filehandles was absent from Perl 6, I would be
far less enthusiastic about my RFC. I agree; they're a kind of scalar.
(Just occurred to me that one could view the % prefix of hashes as denoting
a key-value pair by virtue of looking like two o's separated by a
I'd also like some 'what are you' introspection I can do on all scalars, on
a more formal basis than 'ref'. Either an expansion of the 'ref' functionality
to cover filehandles, or a more general system...
What do you mean, "formal"? ref() has always been a de facto typeof
operator, no?
I've just asked for a multiline comment sublist to be set up. Do any
of the rest of these RFCs want/need a sublist?
What is the purpose of ghettoizing everying cohering topic? Making
us subscribe to infinite lists to wear us down?
--tom
Tom Christiansen writes:
What is the purpose of ghettoizing everying cohering topic? Making
us subscribe to infinite lists to wear us down?
Yes.
If you really care about the topic, you'll join the list. If you
don't care, stay off the list and don't bother the happy workers.
That's the plan
Making us subscribe to infinite lists to wear us down?
You know about perl6-all, right?
Nope, I didn't.
Which is the very problem of which I was speaking.
Secret cabals and all.
--tom
Russ talked about doing that. I think it would have to be called
nntp.perl.org.
I can trivially repoint the old news.perl.com to wherever works best.
--tom
Not sure I agree with that. I think one point of confusion / perceived
difference between filehandles, open(), and basically every other
builtin is that all the others *return* what you want.
Think of all the {file,dir}handle syscalls. They don't do that.
They autoviv an object.
--tom
Not sure I agree with that. I think one point of confusion / perceived
difference between filehandles, open(), and basically every other
builtin is that all the others *return* what you want.
tie and bless and chop and chomp also all act upon their argument(s).
Just to name a few. bless has
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
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 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
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
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
Some related issues:
1) Did Larry or did he not mention something about dealing with
indirect object more cleanly?
Maybe clarify this just a little. I don't think I was present for this
discussion.
That's just the indirect object slot ambuiguity annoyance. See the
OO chapter in
How often does the return value from chomp or chop get used? The confusion
would cleared up considerably, I think, if they didn't return a value.
Seldom, I think--albeit sufficiently often that you might want the
perl526 translator to have any such found be converted to some kind
of
Several macro processors exist and are easily available. I do not see
the need to duplicate (parts of) their functionality in perl.
Personally, I'd even trow out -P.
Well, possibly, but especially if a cpp-like source filter module
is included standard.
--tom
Johan Vromans [EMAIL PROTECTED] writes:
=head1 ABSTRACT
Perl distinguishes named operators and functions. For Perl6, this
disctinction can be dropped.
Will this then work?
sub foo {
my $func = shift;
$func(@_);
}
foo(\print, "foo");
foo("print", "foo");
The descriptions in perlfunc etc. are not 100% complete.
Then send a patch.
There are some features that are still not documented. Therefore, it is
not possible to mathematically prove that a largish program is correct.
Your "therefore" is misplaced or misguided. Formal proof systems
of
Hello!
I am thinking about the perl compiler, and I thought if somebody
avoid using the "eval $scalar", the compiled code (perl to C
compiled code) may not contain a full perl interpreter. If it is the
case, we must say to any module developer: Don't use "eval $scalar"!
This
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
At 12:47 AM 8/4/00 -0400, Ken Fox wrote:
John Tobey wrote:
The Perl 5 (and older) behavior may preclude some optimizations.
I can't think of any optimizations @_ assignment precludes.
If we don't analyze dataflow to figure out if a sub modifies its
args, then we just assume it will.
If we
Why would we ever remove a syscall!?!?
I vote for migration to a module.
And sysopen and fcntl and waitpid and ioctl
Gisle Aas wrote:
foo(\print, "foo");
I think it's critical that built-ins be reference-takeable,
just like user-defineds.
But they [dw]on't work right.
sub CORE::push { push(@_);
$fn = \CORE::push;
$fn-(@some_array, now, some, list);
--tom
I don't much care for m4; it's not so much better than cpp to be
worth the notice.
*Strongly* disagree.
--tom
Tom Christiansen wrote:
I think it's critical that built-ins be reference-takeable,
just like user-defineds.
But they [dw]on't work right.
Um -- why not? Why can't we make then work right in perl6?
As my example demonstrated, it's because there's no run-time
application of content
As my example demonstrated, it's because there's no run-time
application of content coercion templates. And I don't think
s/ent/ext/
Gosh, just unlink() leave it as it is.
--tom
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
Here in my pre-caffiene morning trance it occurs to me that a few of
the "fringe" features of perl should be removed from the langauge.
Here's a few things that I would venture to say that none of the
"perl5 is my first perl" people have probably ever actually used.
reset # How
I've very rarely found cases where ?? was useful and // didn't work, and
never in regular code.
From the Camel:
The C?? operator is most useful when an ordinary pattern match
would find the last rather than the first occurrence:
open DICT, "/usr/dict/words" or die "Can't open
Today around 11:48am, Tom Christiansen hammered out this masterpiece:
: So basically, it would be nice if each, keys, values, etc. could all deal
: with being handed a hash from a code block or subroutine...
:
: In the current Perl World, a function can only return as output to
: its caller
It would be nice if a human readable dump were possible. So please don't
completely dump the idea of Data::Dumper functionality in the core.
These are different things. And the bytecodes can always be B::Deparse'd, or
whatever we come up with for uncompilation.
Not that proper marshalling
dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Hmm, what about CHECK blocks?
--tom
: No. keys() expects something that starts with a %, not
: something that starts with a .
Wow. Now that, that, is lame. You're saying that keys() expects it's first
argument to begin with a %? Why should it care what it's argumen begins with?
You're just now figuring this out? Really?
All
1 - 100 of 273 matches
Mail list logo
