On Thu, Sep 14, 2000 at 10:52:16AM -0700, Nathan Wiger wrote:
Before you scream "Bloody murder", please read on...
I'll wait patiently for the end...
if( $is_fitting $is_just ) {
die subst /\s{8}(.*?\n)/$1/g, qq/
The old lie
Dulce et decorum est
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... -- Robert Byrne
Michael G Schwern wrote:
No, it still has all the problems of any other regex-based solution.
If you shift the code right or left, it breaks (due to the \s{8}) and
you're back to counting whitespace again.
Y'know, I pointed out before why I think this is a superfluous issue.
You have to
This RFC proposes that, as in Perl 5, the invocant of a method should be
normally available to the method as $_[0], but that it can be
automaticaly stripped from @_ and accessed via either a subroutine
or a variable, using the Cuse invocant pragma.
Uh, that should "invocand", should it not?
Uh, that should "invocand", should it not?
No.
Unless the OO community has already decided this issue unbeknownst to me...
As of Camel III "invocant" is the way to refer to the reference to an object
through which a method is called. I.e. the reference that inevitably ends up
in
Mailing List: [EMAIL PROTECTED]
Just to nitpick, this should probably be perl6-language-objects
sub method ($self, @args) {
...
}
and this may, indeed, be sufficient.
Remember, this still won't solve the problem of a module whose functions
can handle
James Mastros wrote:
RFC 163: Automatic accessors for hash-based objects -- This is the good one
of mine G. I would really like to see somthing like this in perl6. Get
rid of the byzanthine access specifiers, and just get a :laccess, :raccess,
and :access method. Look at the archives of
"NT" == Nathan Torkington [EMAIL PROTECTED] writes:
NT Chaim Frenkel writes:
Somehow I find
if (40 == ($foo = substr($bar, index($bar, 'xyz' {
}
NT I don't understand your hypothetical code. substr() returns the
NT substring of $bar from the position retutned by index, onward.
NT When
On Thu, Sep 14, 2000 at 02:51:14PM -0700, Glenn Linderman wrote:
Michael G Schwern wrote:
Well, OK, so now we're talking shades of opinion. You'd agree it
works, though, and quite effectively. But you'd disagree about its
aesthetics, and its performance. The former is much less
seconded by Mark-Jason Dominus [EMAIL PROTECTED]
Except that I don't think adding this feature to the existing q{...}
is a good idea. If I had to vote on your proposal, I would instantaly
vote against it. I think you should have invented a new operator or a
pragma or something.
I have misgivings. I like single-quote context *because* you don't
have to worry about anything magical (except ' and \).
On Thu, Sep 14, 2000 at 09:52:12PM -, Perl6 RFC Librarian wrote:
print F END;
\$!
\$! execute a.com, copy and purge
\$!
\$
On Thu, Sep 14, 2000 at 06:04:41PM -0400, Mark-Jason Dominus wrote:
seconded by Mark-Jason Dominus [EMAIL PROTECTED]
Except that I don't think adding this feature to the existing q{...}
is a good idea. If I had to vote on your proposal, I would instantaly
vote against it. I think you
The perl 5 - perl 6 translator should replace calls to 'eval' with
calls to 'perl5_eval', which will recursively call the 5-6 translator
to translate the eval'ed string into perl 6, and will then eval the
result.
Mark-Jason Dominus [EMAIL PROTECTED]
On Thu, Sep 14, 2000 at 05:11:39PM -0500, Jarkko Hietaniemi wrote:
On Thu, Sep 14, 2000 at 06:04:41PM -0400, Mark-Jason Dominus wrote:
seconded by Mark-Jason Dominus [EMAIL PROTECTED]
Except that I don't think adding this feature to the existing q{...}
is a good idea. If I had to
One could for example have a pragma to *really* tag variables
lexically to be expanded within singlequotes.
Or a pragma that simply changes the semantics of q{...} so that it has
the proposed feature for the rest of the scope of the current block.
On Thu, Sep 14, 2000 at 06:17:07PM -0400, Mark-Jason Dominus wrote:
One could for example have a pragma to *really* tag variables
lexically to be expanded within singlequotes.
Or a pragma that simply changes the semantics of q{...} so that it has
the proposed feature for the rest of
Michael G Schwern wrote:
I'd prefer if here-docs just DWIM.
Yes, but... what do you mean vs. what do others mean, and all these
problems
Others can continue to put the here-doc tag flush left if they don't
want this behavior.
See, this is just too inflexible. The main
Mark-Jason Dominus wrote:
The perl 5 - perl 6 translator should replace calls to 'eval' with
calls to 'perl5_eval', which will recursively call the 5-6 translator
to translate the eval'ed string into perl 6, and will then eval the
result.
And that gives us a convenient name space for
Why not just give \I..\E a special "turn-on-interpolation" meaning in
q{} docs?
$code = '
$x = $y;
@a = (1..10);
$name = \I$funcname\E;
# etc.
';
Damian
Damian Conway wrote:
Why not just give \I..\E a special "turn-on-interpolation" meaning in
q{} docs?
$code = '
$x = $y;
@a = (1..10);
$name = \I$funcname\E;
# etc.
';
Damian
Yes. Modified RFC to
What's wrong with extending current syntax such that:
$a = "Hello";
print q(@{[$a]} World), "\n";
outputs
Hello World
instead of
@{[$a]} World
yes, it's a few extra char's but IMHO
it's a logical extension
it makes you think twice before doing it, do you really need to do
Oh yeah I forget to outline what it currently does for those whom may not have
seen it...
It's usally used for evaluation and interplation of code/subroutines
in "", qq() and HERE. And of course works fine on hashes, scalars, and
arrays.
So it's simply changing perl to check for this in q().
On Thu, Sep 14, 2000 at 10:01:23PM -0400, Jerrad Pierce wrote:
What's wrong with extending current syntax such that:
Please read the discussion so far.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Hang on... \I \E amounts to the same number of characters as using
'. .' (that is, terminating this q-string, concat the thing, start
a new q-string) So for scalars, there would be no savings at all.
For arrays, yes, the proposed \I \E would still be useful. Maybe the
\I should just scan for
Hang on... \I \E amounts to the same number of characters as using
'. .' (that is, terminating this q-string, concat the thing, start
a new q-string)
You can't do that in a 'HERE' doc.
For arrays, yes, the proposed \I \E would still be useful. Maybe the
\I should just
On Fri, Sep 15, 2000 at 01:56:39PM +1100, Damian Conway wrote:
Hang on... \I \E amounts to the same number of characters as using
'. .' (that is, terminating this q-string, concat the thing, start
a new q-string)
You can't do that in a 'HERE' doc.
True.
For arrays,
No thanks. Suppose I want:
'$x = $a;
$y = func(\I$arg1, $arg2, $arg3\E);
Hmmm...should \Ifunc($arg1)\E be replaced by the return value of
func($arg1)?
I don't think so. I think \I..\E should just impose qq{..} semantics on
the text in between. So you'd still
"DC" == Damian Conway [EMAIL PROTECTED] writes:
No thanks. Suppose I want:
'$x = $a;
$y = func(\I$arg1, $arg2, $arg3\E);
Hmmm...should \Ifunc($arg1)\E be replaced by the return value of
func($arg1)?
DC I don't think so. I think \I..\E should just impose qq{..}
that makes good sense. so in a single quote string you can have domains
of double quote behavior.
That's it exactly. Very well expressed, thanks Uri.
now, what if the double quoted range had a \E in it? either directly or
via interpolation? maybe the end escape should be
Michael G Schwern writes:
I have misgivings. I like single-quote context *because* you don't
have to worry about anything magical (except ' and \).
Genericise it.
Alter the overloaded string constant behaviour of perl5 so that
when you say:
use MagicInterpolativeStrings;
$foo = '$bar
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Inline Comments for Perl.
=head1 VERSION
Maintainer: Glenn Linderman [EMAIL PROTECTED]
Date: 14 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 102
Version: 2
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Variable interpolation on demand.
=head1 VERSION
Maintainer: Glenn Linderman [EMAIL PROTECTED]
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 229
Version: 1
Status: Developing
David L. Nicol wrote:
This ability to jump to "the right place" is exactly what exception handling
is for, as I understand it. Exceptions allow us to have one kind of block
and any number of kinds of exit mechanisms. If qC(last die return) are all
excpetions, the can travel up the call
'John Porter' wrote:
David L. Nicol wrote:
"Randal L. Schwartz" wrote:
I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Selective interpolation in single quotish context.
=head1 VERSION
Maintainer: Brad Hughes [EMAIL PROTECTED]
Date: Sep. 14, 2000
Last Modified: Sep. 14, 2000
Mailing List: [EMAIL PROTECTED]
101 - 138 of 138 matches
Mail list logo
