Re: $RS paragraph mode going away?
Larry Wall wrote :
Paragraph mode is not going away--it's merely going elsewhere. :-)
: If so, what's the rationale? Another case of you can't do it right
: internationally, so better not to do it at all?
No, it's simply that using a global variable to control something
that should be a filehandle attribute is the wrong way to go about it.
The readline function takes an input filehandle and a line separator and
returns a line. So it makes sense to store the line separator in the
filehandle. OK.
: I'm just looking at the huge number of stanza-based files and
: system-utility output sysadmins deal with every day using C$/ = '', and
: thinking yeah, I could just write a grammar, but it's just a simple regex
: match in paragraph mode...
No problem, you'll just say something like:
$fh = open $filename, :para;
for $fh - $para { ... }
Eventually the Perl 5 folks will get around to implementing such
user-oriented layers in Perl 5, but at the moment they're still working
on the encoding-oriented layers, which is fine.
This seems to be a weird way to specify the line separator.
What if you stack many of them ?
$fh = open $filename, :para:slurp;
$fh = open $filename, :slurp:para;
$fh = open $filename, :para:chunk(8192);
# (assumming that :chunk does the job of $/ = \8192)
or, worse, if you mix them with encoding layers ?
$fh = open $filename, :lineending(\n):crlf;
$fh = open $filename, :crlf:lineending(\n); # will I get \r chars ?
Encoding layers know nothing about end-of-line terminators. I'm under
the impression that encoding layers and user layers have different
semantics : respectively buffer filters and user-space modifiers.
(Another example of a user layer could be :taint to taint/untaint the
data read from the filehandle. That's something that modifies a
filehandle's attribute, but that doesn't affect the way the data is
read/written and encoded.)
Oh, and $\ should become a filehandle attribute too.
$fh = open $filename, :lineending(\n);
$fh = open $filename, :lineending(\n):gzip;
$fh = open $filename, :gzip:lineending(\n); # ???
Re: Perl6 grammar (take IV)
I keep expecting Damian or Larry or someone to step in with The True
Grammar and make this obsolete -- does such a thing exist?
Changes in this version:
- A bit more speed (though nowhere near enough). It comes from a
combination of improving rule ordering, inlining some rules, moving
most parse tree munging into post-processing functions, and
(optionally) tweaking Parse::RecDescent to inline a couple
frequently-called functions.
- 'err' and '//' are included, and have the right precedence (cf
Exegesis 4).
- Dereferencing and indexing the current topic (.{blah}) now works.
- Output is slightly less ugly.
- Implicit currying variables ($^a etc) are in. I thought I had read
somewhere they were gone in favor of closure args, but people seem
to be using them, and they're not hard to put in.
- loop(;;) { ... }
- labels.
Notably absent:
- Distinguishing lvalues from rvalues.
- anything from Apocalypse 5.
Feedback and improvements welcome.
/s
use Data::Dumper;
use Getopt::Long;
use strict;
$Data::Dumper::Terse = 1;
$Data::Dumper::Indent = 1;
use Term::ReadLine;
##
# Argument context for functions and control structures
##
%::WANT = ();
##
# Functions (list operators):
# XXX: many of these need their own special want_* rules
my $FUNCTION_ARGS = 'maybe_comma';
my builtin_funcs = qw(crypt index pack rindex sprintf substr
join unpack split
push unshift splice
warn die print printf read select syscall sysread
sysseek syswrite truncate write
vec
chmod chown fcntl ioctl link open opendir
rename symlink sysopen unlink
return fail
not);
::WANT{@builtin_funcs} = ($FUNCTION_ARGS) x builtin_funcs;
sub ::add_function {
my $fname = shift-[1];
$::WANT{$fname} = shift || $FUNCTION_ARGS;
1;
}
##
# Loop control
my loop_control = qw(redo last next continue);
::WANT{@loop_control} = ('maybe_namepart') x loop_control;
##
# Unary operators
# XXX: need to handle default $_
my unary_ops = qw(chop chomp chr hex lc lcfirst length
ord reverse uc ucfirst
abs atan2 cos exp hex int log oct rand sin sqrt srand
pop shift
delete each exists keys values
defined undef
chdir chroot glob mkdir rmdir stat umask
close);
::WANT{@unary_ops} = ('prefix') x unary_ops;
##
# Control operators
my control = qw(for given when default if elsif else grep map);
::WANT{@control} = map { want_for_$_ } control;
##
# Named blocks
my special_blocks = qw(CATCH BEGIN END INIT AUTOLOAD
PRE POST NEXT LAST FIRST
try do);
::WANT{@special_blocks} = ('closure') x special_blocks;
##
# Classes (builtin and otherwise)
%::CLASSES = ();
my builtin_types = qw(int real str HASH ARRAY SCALAR
true false); # XXX: these are really constants
::CLASSES{@builtin_types} = builtin_types;
sub ::add_class { # seen class.
my $c = shift-[1];
$::CLASSES{$c} = $c;
1;
}
# HACK to distinguish between my ($a, $b) ... and foo ($a, $b).
# Don't need all keywords in here, but only the ones that cause
# problems.
%::KEYWORDS = ();
::KEYWORDS{qw(my our temp)} = 1;
# (see Parse::RecDescent::Consumer)
sub ::consumer {
my $t = shift;
my $old_len = length $t;
return sub {
my $len = length($_[0]);
return substr($t, 0, ($old_len - $len));
};
}
my %since;
sub ::check_end {
my ($type, $text) = _;
if ($since{$type}) {
local $_ = $since{$type}-($text);
return m/\A[\s\n]+\z/ || undef;
}
return undef;
}
sub ::mark_end {
my ($type, $text) = _;
$since{$type} = ::consumer($text);
}
##
my $literals = 'END';
sv_literal: /(?:\d+(?:\.\d+)?|\.\d+)(?:[Ee]-?\d+)?/
| '{' commit hv_seq '}'
| '[' commit av_seq(?) ']'
| perl_quotelike
av_seq: semi /[;,]?/
av_literal: '(' av_seq(?) ')'
hv_seq: leftop: pair ',' pair /,?/
hv_literal: '(' hv_seq ')'
END
##
$::NAMEPART = qr/[a-zA-Z_][\w_]*/;
my $variables = 'END';
variable: sigil skip:'' varname
sigil:/[\@\%\$\]/
varname: name
|
Re: Perl6 grammar (take IV)
In a message dated Sat, 6 Jul 2002, Sean O'Rourke writes:
- Implicit currying variables ($^a etc) are in. I thought I had read
somewhere they were gone in favor of closure args, but people seem
to be using them, and they're not hard to put in.
My understanding is that they still exist as placeholder variables, but
no longer implicitly curry. I.e.,
{$^a + $^b}
is a synonym for
- $a, $b {$a + $b}
Trey
Re: Perl 6 Summary
Peter Scott wrote: At 01:54 PM 7/3/02 -0600, Thom Boyer wrote: I'm personally MUCH more interested in Python's generators http://www.python.org/peps/pep-0255.html. A generator is like an iterator in that it can produce a series of values. But unlike iterators, when you ask a generator for the next value, it picks up execution exactly where it left off when it returned the last value -- including all [its] stack. Isn't that a coroutine? I thought they were already slated for P6. *Rummage* Yes: http://www.yetanother.org/damian/diary_April_2001.html Or if you like: http://www.yetanother.org/damian/Perl5+i/coroutines.html -- Peter Scott Pacific Systems Design Technologies Yes, coroutines are more than enough to implement generators (as Dan Sugalski has already agreed). And thanks for the pointers. I've been out of touch with the Perl community the last couple of years. It's been exciting seeing how Perl 6 is shaping up, but I'm having a hard time making up lost time. The postings to perl6-language often take for granted features of Perl 6 which I haven't been able to find in any of the apocalypses or exegeses, so I've been plowing through the archive trying to get more background -- but I hadn't yet made it back to April 2001! Knowing that coroutines are already under discussion WRT Perl, I was able to google the existence of RFC 31 and other references to coroutines in Damian's corpus. (Including a slide show from August 2001 titled Perl 6 Prospectus, where it is in the What we might see section.) I've been unable to determine whether coroutines are really slated for P6, as you suggest. Has there been any indication whether those suggestions have met with Larry's approval? =thom
Re: Perl6 grammar (take IV)
On Sat, 6 Jul 2002, Trey Harris wrote:
: In a message dated Sat, 6 Jul 2002, Sean O'Rourke writes:
: - Implicit currying variables ($^a etc) are in. I thought I had read
:somewhere they were gone in favor of closure args, but people seem
:to be using them, and they're not hard to put in.
:
: My understanding is that they still exist as placeholder variables, but
: no longer implicitly curry. I.e.,
:
: {$^a + $^b}
:
: is a synonym for
:
: - $a, $b {$a + $b}
That is correct. Currying will be done via some explicit method.
Sentiment at yapc favored something resembling:
incr := add.assuming(x = 1);
Larry
Re: Perl 6 Summary
On Sun, 7 Jul 2002, Thom Boyer wrote: : Has there been any indication whether those suggestions have met : with Larry's approval? There will certainly be support for that sort of thing in Parrot, up to and including continuations. Otherwise we cannot hope to host all these other languages. Exactly how Perl will make the interface known to its users is still up for grabs. Hopefully we can be specific enough that the compiler can figure out when it has to use continuations and when it can use some lighter mechanism. From a language design point of view, we want fancy control structures to just kind of sneak into people's consciences just as closures did in Perl 5. The capabilities should be there, but they should just work the way you expect when you get to having any expectations whatsover. It'd be really nice to find a way to explain continuations to people without inflicting the typical torturous explanations on people who aren't interested in brain pretzels. Perhaps we should just explain continuations in terms of time travel. Most people think they understand time travel, even when they don't. A continuation is just a funny label for a point in time, and you have a way of sending messages from the future back to that point in time. Another way of looking at it is that a continuation is a hypothesis about the future, and calling the continuation is a way of saying oops about that hypothesis. Basically, we need to find the right oversimplification to make people think they understand it. Kind of like cancelling the dx's and dy's in calculus--the physics profs always tell you to do that, while warning you not to tell the math profs they're telling you to do that, because it doesn't always work, except in real life. Larry
