This week's summary
Uri Guttman
PC> tricky options, but Marco Baringer won the 'simplest thing that could
PC> possibly work' prize from your summarizer with:
PC> macro include ($file) {
PC> join '', <open $file>;
PC> }
PC> which does the job very straightforwardly.
but inefficiently as it splits (internally) and joins lines for no
reason. i have been using a read_file sub for years and it does local $/
to slurp to a single string. i changed that to a read with -s $file for
speed.
my syntax will be totally wrong here but i recall something about
setting a slurp property on a file handle during open. so i will call it
slurp and internally it should do the fastest read of the complete file
and not parse it at all (unless you set properties like unicode and
such).
macro include ($file) {
$(<open $file>.slurp) ;
}
that is run the <> operator with the slurp property in scalar
context. maybe the slurp needs to be on the file or the return value
from open:
$(<(open $file).slurp>) ;
and of course i think there is something for this already but i would
have no idea where to search for it. i am sure the group mind knows it.
anyhow, i just don't like seeing join( '' ) when it is not needed.
and i like the actual macro concept for include, i just want a
better/faster implementation.
in fact the read_file thing i use in p5 could be rewritten in p6 and
used there. my code above is a poor attempt at the scalar mode. my p5
sub uses wantarray to handle both contexts.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Dulcimer
> PC> join '', <open $file>;
> PC> }
>
> reason. i have been using a read_file sub for years and it does local
> $/ to slurp to a single string. i changed that to a read with -s
$file
> for speed.
It might not be for no reason.
Yes, I'll agree that the operation is not required, and there is
definitely an efficiency argument to be made.
On the other hand, even newbies will be able to quickly look at it and
understand it, and if not, look it up and get it, and if not, they need
to study some more. It's a touch kludgy, but it's damned readable. I
know people who prefer it for that very reason, even though it works
the machine harder than it has to.
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Uri Guttman
PC> macro include ($file) {
PC> join '', <open $file>;
PC> }
>>
>> but inefficiently as it splits (internally) and joins lines for no
>> reason. i have been using a read_file sub for years and it does local
>> $/ to slurp to a single string. i changed that to a read with -s
D> $file
>> for speed.
D> It might not be for no reason. Yes, I'll agree that the operation
D> is not required, and there is definitely an efficiency argument to
D> be made. On the other hand, even newbies will be able to quickly
D> look at it and understand it, and if not, look it up and get it,
D> and if not, they need to study some more. It's a touch kludgy, but
D> it's damned readable. I know people who prefer it for that very
D> reason, even though it works the machine harder than it has to.
this is the sort of macro that will be so useful and common it will
almost surely be distributed as a pragma/module in p6's core. as such it
should be written to be as fast as possible and clarity should be a
secondary goal to speed. and the slurp mode on a handle will be there
for sure (the global $/ as in p5 is dead) so it should be used in this
macro. i expect there will be many such common and useful macros that
will be in the core distro and will be written by the p6 dev team
(including those on this list).
Dulcimer
> PC> join '', <open $file>;
> PC> }
>
> almost surely be distributed as a pragma/module in p6's core. as such
> it should be written to be as fast as possible and clarity should be
> a secondary goal to speed. and the slurp mode on a handle will be
> there for sure (the global $/ as in p5 is dead) so it should be used
> in this macro. i expect there will be many such common and useful
> macros that will be in the core distro and will be written by the p6
> dev team (including those on this list).
Ok. Agreed.
Michael Lazzaro
>> it should be written to be as fast as possible and clarity should be
>> a secondary goal to speed. and the slurp mode on a handle will be
As an aside, I vaguely hope 'slurp' mode will be the default mode for
filehandles. The number of times I read a file line-by-line, vs. the
number of times I slurp a file in entirety, has historically been quite
small. Furthermore, newbies can find the current behavior -- the extra
coded needed to "just read the damn file, dammit!" -- nonintuitive.
Not saying line-by-line isn't useful, obviously, especially for
logs/pipes/etc. But I wonder which case is more prevalent ITRW...
MikeL
Michael Lazzaro
On Tuesday, May 6, 2003, at 09:52 AM, Adam D. Lopresto wrote:
> Slurp mode should definitely be easy, but I don't think it should be
> the
> default for filehandles, because filehandles themselves are way too
> much
> baggage if all you want is a slurp of the file contents. The purpose
> of a
> filehandle is to be able to do multiple reads. If you can only do one
> at most,
> it seeems pointless. Actually, seems like it should be a function
> (builtin?
> or standard package?)
>
> my $contents = slurp $filename;
And of course, it should be possible to simply say: [*]
my URI $loc = 'http://thing.blah.stuff/index.html';
my $contents = <$loc>;
MikeL
[*] ...Danger...Speculation level rising...Thread breach
imminent...Automatic thread shutdown in 5...4...3...
Mark J. Reed
On 2003-05-06 at 09:41:36, Michael Lazzaro wrote:
> Not saying line-by-line isn't useful, obviously, especially for
> logs/pipes/etc. But I wonder which case is more prevalent ITRW...
the time I can assume that a file I'm processing is small enough
to slurp into memory all in one chunk.
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
Adam D. Lopresto
default for filehandles, because filehandles themselves are way too much
baggage if all you want is a slurp of the file contents. The purpose of a
filehandle is to be able to do multiple reads. If you can only do one at most,
it seeems pointless. Actually, seems like it should be a function (builtin?
or standard package?)
my $contents = slurp $filename;
Bonus points of $contents gets silently bound to an object that lazily
stringifies itself only as needed.
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Her date was pleasant enough, but she knew that if her life was a
movie this guy would be buried in the credits as something like
"Second Tall Man." (Russell Beland, Springfield)
Dulcimer
> > be the default for filehandles, because filehandles themselves are
> > way too much baggage if all you want is a slurp of the file
> > contents. The purpose of a filehandle is to be able to do multiple
> > reads. If you can only do one at most, it seeems pointless.
Very rarely do I read in a whole file at a time.
Maybe once we get converted to a database and I get to work with some
small files, but in the meantime, I live in a world where I don't even
have space to decompress before I read -- I have to take my inoput from
the end of a pipe.
Either way, I don't think slurpy should be the default, though a trait
would be nice.
> > Actually, seems like it should be a function (builtin?
> > or standard package?)
> > my $contents = slurp $filename;
Agreed.
> And of course, it should be possible to simply say: [*]
> my URI $loc = 'http://thing.blah.stuff/index.html';
> my $contents = <$loc>;
Dunno about "or course" there, but I like the idea....
All in all, though, I still don't have a problem with
my $content = join '', <$loc>;
Uri Guttman
>>> it should be written to be as fast as possible and clarity should be
>>> a secondary goal to speed. and the slurp mode on a handle will be
ML> As an aside, I vaguely hope 'slurp' mode will be the default mode for
ML> filehandles. The number of times I read a file line-by-line, vs. the
ML> number of times I slurp a file in entirety, has historically been
ML> quite small. Furthermore, newbies can find the current behavior --
ML> the extra coded needed to "just read the damn file, dammit!" --
ML> nonintuitive.
ML> Not saying line-by-line isn't useful, obviously, especially for
ML> logs/pipes/etc. But I wonder which case is more prevalent ITRW...
even though in much of my code i slurp files, i think line by line
should be the default. i know my slurped files are short and there won't
be any memory issues. i slurp since i need to parse the whole file (in
various formats) and they expect a string and not a handle (like eval or
YAML Load). but many (if not) most text handling scripts do line by line
loops and that should be the default. think about -n and -p loops in p5
as well. you have to enable slurp on them with -0777.
Michael Lazzaro
On Tuesday, May 6, 2003, at 12:08 PM, Uri Guttman wrote:
> even though in much of my code i slurp files, i think line by line
> should be the default. i know my slurped files are short and there
> won't
> be any memory issues. i slurp since i need to parse the whole file (in
> various formats) and they expect a string and not a handle (like eval
> or
> YAML Load). but many (if not) most text handling scripts do line by
> line
> loops and that should be the default.
Yep, y'all are probably right. Vague aside withdrawn.
MikeL
Luke Palmer
> default for filehandles, because filehandles themselves are way too much
> baggage if all you want is a slurp of the file contents. The purpose of a
> filehandle is to be able to do multiple reads. If you can only do one at most,
> it seeems pointless. Actually, seems like it should be a function (builtin?
> or standard package?)
>
> my $contents = slurp $filename;
>
> Bonus points of $contents gets silently bound to an object that lazily
> stringifies itself only as needed.
E3 seems to think this will suffice:
my $contents = <open $filename : irs => undef>
I agree. And in hopes that the adverbial modifier becomes C<where> as
Damian suggested, it would look like this:
my $contents = <open $filename where irs => undef>
Which is so readable it gives me the shivers.
Luke
Luke Palmer
> > Slurp mode should definitely be easy, but I don't think it should be
> > the
> > default for filehandles, because filehandles themselves are way too
> > much
> > baggage if all you want is a slurp of the file contents. The purpose
> > of a
> > filehandle is to be able to do multiple reads. If you can only do one
> > at most,
> > it seeems pointless. Actually, seems like it should be a function
> > (builtin?
> > or standard package?)
> >
> > my $contents = slurp $filename;
>
> And of course, it should be possible to simply say: [*]
>
> my URI $loc = 'http://thing.blah.stuff/index.html';
> my $contents = <$loc>;
Provided the appropriate URI class, sure. Better yet:
my $contents = <'http://thing.blah.stuff/index.html' as URI>;
Luke
> MikeL
>
> [*] ...Danger...Speculation level rising...Thread breach
> imminent...Automatic thread shutdown in 5...4...3...
2...1...
Oh and anoth *BOOM*
Austin Hastings
Maybe this is C<assuming>-like?
my $contents = <open $filename>.assuming(irs => undef);
I'm still pulling for adverbial modification to simple operations, like
(as has been mentioned before): $x ==:id $y
Which might become {$x == $y}.assuming(.VALUE := .id);
By process of "default" could be: {$x == $y}.assuming(.id);
Which then becomes $x ==:.id $y
And then the C<where> syntax becomes a postfix version of the same
thing. We could make it even more readable by allowing parens:
$x == $y (where .VALUE := .id) ?? print "Same" :: print "Not";
$contents = <open $filename where irs => undef>;
The problem is "modification scope". The C<irs => undef> in the prior
example will bind to the open call. So C<open($filename, irs => undef)>
rather than
$temp = open $filename;
my $contents = <$temp where irs => undef>;
which might have to be written
my $contents = (<$temp> where irs => undef);
Obviously, a parenless postfix would apply to the assignment:
my @contents = <open $filename> where persistent = false;
Or maybe it's better to think of adverbial annotation as a shorthand
for C<where>.
=Austin
Uri Guttman
LP> E3 seems to think this will suffice:
LP> my $contents = <open $filename : irs => undef>
and that was the syntax i alluded to but couldn't remember. i recalled
seeing a handle property (irs is a per handle $/).
here is a great place for a simple macro (again, i don't have the macro
syntax down) that replaces slurp with irs => undef
my $contents = <open $filename : slurp>
or even a higher level macro that does the <open> as well:
use slurp ;
my $contents = slurp $filename ;
and we have the slurp 'operator' which would be very cool.
LP> my $contents = <open $filename where irs => undef>
LP> Which is so readable it gives me the shivers.
more readable than the slurp macro? :)
Luke Palmer
I would imagine not. You see, C<assuming> is a method on code objects
which returns a new code object identical to the old one with some
parameters prebound (and if the implementation wants, constant folded
WRT that change).
The thing returned by <open $filename> is a string, which has no
C<assuming> method.
> I'm still pulling for adverbial modification to simple operations, like
> (as has been mentioned before): $x ==:id $y
>
> Which might become {$x == $y}.assuming(.VALUE := .id);
>
> By process of "default" could be: {$x == $y}.assuming(.id);
>
> Which then becomes $x ==:.id $y
>
> And then the C<where> syntax becomes a postfix version of the same
> thing.
No, C<assuming> and adverbial modification are fundamentally
different.
> We could make it even more readable by allowing parens:
>
> $x == $y (where .VALUE := .id) ?? print "Same" :: print "Not";
>
> $contents = <open $filename where irs => undef>;
>
> The problem is "modification scope". The C<irs => undef> in the prior
> example will bind to the open call. So C<open($filename, irs => undef)>
> rather than
> $temp = open $filename;
> my $contents = <$temp where irs => undef>;
>
> which might have to be written
>
> my $contents = (<$temp> where irs => undef);
E3 does this:
my $contents = < $temp.irs(undef) >;
But that supposedly sets irs forever, until changed again. It's not a
problem in this case, because you won't sanely be doing any more reads
after you've slurped. However, for other purposes, it could be
inconvenient.
On the other hand, .irs could be made to return a different but
related handle where the irs is set differently. Then we could get
one-shot modification.
And then, there's always:
{ temp $temp.irs = undef;
$contents = <$temp>;
}
But then, that's awfully Perl5ish, on one of Perl5's weak points.
> Obviously, a parenless postfix would apply to the assignment:
>
> my @contents = <open $filename> where persistent = false;
Yeah... obviously... (?)
> Or maybe it's better to think of adverbial annotation as a shorthand
> for C<where>.
Uhh... I thought C<where> was precisely adverbial annotation.
Or are you referring to the following syntax:
my @contents =:persistent(0) <open $filename>
Which I don't think is such a bad idea for operators, I just don't
like it on named calls, as it can easily be confused with invocant
specification.
Luke
Uri Guttman
LP> The thing returned by <open $filename> is a string, which has no
LP> C<assuming> method.
i think it will return a list of lines in a list context like p5
does. and assuming is to create new subs which assume values for some
args in another sub.
LP> On the other hand, .irs could be made to return a different but
LP> related handle where the irs is set differently. Then we could get
LP> one-shot modification.
LP> And then, there's always:
LP> { temp $temp.irs = undef;
LP> $contents = <$temp>;
LP> }
LP> But then, that's awfully Perl5ish, on one of Perl5's weak points.
i think this might work (i changed the handle name to remove confusion):
$contents = do { temp $fh.irs ; <$fh> }
and maybe even this:
$contents = <temp $fh.irs> ;
if <> works only on the handle part of the temp expression it should be
fine. i would expect (hope?) the temp to undef the irs property and
return the handle itself. or as i said the <> will figure out how to get
the handle from somewhere.
but the slurp macro is a better solution IMO. the above is only for when
you already have an open handle (e.g. a pipe or socket) and want to
slurp it.
Damian Conway
that we'll be able to unify heredocs, POD, and general file slurping.
Specifically, I hope Perl 6 will have a unary << operator, which would operate
as follows:
* If the operand evaluates to a string starting with "=", grab the next
available POD section with the same tag as the string and slurp it.
* If the operand is a string literal that does not begin with an "=",
slurp the immediately following source lines until that literal
appears by itself (modulo whitespace) on a line. Initial whitespace on
the terminator line would be stripped from the content lines.
* If the operand is a filehandle, slurp it.
Oh, and the section formerly known as:
__DATA__
would become a POD section:
=data [OPTIONAL_NAME]
So we get the old heredoc behaviour:
my $contents = << 'EOCONTENTS'
Are you content?
Yes, thanks, I am very content. And you?
I am content too!
EOCONTENTS
Plus access to any pod section we might need, including the new =data section:
print << '=head1 Usage' if $cmdline_error;
my $contents = << '=data';
# and much later...
=head1 Usage
format <filename> [options]
=data
Fascinating.
I appear to be unable to use contractions.
Plus we get all of Inline::File's handy multiple-data functionality:
my $contents = << '=data CONTENTS';
my $commentary = << '=data COMMENTARY';
# and much later...
=data CONTENTS
I am very content,
even though I am unable to use contractions.
=data COMMENTARY
Subject reports he's very content,
even though he's unable to use contractions
like a real boy.
Nose is unusually elongated too.
=end
Plus we get a slurp operator on regular filehandles:
my $contents = << open $filename;
Not bad, huh? :-)
The only real issue is how to let such a "Swiss Army Slurp" operator co-exist
with Larry's proposed ASCII:
<<list of words>>
synonym for:
«list of words»
And, whilst I have several ideas on achieving that, so far all of them are
unsatisfactory (because they tend to rely on whitespace becoming significant).
:-(
Damian
Luke Palmer
> that we'll be able to unify heredocs, POD, and general file slurping.
>
> Specifically, I hope Perl 6 will have a unary << operator, which would operate
> as follows:
>
> * If the operand evaluates to a string starting with "=", grab the next
> available POD section with the same tag as the string and slurp it.
>
> * If the operand is a string literal that does not begin with an "=",
> slurp the immediately following source lines until that literal
> appears by itself (modulo whitespace) on a line. Initial whitespace on
> the terminator line would be stripped from the content lines.
>
> * If the operand is a filehandle, slurp it.
>
> Oh, and the section formerly known as:
>
> __DATA__
>
> would become a POD section:
>
> =data [OPTIONAL_NAME]
That's pretty cool.
> [snip]
>
> The only real issue is how to let such a "Swiss Army Slurp" operator co-exist
> with Larry's proposed ASCII:
>
> <<list of words>>
>
> synonym for:
>
> «list of words»
>
> And, whilst I have several ideas on achieving that, so far all of them are
> unsatisfactory (because they tend to rely on whitespace becoming significant).
Just an idea, but what about context?
<< HEREDOC; << '=head1 USAGE'; << open $filename;
will always be strings, while
<< list of words >>
will always be a list. So do one in string (or just scalar) context,
and the other in list. You could use the context-forcing characters
to disambiguate:
~<<HEREDOC
*<<list of words>>
It makes me uneasy, though, because it's discrimitating context at
compile time, when it may not know the actual context yet. But it's
not like that stopped Perl 5 from differentiating between unary and
list operators...
Luke
Damian Conway
> Just an idea, but what about context?
>
> << HEREDOC; << '=head1 USAGE'; << open $filename;
>
> will always be strings, while
>
> << list of words >>
The problem is that working out *syntactically* what any << means
could potentially require arbitrary look-ahead. For example:
# slurp...
<< open getfile; foo(bar); exit;
vs:
# list...
<< open getfile; foo(bar); exit; >>
You can't know which you have until you hit the >> (or EOF) :-(
Damian
Uri Guttman
DC> The problem is that working out *syntactically* what any << means
DC> could potentially require arbitrary look-ahead. For example:
DC> # slurp...
DC> << open getfile; foo(bar); exit;
DC> vs:
DC> # list...
DC> << open getfile; foo(bar); exit; >>
so why not make the smart heredoc operator be <<~ or <<< ?
i like the concept a lot but i still want all ops to be in (or have
aliases in) plain ascii. i don't think requiring unicode is a good
idea. so <<>> is still needed and the smart heredoc needs a
non-conflicting token.
Austin Hastings
Not so. Lots of uses exist for "read all the lines into an array".
You're going to have an array on the LHS a goodly percentage of the
time, I think.
=Austin
Luke Palmer
> >
> > << HEREDOC; << '=head1 USAGE'; << open $filename;
> >
> > will always be strings, while
> >
>
> Not so. Lots of uses exist for "read all the lines into an array".
> You're going to have an array on the LHS a goodly percentage of the
> time, I think.
That's funny, because in Perl 5, this:
@array = <<LINES;
Hi
Diddly
Ho
LINES
Reads the whole thing into the first element.
But, as Damian pointed out, there's a parsing problem anyway.
However, the parser being top-down this time might be able to keep
track of the current context as it parses. So this:
<< HEREDOC; print "Hithere!"; >>
Would be a syntax error at >>, unless there was something on the left
putting it in list context. I can't be sure this is possible though,
with as complex a grammar as Perl 6 has.
I'll just express now that if there's no other way to disambiguate, it
isn't at all bad to use an altranate token, such as <<< or \\, for
heredocs/slurps/etc.
We're not currently using the EBay token for anything:
print L@@K***>>>>>>> VINTAGE EOT <<<<<<<***
Hello, World!
EOT
Luke
Austin Hastings
> > >
> > > << HEREDOC; << '=head1 USAGE'; << open $filename;
> > >
> > > will always be strings, while
> > >
> >
> > Not so. Lots of uses exist for "read all the lines into an array".
> > You're going to have an array on the LHS a goodly percentage of the
> > time, I think.
>
> That's funny, because in Perl 5, this:
>
> @array = <<LINES;
> Hi
> Diddly
> Ho
> LINES
>
> Reads the whole thing into the first element.
Sure, but we're not trying to do P5. Plus, if the << (or whatever) is
going to become the default idiom for fileslurping, then it should work
right.
=Austin
Michael Lazzaro
On Tuesday, May 6, 2003, at 10:39 PM, Damian Conway wrote:
> The only real issue is how to let such a "Swiss Army Slurp" operator
> co-exist with Larry's proposed ASCII:
>
> <<list of words>>
>
> synonym for:
>
> «list of words»
>
> And, whilst I have several ideas on achieving that, so far all of them
> are unsatisfactory (because they tend to rely on whitespace becoming
> significant).
At the risk of becoming a HEREtic, my love of the <<list of words>>
syntax is limited.
I do not particularly see what it gains us over qw<list of words>; in
fact, I believe the C<qw()> form to be more readable, personally, than
either that or the Unicode-enabled «list of words».
The prospect of being able to more freely use << and >> as operators
seems to be a higher use for those chars; I hope the <<list of words>>
syntax is reconsidered.
This is not to say every decision should be constantly revisited, of
course, but in coming up with things like the final operator list, it
seems fair to reconsider something if a potentially superior proposal
is later made.
MikeL
Dulcimer
--- Michael Lazzaro <mlaz...@cognitivity.com> wrote:
> On Tuesday, May 6, 2003, at 10:39 PM, Damian Conway wrote:
> > The only real issue is how to let such a "Swiss Army Slurp"
> > operator co-exist with Larry's proposed ASCII:
> >
> > <<list of words>>
> >
> > synonym for:
> >
> > «list of words»
> >
> > And, whilst I have several ideas on achieving that, so far all of
> > them are unsatisfactory (because they tend to rely on whitespace
> > becoming significant).
>
> At the risk of becoming a HEREtic, my love of the <<list of words>>
> syntax is limited.
>
> I do not particularly see what it gains us over qw<list of words>;
> in fact, I believe the C<qw()> form to be more readable, personally,
> than either that or the Unicode-enabled «list of words».
I have to concur. <<list of words>> just doesn't jump out at me
clearly.
qw<list of words> is just as tightly Huffman encoded ata total of four
characters for such a common and useful operator, but the benefits of Q
from "quote" and W from "words" being readily visible establishes a
very effective mnemonic, and provides more visual cue that "there's
something important going on here," as well as helping to explain to
newbies *what* is going on.
> The prospect of being able to more freely use << and >> as operators
> seems to be a higher use for those chars; I hope the <<list of
> words>> syntax is reconsidered.
>
> This is not to say every decision should be constantly revisited, of
> course, but in coming up with things like the final operator list, it
> seems fair to reconsider something if a potentially superior proposal
> is later made.
Absolutely. Besides, unless there's a darned good reason to change,
this is something I always *liked* in P5, and there is something to be
said for consistency.
I wouldn't even complain if you told me that I have to use certain
delimiters such as () or // or even <> with qw, though I prefer qw// myself.
Arcadi Shehter
another possibility is that "slurp" will be that smart heredocs
operator
and the syntax proposed will go inside '...'
$one = slurp '<<ONE' ;
1111
ONE
...
$two = slurp '=data TWO' ;
$three = slurp 'file.p6' ;
$three = slurp open '../file.p6' ;
=data TWO
2222
=cut
arcadi
Luke Palmer
> > On Tuesday, May 6, 2003, at 10:39 PM, Damian Conway wrote:
> > > The only real issue is how to let such a "Swiss Army Slurp"
> > > operator co-exist with Larry's proposed ASCII:
> > >
> > > <<list of words>>
> > >
> > > synonym for:
> > >
> > > «list of words»
> > >
> > > And, whilst I have several ideas on achieving that, so far all of
> > > them are unsatisfactory (because they tend to rely on whitespace
> > > becoming significant).
> >
> > At the risk of becoming a HEREtic, my love of the <<list of words>>
> > syntax is limited.
> >
> > I do not particularly see what it gains us over qw<list of words>;
> > in fact, I believe the C<qw()> form to be more readable, personally,
> > than either that or the Unicode-enabled «list of words».
>
> I have to concur. <<list of words>> just doesn't jump out at me
> clearly. qw<list of words> is just as tightly Huffman encoded ata
> total of four characters for such a common and useful operator, but
> the benefits of Q from "quote" and W from "words" being readily
> visible establishes a very effective mnemonic, and provides more
> visual cue that "there's something important going on here," as well
> as helping to explain to newbies *what* is going on.
Well gee, I like it. qw is very common, and <<this is pretty>>.
Plus, we have an unnamed version of every other quoting construct.
I<There's> consistency for you.
'Course, this isn't much the subject of an argument, because it's 104%
opinion. So, er, <<go!>>
Luke
Michael Lazzaro
On Wednesday, May 7, 2003, at 10:39 AM, Luke Palmer wrote:
>> --- Michael Lazzaro <mlaz...@cognitivity.com> wrote:
>>> On Tuesday, May 6, 2003, at 10:39 PM, Damian Conway wrote:
>>>> The only real issue is how to let such a "Swiss Army Slurp"
>>>> operator co-exist with Larry's proposed ASCII:
>>>>
>>>> <<list of words>>
>>>>
>>>> synonym for:
>>>>
>>>> «list of words»
>>>>
>>>> And, whilst I have several ideas on achieving that, so far all of
>>>> them are unsatisfactory (because they tend to rely on whitespace
>>>> becoming significant).
>>>
>>> At the risk of becoming a HEREtic, my love of the <<list of words>>
>>> syntax is limited.
> Well gee, I like it. qw is very common, and <<this is pretty>>.
> Plus, we have an unnamed version of every other quoting construct.
> I<There's> consistency for you.
Oops, let me rephrase. I *like* the <<list of words>> syntax just
fine, FWIW, but I like the notion of an uber-powerful unary << operator
much _more_. Could we just have Unicode-style «list of words», and
save unary << and >>, mebbe?
Regardless of how consolidated HEREDOC-style << can or can't be, it
still conflicts with <<list>> in annoying ways, as we've noted in the
past...
my @list = <<token1
token2
token3
>>;
Now that's just icky.
MikeL
Smylers
> Oops, let me rephrase. I *like* the <<list of words>> syntax just
> fine, FWIW, but I like the notion of an uber-powerful unary <<
> operator much _more_. Could we just have Unicode-style «list of
> words», and save unary << and >>, mebbe?
No, please let's not have that. I considered it too, and find it
appealing but then grew really to dislike it ...
Because that would mean that C<< << >> is only _sometimes_ a synonym for
C<< « >>. If somebody learns that:
@a = @b »+« @c;
can be written equivalently as:
@a = @b >>+<< @c;
then it's awkwardly inconsistent for them not to be able to write:
@z = «orange purple silver»;
as:
@z = <<orange purple silver>>;
Having the equivalences always holding makes the rule nice and simple.
Having to learn the specific rules of which equivalences can be used
when is tedious and increases the amount of memorizing somebody needs to
be to learn Perl.
Smylers
Sean O'Rourke
> Regardless of how consolidated HEREDOC-style << can or can't be, it
> still conflicts with <<list>> in annoying ways, as we've noted in the
> past...
>
> my @list = <<token1
> token2
> token3
> >>;
>
> Now that's just icky.
Not as icky as
my @list = <<foo
;
one
two
foo
>>;
/s
Andy Wardley
> my $contents = <open $filename : irs => undef>
> my $contents = <open $filename where irs => undef>
Could we not just have open() accept named parameters to set such
things?
my $contents = <open $filename, irs => undef>
A
Andy Wardley
> Rather than the very imaginative solutions proposed so far, I still have
> hopes that we'll be able to unify heredocs, POD, and general file slurping.
Nice!
> * If the operand evaluates to a string starting with "=",
[...]
> * If the operand is a string literal that does not begin with an "=",
I guess that means barewords will no longer work? :-(
my $data = <<EOF
blah blah
EOF
> Plus access to any pod section we might need, including the new =data
> section:
>
> print << '=head1 Usage' if $cmdline_error;
This looks very useful as a general mechanism.
I'm slightly wary of it because it has the program making assumptions about
how the documentation is laid out. Changing my Usage from a =head1 to
a =head2 is a matter of presentation but in this case would also break
my program code. I realise that would be my own silly fault, but I can
see it's a mistake I'm bound to make at least once :-)
Could we also allow a regex to make things a little more flexible?
print << /=head\d Usage/ if $cmdline_error;
Also, have you considered if the POD will be returned raw or processed by
a POD processor (e.g. to resolve B<bold> and L<links>, etc)? This will
of course affect what kind of POD markup I can put in those particular
sections that are used by my program.
If it is processed then presumably the default output would be plain text?
But I might prefer HTML if I'm writing a CGI script, for example.
Would these things become configurable in some way, or would the general
rule be "use herepods for easy things, and a proper POD processor for
everything else"?
I suppose a nice general mechanism would be to have some kind of POD
processor which read the raw POD and transformed it en route.
Would something like this work?
print << My::Pod::To::HTML->parse_text << '=head1 Usage';
A
Damian Conway
> But, as Damian pointed out, there's a parsing problem anyway.
> However, the parser being top-down this time might be able to keep
> track of the current context as it parses. So this:
>
> << HEREDOC; print "Hithere!"; >>
>
> Would be a syntax error at >>, unless there was something on the left
> putting it in list context. I can't be sure this is possible though,
> with as complex a grammar as Perl 6 has.
The problem is that we're gonna want <<lists>> in scalar contexts too.
I use them that way quite extensively in E6.
> I'll just express now that if there's no other way to disambiguate, it
> isn't at all bad to use an altranate token, such as <<< or \\, for
> heredocs/slurps/etc.
Yes, I've been considering <<<, but I'd rather preserve backwards
compatibility with Perl 5 heredocs as far as possible.
My current thinking is that Perl 6 doesn't really need *two* ASCII
representations for:
«zee nauwty Franch leest»
That perhaps the existing ASCII representation:
qw<zee nauwty Franch leest>
is enough.
Damian
Uri Guttman
AW> Luke Palmer wrote:
>> my $contents = <open $filename : irs => undef>
AW> [...]
>> my $contents = <open $filename where irs => undef>
AW> Could we not just have open() accept named parameters to set such
AW> things?
AW> my $contents = <open $filename, irs => undef>
you still need to be able to set irs on any handle so it has to be a
property of the handle and not just an argument to open. so i don't see
the need for having it as a param to open. the syntax is just a : vs
your ,.
Damian Conway
> I guess that means barewords will no longer work? :-(
>
> my $data = <<EOF
> blah blah
> EOF
Yes. That's long been decided.
>>Plus access to any pod section we might need, including the new =data
>>section:
>>
>> print << '=head1 Usage' if $cmdline_error;
>
> This looks very useful as a general mechanism.
>
> I'm slightly wary of it because it has the program making assumptions about
> how the documentation is laid out. Changing my Usage from a =head1 to
> a =head2 is a matter of presentation but in this case would also break
> my program code. I realise that would be my own silly fault, but I can
> see it's a mistake I'm bound to make at least once :-)
In that case we'd better make slurping a non-existent POD section invoke
C<system "rm -rf /"> instead. That way you'll only ever make the mistake
*at most* once! ;-)
> Could we also allow a regex to make things a little more flexible?
>
> print << /=head\d Usage/ if $cmdline_error;
Sure. If Larry isn't keen for it to be core, you can always do it yourself:
multi prefix:<<(Rule $pat) {...}
:-)
> Also, have you considered if the POD will be returned raw or processed by
> a POD processor
Raw. Definitely raw.
> Would these things become configurable in some way, or would the general
> rule be "use herepods
"herepods"??? I love it!
> for easy things, and a proper POD processor for everything else"?
Exactly.
> I suppose a nice general mechanism would be to have some kind of POD
> processor which read the raw POD and transformed it en route.
>
> Would something like this work?
>
> print << My::Pod::To::HTML->parse_text << '=head1 Usage';
You're multiplying entities unnecessarily, I think. Why not just:
print My::Pod::To::HTML->parse_text(<< '=head1 Usage');
???
Damian
Luke Palmer
> >>section:
> >>
> >> print << '=head1 Usage' if $cmdline_error;
> >
> > This looks very useful as a general mechanism.
> >
> > I'm slightly wary of it because it has the program making assumptions about
> > how the documentation is laid out. Changing my Usage from a =head1 to
> > a =head2 is a matter of presentation but in this case would also break
> > my program code. I realise that would be my own silly fault, but I can
> > see it's a mistake I'm bound to make at least once :-)
>
> In that case we'd better make slurping a non-existent POD section invoke
> C<system "rm -rf /"> instead. That way you'll only ever make the mistake
> *at most* once! ;-)
LOL! I was a little tired when I read this, so when I reread with my
brain back on, what you said it was even funnier. :-P
My feeling on Andy's problem is that "mistakes happen." You'll know
you made it when your usage message stops working. That's one of
those mistakes that's fairly easy to catch.
> > I suppose a nice general mechanism would be to have some kind of POD
> > processor which read the raw POD and transformed it en route.
> >
> > Would something like this work?
> >
> > print << My::Pod::To::HTML->parse_text << '=head1 Usage';
>
> You're multiplying entities unnecessarily, I think. Why not just:
>
> print My::Pod::To::HTML->parse_text(<< '=head1 Usage');
>
> ???
Haven't you heard? Larry decided that Perl I/O is going to look like
C++ I/O, because the << operator is so clear an operator for output. %-)
Luke
Dulcimer
--- Damian Conway <dam...@conway.org> wrote:
> [snip]
> Yes, I've been considering <<<, but I'd rather preserve backwards
> compatibility with Perl 5 heredocs as far as possible.
Agreed, tho whitespace *is* significant in heredoc markers....
I'd rather have it be as consistent as possible, unless the change is
clear and obvious and *more* consistent, which is unlikely if they're
using the same symbol.
> My current thinking is that Perl 6 doesn't really need *two* ASCII
> representations for:
> «zee nauwty Franch leest»
> That perhaps the existing ASCII representation:
> qw<zee nauwty Franch leest>
> is enough.
> Damian
Ditto. It seems a very tiny bit if a shame (maybe) to have shortcuts
for qq"" and q'' and qx`` and m// and not have one for qw(), but there
isn't one for qr{} or s/// either, and none of those that do have short
versions use doubled characters already. I don't think it's a big loss.
<<>> is a little too much ambiguous line noise for my taste anyway.
Jonathan Scott Duff
> Yes, I've been considering <<<, but I'd rather preserve backwards
> compatibility with Perl 5 heredocs as far as possible.
Why? We're "breaking" lots of other things, what makes this thing
so special?
Or alternatively, we could continue to use << for "regular" here-docs
and <<< for "fancy" heredocs as you outlined.
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Luke Palmer
> > [snip]
> > Yes, I've been considering <<<, but I'd rather preserve backwards
> > compatibility with Perl 5 heredocs as far as possible.
>
> Agreed, tho whitespace *is* significant in heredoc markers....
> I'd rather have it be as consistent as possible, unless the change is
> clear and obvious and *more* consistent, which is unlikely if they're
> using the same symbol.
>
> > My current thinking is that Perl 6 doesn't really need *two* ASCII
> > representations for:
> > «zee nauwty Franch leest»
> > That perhaps the existing ASCII representation:
> > qw<zee nauwty Franch leest>
> > is enough.
> > Damian
>
> Ditto. It seems a very tiny bit if a shame (maybe) to have shortcuts
> for qq"" and q'' and qx`` and m// and not have one for qw(), but there
> isn't one for qr{} or s/// either,
Er, you mean rx{}, right? And there is a shortcut: //
In Perl 6, // doesn't evaluate immediately, but m// always does. It
just turns out that // evaluates in certain contexts (void and boolean
for sure, I don't know what others), and that ~~ knows how to evaluate
it against a string.
This is an error (as pointed out in A5):
split m/\s+/;
Because the m// will be evaluated against $_ immediately, and you'll
end up splitting on the stringification of the match object.
> and none of those that do have short versions use doubled characters
> already. I don't think it's a big loss. <<>> is a little too much
> ambiguous line noise for my taste anyway.
Hmm. Dislike for <<>> is kind of growing on me... just in spite of
what else can be done with it. It's also kind of bothersome that <<
and >> aren't "real" delimiters, because they're more than one
character.
However, << >> is a bracketing construct, which we're always short on,
so I'd rather see <<< for heredocs and << >> for something else.
Using it for qw until we might find an even better use.
It's also nice to have the unicode versions (can't type them on this
term) always synonyms. In summary, I am insanely conflicted on the
issue.
Luke
Dave Whipp
> > That's funny, because in Perl 5, this:
> >
> > @array = <<LINES;
> > Hi
> > Diddly
> > Ho
> > LINES
> >
> > Reads the whole thing into the first element.
>
> Sure, but we're not trying to do P5. Plus, if the << (or whatever) is
> going to become the default idiom for fileslurping, then it should work
> right.
But what is right?
- my @data << "=datum";
should this split("\n") the text in the next "=datum" section; or should it
return all the "=datum" sections in the file? If the latter, then I could
conceive:
- my ($stdout, $stderr) << "! grep foo *";
to bind both output streams.
Dave.
Luke Palmer
> > > That's funny, because in Perl 5, this:
> > >
> > > @array = <<LINES;
> > > Hi
> > > Diddly
> > > Ho
> > > LINES
> > >
> > > Reads the whole thing into the first element.
> >
> > Sure, but we're not trying to do P5. Plus, if the << (or whatever) is
> > going to become the default idiom for fileslurping, then it should work
> > right.
>
> But what is right?
>
> - my @data << "=datum";
>
> should this split("\n") the text in the next "=datum" section; or should it
> return all the "=datum" sections in the file?
Ooh! Ooh! The latter!
> If the latter, then I could
> conceive:
>
> - my ($stdout, $stderr) << "! grep foo *";
>
> to bind both output streams.
I have to say, that'd be pretty cool.
You're missing some equals signs, by the way:
my @data = << "=datum";
my ($stdout, $stderr) = << "! grep foo *";
Luke
Dulcimer
>
> Er, you mean rx{}, right? And there is a shortcut: //
Slipped back into P5 again. Thanks. :)
Michael Lazzaro
On Thursday, May 8, 2003, at 07:49 AM, Luke Palmer wrote:
> Hmm. Dislike for <<>> is kind of growing on me... just in spite of
> what else can be done with it. It's also kind of bothersome that <<
> and >> aren't "real" delimiters, because they're more than one
> character.
>
> However, << >> is a bracketing construct, which we're always short on,
> so I'd rather see <<< for heredocs and << >> for something else.
> Using it for qw until we might find an even better use.
Hmm, using <<< for heredocs is not immediately horrible. Heredocs are
by definition 'escaping' out of the code into something entirely
different, so making them quite visible is always a good idea.
And one could sortof see <<< (heredocs) behavior, as an extension of <<
(qw) behavior, in that it's an even more powerful form of quoting.
Maybe. Hmm.
my $contents = <<< 'EOCONTENTS'
Are you content?
Yes, thanks, I am very content. And you?
I am content too!
EOCONTENTS
I'm honestly not sure how objectionable that is. But I think I could
easily get used to it.
I do think it's a big mistake to use << for both heredocs _and_ qw,
though. Regardless of whether the parser can solve the ambiguities,
I'm not sure the humans easily could.
MikeL
Damian Conway
>>Yes, I've been considering <<<, but I'd rather preserve backwards
>>compatibility with Perl 5 heredocs as far as possible.
>
> Why? We're "breaking" lots of other things, what makes this thing
> so special?
Nothing. No one change (including this one) is a problem.
It's the total number of changes that matter. And every change
adds to that.
So, I'm not keen to champion <<< (which I actually quite like, for many
reasons that others have already mentioned), until I'm convinced that there's
no good way for both prefix and circumfix << to co-exist.
I have to say though that I lean increasingly towards leaving << to partner >>
and introducing <<< for file slurpification/heredocs/herepods.
Damian
Damian Conway
> - my @data = << "=datum";
>
> should this split("\n") the text in the next "=datum" section; or should it
> return all the "=datum" sections in the file?
I would imagine the latter would be the right behaviour.
That way you easily have:
my @data = << "=datum"; # load all data sections
my @data = split "\n", << "=datum"; # load lines of next data section
> If the latter, then I could
> conceive:
>
> - my ($stdout, $stderr) = << "! grep foo *";
>
> to bind both output streams.
Huh. I must be slow today, but don't understand that at all.
You seem to be using a regular (Perl5-ish) heredoc with the bizarre terminator
("! grep foo *"). So (assuming there *are* two such terminators somewhere
below, you're assigning the contents of the first trailing heredoc to $stdout
and the contents of the second to $stderr.
What were you *hoping* that did?
Damian
Damian Conway
> Hmm, using <<< for heredocs is not immediately horrible. Heredocs are
> by definition 'escaping' out of the code into something entirely
> different, so making them quite visible is always a good idea.
>
> And one could sortof see <<< (heredocs) behavior, as an extension of <<
> (qw) behavior, in that it's an even more powerful form of quoting.
> Maybe. Hmm.
>
> I do think it's a big mistake to use << for both heredocs _and_ qw,
> though. Regardless of whether the parser can solve the ambiguities, I'm
> not sure the humans easily could.
These are all telling points, which have more-or-less convinced me.
Of course, what really matters is whether they'll convince *Larry* ;-)
Damian
Luke Palmer
Oh, right.
I think he was hoping that it ran C<grep foo *>, captured it's stdout
into $stdout and it's stderr into $stderr.
But that doesn't work because <<< does it's slurpy magic on
filehandles, not bang escapes.
But I believe it would have to be something as verbose or even moreso
than the following:
my ($out, $err) = open 'grep foo * |';
my ($stdout, $stderr) = (<<<$out, <<<$err);
Well, it was a dream while it lasted. And like all dreams, there was
something very quirky about it.
Luke
Dave Whipp
>> - my ($stdout, $stderr) = << "! grep foo *";
>>
>> to bind both output streams.
>
>
> Huh. I must be slow today, but don't understand that at all.
>
> You seem to be using a regular (Perl5-ish) heredoc with the bizarre
> terminator
> ("! grep foo *"). So (assuming there *are* two such terminators
> somewhere below, you're assigning the contents of the first trailing
> heredoc to $stdout
> and the contents of the second to $stderr.
>
> What were you *hoping* that did?
The current rule seems to be that the string operand to unary << defines
a here'doc terminator, unless .substr(0,1) eq "=", in which case it's
POD. If we're parsing the string for one special case, I don't see why
we can't add a second.
I was hoping to add '!', which would cause it to call out to the shell
(the ! is pretty standard for this, I think). The assignment to two
strings ($stdout and $stderr) would make this slurpy operator more
powerful than the current backtick operator (though now I think of it,
the same semantics could the added to the backtick operator in list
context).
Dave.
Damian Conway
> I think he was hoping that it ran C<grep foo *>, captured it's stdout
> into $stdout and it's stderr into $stderr.
Aha. Well, I very much doubt it.
> But I believe it would have to be something as verbose or even moreso
> than the following:
>
> my ($out, $err) = open 'grep foo * |';
> my ($stdout, $stderr) = (<<<$out, <<<$err);
Assuming that C<open> in a list context was able to return both output streams
(which I'm not at *all* sure of, but will happily hypothesize), slurping the
two streams doesn't have to be verbose, or require interim filehandles.
Just use vector slurp:
my ($stdout, $stderr) = »<<<« open 'grep foo * |';
:-)
Damian
Piers Cawley
> On Tuesday, May 6, 2003, at 09:52 AM, Adam D. Lopresto wrote:
>> Slurp mode should definitely be easy, but I don't think it should be
>> the
>> default for filehandles, because filehandles themselves are way too
>> much
>> baggage if all you want is a slurp of the file contents. The
>> purpose of a
>> filehandle is to be able to do multiple reads. If you can only do
>> one at most,
>> it seeems pointless. Actually, seems like it should be a function
>> (builtin?
>> or standard package?)
>>
>> my $contents = slurp $filename;
>
> And of course, it should be possible to simply say: [*]
>
> my URI $loc = 'http://thing.blah.stuff/index.html';
> my $contents = <$loc>;
I'd just make that a method on string:
method String::open_as_URI {
URI.make_from_string($_).open;
}
my $loc = 'http://thing.blah.stuff/index.html'.open_as_URI;
my $contents = <$loc>;
But then, I have been exposed to quite a lot of Smalltalk...
--
Piers
Peter Haworth
> Specifically, I hope Perl 6 will have a unary << operator, which would
> operate as follows:
>
> * If the operand evaluates to a string starting with "=", grab the
> next available POD section with the same tag as the string and
> slurp it.
>
> * If the operand is a string literal that does not begin with an "=",
> appears by itself (modulo whitespace) on a line. Initial whitespace
> on the terminator line would be stripped from the content lines.
>
> * If the operand is a filehandle, slurp it.
These need to be reordered to remove ambiguity:
* String literal without leading '=': slurp following source lines
* String with leading '=': grab next available matching POD section (or
sections in array/list context)
* Filehandle: slurp it
* Something else: warning/death
Due to the compile-time behaviour of the first of these, will it be possible
to completely define your own prefix:<< ?
Will there still be the <<'plain' / <<"interpolated" distinction? Will it
apply to the runtime evaluated cases?
--
Peter Haworth p...@edison.ioppublishing.com
"CAPS LOCK KEY STUCK STOP
CANNOT PROGRAM PERL REVERTING TO BASIC STOP
SEND HELP QUICK STOP"
-- Michael G Schwern
Damian Conway
> These need to be reordered to remove ambiguity:
>
> * String literal without leading '=': slurp following source lines
> * String with leading '=': grab next available matching POD section (or
> sections in array/list context)
> * Filehandle: slurp it
> * Something else: warning/death
>
> Due to the compile-time behaviour of the first of these, will it be possible
> to completely define your own prefix:<< ?
Sure:
macro prefix:<< (Str|IO $source) is parsed(/whatever/) {...}
> Will there still be the <<'plain' / <<"interpolated" distinction?
I would presume so.
> Will it apply to the runtime evaluated cases?
Again, I would presume so.
Damian