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 "mod 8"
> (which it does).
Damnit, I'
On 13 Sep 2000, Perl6 RFC Librarian wrote:
> An inconsistency between "C" and "<>" bugs me: "C" means
> "C" so it seems like "<>" should mean "C<$_ = > <>".
> This would break code prompting for "Press any key" and wasting the
> input.
I suggest again:
s/"<>"/"C<< <> >>"/g; s/C<$_ = > <>/C<< $
Michael G Schwern <[EMAIL PROTECTED]> writes:
[...]
> I propose that this work out to
>
> "The old lie\n Dulce et decorum est\n Pro patria mori.\n"
>
> and always work out to that, no matter how far left or right the
> expression be indented.
>
>{ { { { {
> if(
On 13 Sep 2000, Perl6 RFC Librarian wrote:
> =head1 DESCRIPTION
>
> $_ is the default scalar for a small set of operations and functions.
> Most of these operations and functions are ones that use C<=~>.
Er, no. Quite a few others also use $_. The ones I found: -X filehandle
tests (except for -
I've implemented a prototype of the indented here-doc tag I'm proposing.
http://www.pobox.com/~schwern/src/RFC-Prototype-0.02.tar.gz
Its RFC::Prototype::111, which is probably the wrong number.
I'll have to add < be expanded.
2. POD end tags may now be followed by trailing whitespace
--
Michael,
I just noticed your post (I am at work). This is begining to get there (maybe I
should not have split the original
111).
In the prototype you only cover use of " quotes.
if( ($pre_code, $quote_type, $curr_tag, $post_code) = $_ =~
m/(.*)\<\<(")(\w+)"(.*)/ )
It needs to match (.*)<<(
use diagnostics;
my $i=1;
print 'hi' if ($i=1;
running this with perl -wc (v 5.004, unix), I get
perl -wc x.pl
syntax error at x.pl line 3, near "1;"
x.pl had compilation errors (#1)
(F) The final summary message when a perl -c fails.
Uncaught exception from user code:
Glenn Linderman wrote:
>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
On Thu, 14 Sep 2000 12:16:51 GMT, Ed Mills wrote:
>If I'm missing a "}" the compiler tells me its missing. That's also a syntax
>error, but it reports the actual missing "}". Why not do the same for ")"?
That reminds me: if Perl reports a missing "}", "]" or ")", it would
also be very nice if
> Sometimes I want a chunk of documentation to hang out near a
> chunk of code, but the order of the code is not always a good order for
> a man page.
Are you familiar with the C m4 command? L.
I'm not saying it would be the way to go; but it might be useful
to see how another preprocessing lan
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";
> substr($foo, index($foo, 'abc'
Ariel Scolnicov wrote:
>1. It requires the perl parser know about indentation. Of course we
> all know that tabs are 8 characters wide (I myself make a point of
> bludgeoning anyone who says otherwise), but do we really want to
> open this can of worms?
Not so fast with those 8-column tabs
In Michael Schwerns prototype, expansion to treat both semicolons and comments
at the end tag is possible by changing
/^(\s*)$curr_tag\s*$/
to
/^(\s*)$curr_tag\s*(;\s*)?(#.*)?$/
Richard
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 either of those. But
> 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 either o
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 either of those. But
Garrett Goebel wrote:
>Could someone shoot down or prop up the following:
>
>* Subroutines automatically get their name as a label
Ick! Shades of Pascal! Why don't we just replace "return $value"
with "subroutine_name = $value;"!
Seriously, what is the point of
sub func1
{
func
Jarkko Hietaniemi wrote:
> > In the other camp, C has been suggested; but
> > the conflation of that with its thread-related semantics may not
> > be a such good idea.
>
> C.
Well, "pass" might be o.k.; but it usually means something going
*into* a sub, not coming out...
--
John Porter
Eric Roode wrote:
>
> sub func1
> {
> func2();
> }
>
> sub func2
> {
> last func1;
> }
>
> ? Imho, it is a BAD THING for functions to know who called them,
> and to vary their behavior accordingly.
Yes. This is a serious downside to the propos
On Thu, Sep 14, 2000 at 11:46:31AM -0400, 'John Porter' wrote:
> Jarkko Hietaniemi wrote:
> > > In the other camp, C has been suggested; but
> > > the conflation of that with its thread-related semantics may not
> > > be a such good idea.
> >
> > C.
>
> Well, "pass" might be o.k.; but it usually
Garrett Goebel wrote:
>
> * Subroutines automatically get their name as a label
My concern here is whether it introduces a problem with C
vs. C. If, as you propose, subs do get their name as label,
I would like to conflate these two forms. But the semantics of
C specifies that @_ is passed as
> =head1 TITLE
>
> crypt() default salt
>
> =head1 VERSION
>
> Maintainer: Mark Dominus <[EMAIL PROTECTED]>
> Date: 11 Sep 2000
> Last Modified: 13 Sep 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 208
> Version: 2
> Status: Developing
If there are no objections, I will freez
From: John Porter [mailto:[EMAIL PROTECTED]]
> Eric Roode wrote:
> >
> > sub func1
> > {
> > func2();
> > }
> >
> > sub func2
> > {
> > last func1;
> > }
> >
> > ? Imho, it is a BAD THING for functions to know who called them,
> > and to vary the
On 14 Sep 2000, Ariel Scolnicov wrote:
> 1. It requires the perl parser know about indentation. Of course we
>all know that tabs are 8 characters wide (I myself make a point of
>bludgeoning anyone who says otherwise), but do we really want to
>open this can of worms?
No, b
> Show me where this fails and I'll shut up about it.
Actually, to me this thread underscores how broken here docs are
themselves. We already have q//, qq//, and qx// which duplicate their
functions far more flexibly. Question: Do we really need here docs?
Before you scream "Bloody murder", pleas
At 10:52 AM 9/14/00 -0700, Nathan Wiger wrote:
>Actually, to me this thread underscores how broken here docs are
>themselves. We already have q//, qq//, and qx// which duplicate their
>functions far more flexibly. Question: Do we really need here docs?
I have thought this before, but I think the
This whole debate has got silly.
RFC 111 V1 covered both the whitespace on the terminator and the
indenting - there was a lot of debate that this was two things - more were
in favour of the terminator and there was more debate on the indenting.
Therefore I split this into two RFCs leaving RFC111
Nathan Wiger wrote:
>Actually, to me this thread underscores how broken here docs are
>themselves. We already have q//, qq//, and qx// which duplicate their
>functions far more flexibly. Question: Do we really need here docs?
Yes.
Try generating lots of HTML, Javascript, Postscript, or other
lan
Richard Proctor made some excellent comments, and asked:
>When measuring whitespace how does the system treat tabs? (be realistic
>and dont FLAME)
I suggest that there be NO tab/space conversion. Not 8 columns, not
4 columns, nothing. If the here doc terminator has four tabs preceding
it, then f
Eric Roode wrote:
>
> I suggest that there be NO tab/space conversion.
I also suggest that no whitespace stripping/appending/etc/etc be done at
all. If I write:
if ( $its_all_good ) {
print <
Nathan Wiger wrote:
>
>I also suggest that no whitespace stripping/appending/etc/etc be done at
>all. If I write:
[...deletia...]
>But this shouldn't be implicit in the language.
That's a good argument for having a separate operator for these
"enhanced here docs", say <<<, rather than chucking th
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 "mod
On Thu, 14 Sep 2000 11:58:46 -0400, Mark-Jason Dominus wrote:
>If there are no objections, I will freeze this in twenty-four hours.
Oh, I have a small one: I feel that this speudo-random salt should NOT
affect the standard random generator. I'll clarify: by default, if you
feed the pseudo-random
On Thu, 14 Sep 2000 10:52:16 -0700, Nathan Wiger wrote:
>We already have q//, qq//, and qx// which duplicate their
>functions far more flexibly. Question: Do we really need here docs?
With your above functions, you always need to be able to escape the
string end delimiter. Therefore, you will al
This whole debate has got silly.
RFC 111 V1 covered both the whitespace on the terminator and the
indenting - there was a lot of debate that this was two things - more were
in favour of the terminator and there was more debate on the indenting.
Therefore I split this into two RFCs leaving RFC111
> > This reminds me of a related but rather opposite desire I have had
> > more than once: a quotish context that would be otherwise like q() but
> > with some minimal extra typing I could mark a scalar or an array to be
> > expanded as in qq().
>
> I have wanted that also, although I don't remem
On Thu, Sep 14, 2000 at 11:49:18AM -0700, Glenn Linderman wrote:
> I'm all for solving problems, and this message attempts to specify 3
> problems, but it needs more specification. You describe three
> problems, but it is not clear what the problems are
Since we've been charging back and forth o
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( $i
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: C pragma
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 14 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 223
Version: 1
Status: Developing
=head1 ABSTRACT
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 C pragma.
Uh, that should "invocand", should it not? In
> 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 $s
> 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 hand
Hey all.
Unfornatly, I don't have as much time for perl6 hacking as I'd like --
real life is rather getting in the way.
Therefore, the following RFCs are up for adoption:
149 (v1): Lvalue subroutines: implicit and explicit assignment -- This is a
comprimize RFC between the two lvalue subrotin
James Mastros wrote:
>
> RFC 163: Automatic accessors for hash-based objects -- This is the good one
> of mine . 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
On Thu, Sep 14, 2000 at 01:30:15PM -0700, Nathan Wiger wrote:
> Y'know, I pointed out before why I think this is a superfluous issue.
> You have to either change your regexp, or change the indentation of your
> here docs terminator when you move your code around.
I think it would be best for us
From: "Nathan Wiger" <[EMAIL PROTECTED]>
To: "James Mastros" <[EMAIL PROTECTED]>
Sent: Thursday, September 14, 2000 5:32 PM
Subject: Re: RFCs up for adoption, and a proto-RFC
> James Mastros wrote:
> > RFC 163: Automatic accessors for hash-based objects
> I'll gladly grab this from you. I think
> "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, o
Michael G Schwern wrote:
> On Thu, Sep 14, 2000 at 11:49:18AM -0700, Glenn Linderman wrote:
> > I'm all for solving problems, and this message attempts to specify 3
> > problems, but it needs more specification. You describe three
> > problems, but it is not clear what the problems are
>
> Since
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
> intere
> 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 < \$!
> \$! execute a.com, copy and purge
> \$!
> \$ \@sys\$log
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 thi
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.
> > 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 th
Michael G Schwern wrote:
[...]
> Personally, I'd solve this with sprintf():
>
> print F sprintf <<'END', $filename;
> $!
> $! execute a.com, copy and purge
> $!
> $ @sys$login:a.com
> $ copy %s sys$login:*.*
> $ purge sys$login:$filename
> $!
> $ exit
>
> but
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 ma
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
On Fri, Sep 15, 2000 at 10:29:31AM +1100, 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;
That would be four keystrokes
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. M
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 thi
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 <>2||($_<<2>12)){$_="Vainyvq ragel";&{$F[0]};last;}&t;$0-=$_;$_="Lbh jva";
die(&{$F[0]}) if !($0-1);$0-=$0%2?$0>2?2:1:$0<=
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 t
> 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
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
> > 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 yo
> "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 sh
> 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 ano
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 requires.
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
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
Sta
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
=hea
Dave Storrs <[EMAIL PROTECTED]> writes:
[...]
> > print << FIRST_HERE_DOC; print << SECOND_HERE_DOC;
> > This is on the left margin.
> > This is indented one char.
> > FIRST_HERE_DOC
> > This is indented one char.
> > This is on the left margin.
> > SECOND_HERE_D
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
> >
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
Mailing List: [EMAIL PROTECTED]
Number: 226
Version: 1
Status: D
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]
Numbe
85 matches
Mail list logo
