Michael G Schwern wrote:
RFC 142 may help out existing un/pack users, but does nothing to help
in the understanding of un/pack by native speakers of Perl.
I'm starting to think this is largely a documentation issue.
The existing documentation of pack/unpack is terse, and assumes a knowledge
"David L. Nicol" wrote:
What I was suggesting was, if you want to overload the autoloading
of something, it could be done with "catch" instead of rewriting
the ::OVERLOAD procedure, for that module.
"method not loaded" becomes an exception which is thrown, rather
than "AUTOLOADING" being
Peter Scott wrote:
Yes, we get breakage; the user expects die to be trapped by eval.
It still would be.
Users of
Error.pm also expect it to be trapped by catch.
It still would be, if you 'use Error.pm'.
I do not think we should
maintain die/eval as a separate mechanism from try/catch;
Tony Olekshy wrote:
Glenn Linderman wrote:
I do recall seeing this quote; however, replacing AUTOLOAD is a very
specific instance of resuming from or retrying a fault condition. And
even though a retry mechanism could be generalized from AUTOLOAD to
handling other conditions
Tony Olekshy wrote:
Yes, well, at this point I must re-iterate that (in light of reasons
for the existence of a try keyword that I have explained in other
messages), what you've written is the same as:
try { ... } finally { do_something(); }
Yes, they are equivalent.
And note that
Tony Olekshy wrote:
There you have it. That's why RFC 88 uses structured data for $@.
That's a good argument, one that I have no quarrel with. As an
enhancement to eval/die, this would make it more flexible for checking
conditions. And with appropriate stringification, it is upward
Tony Olekshy wrote:
Other than for the except and always clauses, RFC 199 is very
similar to RFC 88. I like the idea behind except and always,
but I think the proposed implementation could be dramatically
simplified.
The first thing to realize is that just because 119 doesn't say
"try"
I'm not on -io, so copy me on discussion. But this RFC was intriguing, so I
read the discussion on the archive for it, and have the following comments.
Perl6 RFC Librarian wrote:
format FILE =
@: @
$name, $ssn
.
=head2 New Syntax
Under the new syntax, a format will be held in a
RFC 186 is another interesting -io RFC, even though I'm not on the -io
list. I couldn't find any discussion in the mail archive, so here's
some to
start it. Please copy me on the discussion. Sorry for cross posting,
but
this is attempting to unify RFCs from different lists; I've bcc'd two of
0 at 12:01:03AM -0700, Glenn Linderman wrote:
Once extracted, a module can deal with it
just as easily, and with much more flexibility, than a core patch to
perl can.
Who cleans up all the junk files later?
Nobody does, they're not junk. They go into the t/ directory of the
m
Perl6 RFC Librarian wrote:
The effects of applying Cprivate to a single hash entry would be to:
=over 4
=item 1.
mark the entire hash as non-autovivifying (except via future calls to
Cprivate -- see below)
This is an interesting proposal, but it seems to be missing something, or maybe I
Perl6 RFC Librarian wrote:
Which again, can be used in the appropriate contexts. Note this allows
you to maintain arrayref objects automatically as well:
package Johnson;
sub new {
my $class = shift;
my $self = [];
$self-[0]-[2]-[3] :raccess('size') = undef;
Michael G Schwern wrote:
On Mon, Sep 18, 2000 at 11:01:12AM -0700, Glenn Linderman wrote:
One of the big complaints about today's perl objects is their slowness at
accessing member data, which is a direct result of hashes being used as the
base data type for the underlying member data
Michael G Schwern wrote:
Similar mistaken logic leads to "globals are faster than lexicals".
Maybe so, but I'd think lexicals would be faster, because more of the lookup is
done at compile time rather than runtime... so I'm not sure what is similar
about the mistaken logic... for arrays, more
Edwin,
This writeup certainly is a great first draft for this RFC. I'll have to track down
those references.
I was surprised by the read/write operations, but have no objection to them.
New/get/set and the individual data member access functions are the critical pieces,
as the I/O could be
Graham Barr 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 question on how long the resulting list should be if
@a, @b, @c is not of the same length. I think zip() was defined
Ted Ashton wrote:
2) Also this proposition fails in one of my goals, which was to allow
arbitrary nesting of multiline comments. I believe this would be true for
any function based solution.
Negative. If you use paired delimiters you're ok.
qc( Here's a quick comment which actually
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. pack
the
script, except for forays into the language of the users of the script.
John Porter wrote:
Glenn Linderman wrote:
qc( Here's a quick comment which actually contains
qc( another comment )
within it
);
This type of comment will not comment out arbitrary text.
In
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
Instead of "local", how about...
reuse
redef
our_temp
Perl6 RFC Librarian wrote:
=head1 TITLE
Rename the Clocal operator
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
NetZero Free
Great idea! (Don't accuse me of apathetic lurking!)
I suspect it already has a different meaning, based on operator precedence rules,
left to right evaluation, etc., but I strongly doubt there is much use of it in
that manner, and would encourage this redefinition to be used instead.
Perl6 RFC
Damian Conway wrote:
This switch statement RFC seems to be built on the premise that the
reason to have a switch statement is to remove a common parameter
from the following limited form conditional expressions.
Yes. As I point out in the paper, that's the *nature* of a switch
Ken Fox wrote:
Then write the switch as:
switch ( __ ) {
case $v == 1: { ... }
case $v == 2: { ... }
case $v == @foo { ... }
}
It might take you a little while to get your head around the __
symbol. I'm not sure it's useful to think of it as a variable;
poison is more
Edwin Wiles wrote:
Without them, the programmer must calculate the required length of the reads
themselves.
Good point. I now want them, rather than being ambivalent.
[ 'bar' = 'i', 'baz' = 'i', 'count' = 'i' ]
It is my understanding that "=" is an indication of a link in a hash
Me too, and I'm _not_ an astronomer.
Tim Jenness wrote:
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_NetZero
Andy Dougherty wrote:
On Mon, 7 Aug 2000, Glenn Linderman wrote:
Me too, and I'm _not_ an astronomer.
Tim Jenness wrote:
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
But surely not as a part of the core language?
It isn't that hard
Jeremy Howard wrote:
Damian Conway wrote:
Personally, if we have positional placeholders I don't see the need
for named ones too. But I'm willing to be convinced.
I'd agree to the contrapositive: if we have named placeholders, I don't see the
need for positional ones too. But I'm willing
John Porter wrote:
Glenn Linderman wrote:
When using an inline comment, I want to spend my character budget mostly
on the comment, and just enough on the delimiters to see it
effectively. # magic here # would do quite nicely
When reading a script, I'd like to be able to quickly
Perl6 RFC Librarian wrote:
It is proposed that a new syntax for declaring constants be introduced:
my constant $PI = 3.1415926;
my constant @FIB = (1,1,2,3,5,8,13,21);
my constant %ENG_ERRORS = (E_UNDEF='undefined', E_FAILED='failed');
I like this. Implementation wise, it could fit
Damian Conway wrote:
Currying placeholders are scalars
Is that a general truth? It wasn't obvious from RFC 23... If you rev it, perhaps
you could make that clearer.
Looking back, the defining example did give a list of (;) in the prototype. I
suppose it would be pretty complex to infer
Nice. But you need to discuss the initial condition: I'd guess you need
an
implicit
=begin perl
before line 1 of each script file, so that scripts that don't pod still
work.
How about some extensions, which integrate another old perl5 feature?
Instead of __END__, how about
=begin data
Now
.something. Probably pretty early.
Perhaps the printed docs should preserve their version, starting with perl6 (or
earlier)... just to remind one of their age...
Bart Lateur wrote:
On Thu, 10 Aug 2000 17:59:52 -0700, Glenn Linderman wrote:
I find nothing in the documentation tha
Peter Scott wrote:
I have often wished that digraphs were not bundled with variables in this
respect, i.e., I wanted to put a string containing \n inside single quotes
just 'cuz it didn't contain variables to be interpolated. Whether there's
a way of improving this behavior or not I don't
Chaim Frenkel wrote:
Would Unicode reduce the problem? Take some operators from the math symbols
and make them the matrix op versions?
(Now, if we add all that APL symbols ...)
Chaim, I think you are on to something here. But before jumping to Unicode or APL
to get more line noise, let's
Seems like the results of
@b = 1 .. 10;
for ( 1 .. 3 )
{ push @a, pop @b;
}
and
@b = 1 .. 10;
push (@a, pop ( @b, 3 ));
But this RFC makes it seem like they produce different results in @a. One could
argue that the current definition of unshift has a similar problem, and that you
are
This deserves a "me too".
Perl6 RFC Librarian wrote:
The camel and the docs include this example:
if (/Time: (..):(..):(..)/) {
$hours = $1;
$minutes = $2;
$seconds = $3;
}
This then becomes:
/Time: (?$hours=..):(?$minutes=..):(?$seconds=..)/
This
Nathan, thanks for zeroing in on this paragraph from RFC 23. It raises a
question in my mind about the meaning of the RFC, and whether the paragraph is
even necessary, which could answer your question about implementation.
If a curried subroutine is truly generated because of seeing an
Clever, and really obscure; wouldn't this then require that _everyone_ that
writes a curried expression for the sort sub use ^a ^b, and that everyone
writing a non-curried sort sub name their parameters a and b? I guess that
wouldn't necessarily be bad, but it would be restrictive.
Damian
Damian Conway wrote:
Clever, and really obscure;
"Invisible", rather than "obscure", I would say.
DWIMity of the first order. :-)
wouldn't this then require that _everyone_ that
writes a curried expression for the sort sub use ^a ^b, and that everyone
writing a
Dan Sugalski wrote:
At 02:48 AM 8/24/00 +0200, Markus Peter wrote:
--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote:
Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
errors, people that want to write fatal errors can switch to using "warn
...; exit
Tony Olekshy wrote:
Glenn Linderman wrote:
Just to point out that fatal is, indeed, as several people keep
saying, truly in the eye of the catcher.
That said, none of the currently proposed mechanisms permit
"resume from fault" semantics, much less "resume from h
uage topic that hasn't
been discussed much.
"David L. Nicol" wrote:
i think he meant the windoes95 BSOD kind of GPF; that's how I read it at leas
Glenn Linderman wrote:
Dan Sugalski wrote:
At 02:48 AM 8/24/00 +0200, Markus Peter wrote:
--On 23.08.2000 17:26 Uhr -0700 G
Jeremy Howard wrote:
New programmers should easily understand that:
- $foo is the variable 'foo'
- _foo is the placeholder 'foo'
- $_ is the default variable
- __ is the default placeholder.
Then, when they see the same named placeholder appear twice in the same
higher-order
Nathan Wiger wrote:
Bart Lateur wrote:
Why interpolate "$obj-method" and not "Class-method"?
This is a decent point worth considering.
I think another way to look at it which is more accurrate is that - is
special in many cases already:
/$foo-{blah}/ # - special
Eric Roode wrote:
Imagine that you could easily override the conversion of undef() into a
string, so that when stringified it returns something like "#UNDEF#"
instead of just an empty string. That would make debugging far more
easy: take a look at the output, and search for this sentinel
Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing
stuff after the terminator? Even the ";" afterward seems useless... the ";"
should be at the end of the statement, not the end of the here doc. The only
improvement to here docs I see in this RFC is to allow whitespace
Nathan Wiger wrote:
I don't know about this. What if someone writes:
print "You owe me $2, $name.\n";
With -w it'll print out the "correct" version?
With a warning, because $2 isn't defined.
You owe me $2, Nate.
But without it it won't?
You owe me , Nate.
You turn off
Michael G Schwern wrote:
On Wed, Sep 13, 2000 at 11:34:20PM -0700, Glenn Linderman wrote:
The rest is handled adequately and consistently today, and Tom's
dequote is adequate to eliminate leading white space... especially
among people who cannot agree that a tab in a file means "
John Porter wrote:
Chaim Frenkel wrote:
Removing -1 as a valid result, could be a breakage (if someone is
doing something weird with a negative result)
What, like using it as an index into a substr?
Bad Code is its own reward, my friend.
$foo = "flabergasted";
Nathan Wiger wrote:
Solves problem #1, indented terminator, except that it adds two newlines
(more later).
I never found anything later about these extra newlines... so if this idea
has merit, it needs to be finished.
However, it leaves 2 and 3. Let's try adding in a regexp:
if(
Glenn Linderman wrote:
I think $mesg wins up with the value of "1" the way you've coded it.
Sorry, I missed the placement of the (). $mesg is fine.
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Ro
I _like_ the conceptual idea, here. But I think we need a different kind of
quoting, not extend single quote semantics. Single quote semantics are really,
really, good for exact quoting. I'm sure you (since you mention VMS) find single
quote semantics good for escaping all those $ VMS
Damian Conway wrote:
now, what if the double quoted range had a \E in it? either directly or
via interpolation? maybe the end escape should be another char than \E?
Make \E significant only where it's explicit.
None of the \ escapes are significant via interpolation, even today. \E
Simon Cozens wrote:
sub interpolate {eval "\"@_\""}
Never say "there is no way". There's *always* a way, and 99% of the time it
doesn't need to go in core.
Yes. Well, actually if you carefully read the thread about RFC 111 in which I got
the inspired flash that interpolation of variables
Richard Proctor wrote:
Maybe I'm being too simplistic, I don't use tabs anymore.
Yes you are, the problem comes with mixing editors - some use tabs for
indented material some dont, some reduce files using tabs etc etc. [I move
between too many editors]. Perl should DWIM. I think that
Chaim Frenkel wrote:
But you would still have to catch the exception. Not a nice thing to
terminate the program just because an expected mismatch occured.
Sometimes it is, sometimes it isn't.
Not finding something is not exceptional.
Sometimes it is, sometimes it isn't. Why were you
Chaim Frenkel wrote:
I thought he was asking for evaluating until nothing is left to interpolate.
I wasn't, just some number of iterations of interpolation, but "infinite"
iterations of interpolation is an interesting idea, and could be added as a special
case... Such would make it hard to
Tom Christiansen wrote:
I am certainly in strong favor of a simple and visually distinctive
solution, and find that the leading bit helps a lot. But I would probably
have written that as:
die POEM =~ /[^!]*/g;
!The old lie
! Dulce et decorum est
! Pro patria
Chaim Frenkel wrote:
"GL" == Glenn Linderman [EMAIL PROTECTED] writes:
Neither is EOF on a file, or working with an empty list. Adding all these
exceptions for non-exceptional and quite common scenerios is bothersome.
I don't know where this idea of a _normal_ situation is
Chaim Frenkel wrote:
What about a hypothetical, use tristate. This would give undef some
extra special powers.
There is a difference between "undefined" and "unknown".
SQL NULL, and the resultant tristate operators used in SQL, specifically is based
on NULL representing the "unknown" value.
Perl6 RFC Librarian wrote:
The is mandatory.
Which makes me happy with this proposal
Parens are also mandatory if
arguments are to be passed.
And I guess the balancing of the parens would solve many of the problems of
argument parsing for the function, which is a concern to me. Within
John Porter wrote:
Glenn Linderman wrote:
The idea of a _normal_ situation being considered exceptional is raised when the
code written inappropriately handles some of the normal return values.
You would throw exceptions at the problem of bad coding practice.
Not the goal
Damian Conway wrote:
Should I point out that RFC 225 (Superpositions) actually covers most of this?
Cnull is equivalent in semantics to Cany() or Call().
I'd love to read your not yet available paper to which the RFC refers. However,
until it is available, and I have time to read it, I'll
John Porter wrote:
Nathan Wiger wrote:
undef null
$a = undef; $a = null;
$b = 1; $b = 1;
$c = $a + b; $c = $a + $b;
$c is 1 $c is
Damian Conway wrote:
Should I point out that RFC 225 (Superpositions) actually covers
most of this?
Cnull is equivalent in semantics to Cany() or Call().
I hope you won't mind my pointing out that the documentation of the
Quantum::Superpositions module -- to which the
"Konovalov, Vadim" wrote:
I'm quite sure that adding "null" into the language will complicate
programming and hardly will give any benefits. One should differentiate
between "null" and "undef", sometimes (or better always!) check variables
with defined(...) *and* isnull(...).
Unlike undef,
"H.Merijn Brand" wrote:
On 20 Sep 2000 04:12:09 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote:
=head1 TITLE
Add null() keyword and fundamental data type
=head1 MIGRATION
None. New functionality.
Not true. Apart from the discussion if undef is the same as null, in which I
John Porter wrote:
Nathan Wiger wrote:
Since undef() has established semantics, I don't think these should
change. I believe taking from RDBMS and adding null() which has the
correct NULL semantics is the way it should go.
You realize, I hope, that there is no end of different
Russ Allbery wrote:
Glenn Linderman [EMAIL PROTECTED] writes:
Russ Allbery wrote:
I agree with Tom; I think it's pretty self-evident that they're the
same thing. undef means exactly the same thing as null; that's not the
problem. The problem is that Perl doesn't implement the tri
Sam Tregar wrote:
On Tue, 19 Sep 2000, Glenn Linderman wrote:
They are different. Neither is a mistake.
How do you explain the fact that every SQL book I've ever seen has
included copious text on problems concerning NULL?
I'm not sure what SQL books you've seen. The standard treatise
Bad idea. See my multitudinous posts on why. Briefly:
1) can't use null and undef together
2) not extendable to 29 versions of null, when SQL defines them
Nathan Wiger wrote:
Graham Barr wrote:
If you want an operator to act differently on some piece of data then a pragma
is the way
Damien Neil wrote:
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
Add null() keyword and fundamental data type
I think that this is better done as a special overloaded object used
by database modules which wish to implement SQL-style tri-state logic.
It could be done
Eric Roode wrote:
Glenn Linderman wrote:
Eric Roode wrote:
1. You don't say in your RFC, but I'm guessing, that a null value
evaluates to false in a boolean context. Correct?
I would expect it to be considered false. Logical expressions involving
NULL are defined to be "unde
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. NULL is neither number nor string,
Tom Christiansen wrote:
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.
That's not much different than the cost of undef, so I fear it proves
nothing, universally.
Tom Christiansen wrote:
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,
Russ Allbery wrote:
Glenn Linderman [EMAIL PROTECTED] writes:
undef has the following semantics:
1) all otherwise uninitialized variables are set to undef
And as the RFC says, quite a few times, for database code you often want
all your variables to start as the null value.
The RFC
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
Tom Christiansen wrote:
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 null string:""
In Perl, this is the null character: "\0"
In Perl, this is the null list: ()
Tom Christiansen wrote:
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.
No, in that wonderfully
Peter Scott wrote:
At 12:38 PM 9/20/00 -0700, Glenn Linderman wrote:
OK, scalar variables. But I see code in the XML modules that check
defined (@array)
Then they should be fixed. That doesn't do anything useful right now.
I tried to fix it according to the suggested fix in the warning
John Porter wrote:
$a = null;
$b = ($a == 42);
print defined($b)? "defined" : "not defined";
would print "not defined", maybe?
defined() is the wrong operator to be using there. Rather,
The tri-state logic deals with "true", "false", and "unknown" (not
NULL). To quote
Paris Sinclair wrote:
If
you need additional semantics than provided by undef, why not make a
module?
This might be workable. There are some thoughts on that. Personally, I
haven't used that much overloading in Perl to know whether it can be made to
work well enough to completely conform
Peter Scott wrote:
$employee{$empno}{SAlARY} -= 10_000; # IPO failure
$employee{$empno}{FAX} = '888-555-1212';
First one got the wrong key when my finger slipped on the shift key, second
one got it when I misremembered FAX instead of FACSIMILE. But in neither
case
Damien Neil wrote:
I suggest that you read up on the difference between "use strrict" and
"use warnings"/-w.
Thanks, yes, I figured out the "no warnings" issue afterwards.
Furthermore, you may wish to take the five seconds necessary to
understand WHY it prints that message when you print a
Tom Christiansen wrote:
A null is a null byte, or a null character. Period.
ASCII, a standard that long predates Perl, defines the term NUL, not NULL, to refer
to a null byte or null character. You are not correct, period or otherwise.
You are
completely out of your mind if you expect to
Thanks, Paris, for your intervention, although I fear it was too late.
Well, since Tom claims to have put me in his kill file, he may never see
this. But for the record...
Tom Christiansen wrote:
Can't we all just play nice?
Apparently not. Several of us attempted to explain why this
Philip Newton wrote:
Having $seen{$word}++ turn $seen{$word} to undef is bad, if (undef)++
assumes NULL semantics everywhere, hence "one more than unknown" = "still
unknown".
Right. Applying NULL semantics to undef would be bad. The counterproposals to
RFC 263, along the lines of "use
Graham Barr wrote:
On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote:
Russ Allbery wrote:
Why on earth would you want to do this in real code?
I wouldn't, of course. This is just a demonstration that I want both
semantics available concurrently.
If you
John Porter wrote:
Glenn Linderman wrote:
If they are the same, then you can't tell the different between a variable
that is yet uninitialized, and one that has been read in from the database,
containing a NULL. In my mind, that is horribly confusing.
Since this is a theoretical
Buddha Buck wrote:
Ok, let's see if I can make some sense of this...
Thanks for trying. I think you have.
You want a singleton scalar datatype in addition to the exising scalar
datatypes of strings, numbers, references, filehandles, and undef that
represents an unknown value, similar in
Russ Allbery wrote:
I'm not overlooking it; I just don't agree with you. There *is* a
difference.
You are certainly welcome to not agree with me. And if you didn't overlook
it, that is fine.
In my opinion, which you probably will also not agree with, attempting to
toggle between the
Michael Maraist wrote:
my/our @array :hashsyntax;
would hide the definition of %array in the same way that
my/our %array
would hide a prior definition of %array. And references to %array
would thenceforth actually be references to the keyed array @array.
I can see
RFC 186 is another interesting -io RFC, even though I'm not on the -io
list. I couldn't find any discussion in the mail archive, so here's
some to
start it. Please copy me on the discussion. Sorry for cross posting,
but
this is attempting to unify RFCs from different lists; I've bcc'd two of
Russ Allbery wrote:
use 'strict' is probably the difference between our code... I tend not to use
it, because I wrote a bunch of code that didn't, initially, before I heard of
it (maybe before it existed? I started with Perl 4.something), and haven't
gotten it all converted so that it can be
"John L. Allen" wrote:
On 29 Sep 2000, Perl6 RFC Librarian wrote:
Make Perl's powerful string interpolation facilities are available to
variables, in addition to literals.
=head1 DESCRIPTION
Given:
$foo = 'def';
$bar = 'ghi';
$x = "abc$foo$bar";
$y = 'abc$foo$bar';
Nathan Wiger wrote:
(And if the RFC is proposing autoquoting only barewords, then I think
that's _really_ inconsistent and should not be done.)
Isn't autoquoting only barewords precisely the type of autoquoting that = does?
So there is a precedent. I've been assuming all along that that is
"David L. Nicol" wrote:
This is a new feature, so name conflict is the only issue.
Thisseems compatiblewith otherextensionsto string
interpolation... whatever extensions get implemented should work here
too.
it's not a new feature. It's amazing the subtle
Bart Lateur wrote:
On 30 Sep 2000 20:13:55 -, Perl6 RFC Librarian wrote:
But setting $[ = 1 is the mathematically correct method for
array addressing and makes it easier for ordinary mortals to do
basic tasks with Csubstr(), array addressing and the like.
I sure don't want the fact
1 - 100 of 138 matches
Mail list logo
