Re: Synopsis 9 draft 1
At Fri, 3 Sep 2004 17:08:00 -0700,
[EMAIL PROTECTED] (Larry Wall) wrote:
On Fri, Sep 03, 2004 at 05:45:12PM -0600, John Williams wrote:
: If not, does @ints[-1] mean the element with index -1 or the last element?
The element with index -1. Arrays with explicit ranges don't use the
minus notation to count from the end. We probably need to come up
with some other notation for the beginning and end indexes. But it'd
be nice if that were a little shorter than:
@ints.shape[0].beg
@ints.shape[0].end
Suggestions? Maybe we just need integers with whence properties... :-)
I think @ints[-11] is the obvious choice!
Also, it might be a decent default to have array parameters (or any
bindings) automatically readjust their indices to [0..$#array] unless
explicitly declared otherwise:
sub f1(@a) { @a[0] }
sub f2(@a is shape(:natural)) { @a[0] }
sub f3(@a is shape(-2..(-2 + @a.len))) { @a[0] }
my @array is shape(-1..1) = 1..3;
f1(@a); # == 1
f2(@a); # == 2
f3(@a); # == 3
That way, any code using non-zero-based indices would be clearly
marked as such, which seems prudent -- I know I don't use $[ where
appropriate, and usually assume that $#x + 1 == @x.
/s
Re: Pipeline Performance
At Tue, 31 Aug 2004 13:23:04 -0400,
[EMAIL PROTECTED] (Aaron Sherman) wrote:
I would think you actually want to be able to define grep, map, et al.
in terms of the mechanism for unraveling, and just let the optimizer
collapse the entire pipeline down to a single map.
Even for map and grep this is a bit trickier, since map can produce
zero or more values for each input value, and calls its body in list
context, whereas grep produces zero or one value, and gets called in
scalar context. So you'd need something like a full call and return
prototype for each mapping function, e.g.:
FunctionReturn context Argument context
--
- $a { $a + 2 }($y)($x)
grep(block)($y is optional)($x)
map(block) ([EMAIL PROTECTED]) ($arg)
Then your loop merging macro could deconstruct these into the
appropriate kind of loop (using foreach and pushing single items only
to make intention clear):
@a == map b == @c
==
foreach $a (@a) { foreach $b (map_item(b, $a)) { push @c, $b } }
@a == (b = - $a { $a + 2 }) == @c
==
foreach $a (@a) { push @c, b($a) }
@a == grep \b == @c
==
foreach $a (@a) { foreach $b (grep_item(b, $a)) { push @c, $b } }
where map_item and grep_item are the single-element mapper
functions defining map and grep. I think that both the context and
the number of items consumed/produced could be gathered from
prototypes, so the only restrictions for mapping functions would be
(1) having a prototype available at definition time, and (2) being
side-effect-free.
/s
Re: Pipeline Performance
At Tue, 31 Aug 2004 13:23:04 -0400,
[EMAIL PROTECTED] (Aaron Sherman) wrote:
I would think you actually want to be able to define grep, map, et al.
in terms of the mechanism for unraveling, and just let the optimizer
collapse the entire pipeline down to a single map.
Even for map and grep this is a bit trickier, since map can produce
zero or more values for each input value, and calls its body in list
context, whereas grep produces zero or one value, and gets called in
scalar context. So you'd need something like a full call and return
prototype for each mapping function, e.g.:
FunctionReturn context Argument context
--
- $a { $a + 2 }($y)($x)
grep(block)($y is optional)($x)
map(block) ([EMAIL PROTECTED]) ($arg)
Then your loop merging macro could deconstruct these into the
appropriate kind of loop (using foreach and pushing single items only
to make intention clear):
@a == map b == @c
==
foreach $a (@a) { foreach $b (map_item(b, $a)) { push @c, $b } }
@a == (b = - $a { $a + 2 }) == @c
==
foreach $a (@a) { push @c, b($a) }
@a == grep \b == @c
==
foreach $a (@a) { foreach $b (grep_item(b, $a)) { push @c, $b } }
where map_item and grep_item are the single-element mapper
functions defining map and grep. I think that both the context and
the number of items consumed/produced could be gathered from
prototypes, so the only restrictions for mapping functions would be
(1) having a prototype available at definition time, and (2) being
side-effect-free.
/s
Re: Progressively Overhauling Documentation
At Mon, 23 Aug 2004 19:46:34 +0200,
[EMAIL PROTECTED] (Juerd) wrote:
I also think POD should be overhauled completely. I've been thinking
about proposing something like:
sub foo (
Foo::Bar$bar,
Quux::Xyzzy $xyzzy,
+$verbose,
+$foo
) description {
Calculates the foo-intersection of $bar and $xyzzy, optionally
blah blah blah...
} returns Array | undef {
# real code here
}
which would get rendered as:
foo (Foo::Bar $bar, Quux::Xyzzy $xyzzy, +$verbose, +$foo)
returns Array | undef;
Calculate the foo-intersection of $bar and $xyzzy, optionally
blah blah blah...
I also think something like this is a great idea -- I've been doing a
lot of programming in Octave and Emacs Lisp, and the latter's
generated documentation makes it possible to program what would
otherwise be a completely baroque and unmanageable system. But I
wouldn't go for the syntax you have above. Why not just do it with a
property, then ship with a doc-generator that makes use of it?
sub foo($x is rw, $y) is doc .
Does some stuff, then frobs $x without mercy.
.
{
# ...
}
/s
Re: Instantiation
At Mon, 23 Aug 2004 15:51:00 -0400, [EMAIL PROTECTED] (Aaron Sherman) wrote: On Mon, 2004-08-23 at 15:19, Paul Seamons wrote: So, I was wondering about a synonym, like: uses Some::Module::That::Defines::A::Class $foo; Well if the long name is the problem: use Some::Module::That::Defines::A::Class as Foo; No, like I said: this is not golf. I'm trying to remove an element of redundancy that I think obscures the meaning of a set of statements. Saying, use reallylongnameforamodulethathassomeclass as Foo; our Foo $bar := .new; Still has the same redundancy, it's just been hidden a bit. If use/instantiate is a common practice for certain kinds of library, then I think we should have a mechanism to perform that pair as a single step. How about making use a list operator returning the module's return value (== its last statement?)? Then you could do something like my $x = (use Some::Module::That::Defines::A::Class).new(blah); This leaves a bad taste in my mouth -- I think importing a module and instantiating its main class should remain separate -- but this looks like a painless way to get what you want without a separate function or keyword. /s
Re: simple grammar example
[EMAIL PROTECTED] (Aldo Calpini) writes: I'm preparing a talk about Perl6 for the Italian Perl Workshop, and I would like to have a slide comparing a BNF (yacc/bison) grammar to a Perl6 one, to show how powerful in parsing/lexing Perl6 regexen are. ... am I missing something obvious here? will the above code work in Perl6? do you have perhaps a better example, or just an idea about what to show? A few points: * Remember that with Yacc, you also need a lexer, while P6 combines lexing and parsing. Though it would complicate the example, it would make P6 look better to include a lex definition for NUM and the regex rule in P6. * I'd do infix, because it's not too much more complex, because it's more natural and familiar, and because it will show the differences in how you write recursive descent versus LALR grammars. * To really show where P6 rocks, you need to show dynamic features. A simple example might be using a language with keywords kept in variables, allowing you change between e.g. for, while, if, pour, tandis-que, si, etc. (hey, you could use LWP::Simple to babelfish your language on the fly!). A more complicated example might parse a construct that would add rules to the grammar, something that would be really hard with Yacc. /s
Re: simple grammar example
[EMAIL PROTECTED] (Rafael Garcia-Suarez) writes: Sean O'Rourke wrote: * To really show where P6 rocks, you need to show dynamic features. A simple example might be using a language with keywords kept in variables, allowing you change between e.g. for, while, if, pour, tandis-que, si, etc. Small correction : pour, tant_que, si :) Ouch! High school French fails me once again... /s
Re: backticks (or slash, maybe)
[EMAIL PROTECTED] (Juerd) writes:
Angel Faus skribis 2004-04-19 22:43 (+0200):
If we really need a ultra-huffman encoding for hash subscriptors, I
have always dreamt of being able to do:
%hash/key
$hashref/foo/bar/baz/quux
...
I'd hate to give up dividing slash. It's one of the few operators that I
sometimes type without whitespace. Simple because 1/10 is good enough
and 1 / 10 is very wide.
You can have both, though.
for /home/angel - $file {
That would mean giving up // for regexes (i.e. making the m
mandatory).
Since modifiers have to be up front, and since hash slices won't have
a trailing '/', I don't think there's any ambiguity -- anything ending
in a '/' is a regex, anything otherwise is a hash slice.
/s
package DH;
require Tie::Hash;
@ISA = 'Tie::StdHash';
sub TIEHASH {
return bless {}, 'DH';
}
sub SCALAR {
return shift;
}
sub STORE {
my ($h, $k, $v) = @_;
$h-{$k} = $v;
}
use overload '/' = sub {
my ($x, $y, $rev) = @_;
if (!$rev) {
if (ref $y eq 'ARRAY') {
return [EMAIL PROTECTED]@$y}];
} else {
return $x-{$y};
}
} else {
return $y / keys %$x;
}
};
package main;
my %h;
tie %h, 'DH';
%h = qw(a 1 b 2 c 3);
my $xs = %h / [qw(a c)];
print %h / 'a', \n;
print @$xs\n;
Re: backticks (or slash, maybe)
[EMAIL PROTECTED] (Juerd) writes:
Sean O'Rourke skribis 2004-04-19 15:11 (-0700):
I'd hate to give up dividing slash. It's one of the few operators that I
sometimes type without whitespace. Simple because 1/10 is good enough
and 1 / 10 is very wide.
You can have both, though.
But not in a way that makes $foo/$bar divide $foo by $bar, if $foo is a
hashref.
I'm saying division is now defined such that when the numerator is
a hash(-ref), the result is the set of values associated with the
denominator. I've never tried to divide a hash or hashref by
something without it being a bug.
That would mean giving up // for regexes (i.e. making the m
mandatory).
Since modifiers have to be up front, and since hash slices won't have
a trailing '/', I don't think there's any ambiguity -- anything ending
in a '/' is a regex, anything otherwise is a hash slice.
I don't understand. Could you give some examples? Is this in the context
of bare /path/to/foo, even?
Sure:
/foo/ # trailing slash -- so it's a regexp (m/foo/)
/foo\/bar/ # trailing slash -- syntax error (m/foo/ bar/)
/foo/a # hash-path -- no trailing slash ($_.{'foo'}{'a'})
/foo\/bar # hash-path -- no trailing slash ($_.{'foo/bar'})
/foo\/ # hash-path -- no trailing slash ($_.{'foo/'})
/s
Re: backticks
[EMAIL PROTECTED] (Juerd) writes:
I think it has to go because `pwd`, `hostname`, `wget -O - $url`
should not be easier than the purer Perl equivalents and because
``'s interpolation does more harm than good.
I have to disagree with you here. The Perl way is not always the Perl
way -- the beauty of Perl is that it makes it as easy as possible to
take advantage of existing tools. Sometimes this is best done with a
foreign interface like XS, but sometimes it's adequate and easier to
simply shell out and collect the output. I don't see purity as a
good motive here; in fact, rigid purity makes languages like Java and
Smalltalk somewhere between frustrating and useless.
As for it doing more harm than good, do you mean that `` is a security
threat? I find that there are still plenty of contexts in which `` is
nice and security is irrelevant.
Of course, I'd be fine with the slightly longer qx{}...
/s
Synopsis 3: quick junction question
S3 says: 1|2 + 34; # (4|5) (5|6) but shouldn't that equal (1 + (34)) | (2 + (34)) = (45) | (56) = (4|6) 5 # ??? For one thing, OR's of AND's (DNF) is just nicer than AND's of OR's (CNF). For another, I read that as 1 or 2 plus 3 and 4; it would be surprising if that were equal to (4 or 5) and (5 or 6), since that equals 5 and 5. I haven't run through many examples, but I think it should be a general rule than when combining conjuctions with disjuctions through any operation, the conjuction should distribute over the disjuction. I know these aren't strictly logical ops, but if I say @a = (0,0,0,0,1,0); print yes if @a[1|2 + 34]; I would be chagrined if it printed yes. Then again, I would be chagrined to have to read that code, anyways. /s
Re: Control flow variables
[EMAIL PROTECTED] (Austin Hastings) writes:
What does Cscatter do?
That's the operator that's used to assign values to C$^x and
friends in closures. In all its glory, you give it a set of values,
and it assigns them to a block's undefined variables, quieting those
annoying warnings:
@x = 1..10;
scatter @x {
$the = 1;
$teh + $the * $The
}
# == 1 + 1 * 2 = 3
/s
Re: Protocols
On 19 Jul 2003, Luke Palmer wrote: [1] It would be totally cool to use a Haskell- or ML-style type inference system, but those things just don't work in procedural languages. Could you clarify what you mean by don't work here? ML has both assignment and type inference, so it seems like it's at least possible to do this; O'Caml generates some pretty fast code, too, so it seems like it can be practical as well. Of course, perl6's being _dynamic_ may sink this, but its being _procedural_ doesn't seem like it would pose a problem. /s
Re: This week's summary
On Tue, 24 Jun 2003, Leopold Toetsch wrote: Piers Cawley [EMAIL PROTECTED] wrote: He's worried that the P6C tests break, ... albeit this is still an issue. Nobody answered, if we need another Sub class implementing the old invoke/ret scheme ... I'd say no. P6C is now compiling to an obsolete architecture. While we should all step back and be impressed at how well Intel has maintained backward compatibility in the x86, there's no particular reason we should do so ourselves. Rather, someone (me) needs to port P6C to the new machine. Whee! My first anniversary! Congrats and thanks for your great summaries. Seconded. /s
Re: This week's summary
On Mon, 9 Jun 2003, Adam Turoff wrote: - roll-your-own inheritance mechanisms (see NEXT.pm) On a related note, you might also want to take a look at CLOS (the Common Lisp Object System) where it talks about method selection. They've got a pretty clear and general model that describes every imaginable (and unimaginable) thing you'd want to do with dispatch. It's broken into 3 steps, any one of which you can customize: - find all applicable methods - sort them in order of specificity - apply some kind of combining operation to this list (e.g. select 1st) Granted, this is hardly efficient, and from what I've seen you need to be careful in how you use MMD to get decent performance in Lisp. But it's still helpful in laying out the design space. /s
Re: Rules and hypotheticals: continuations versus callbacks
On Wed, 19 Mar 2003, Jonathan Scott Duff wrote:
Are you implying that
$fred = rx/fred/;
$string ~~ m:w/ $fred { $fred = rx/barney/; } rubble /
won't match barney rubble?
Or, worse, that
$fred = rx/fred/;
$string ~~ m:w/ { $fred = rx/barney/; } $fred rubble /
won't, either?
/s
Re: Rules and hypotheticals: continuations versus callbacks
On Tue, 18 Mar 2003, Matthijs van Duin wrote: and maybe also: What is the current plan? although I got the impression earlier that there isn't any yet for invoking subrules :-) See line 1014, languages/perl6/P6C/rule.pm. The hack I used was to call rules like ordinary subs, and have them push marks onto the regex stack before they return. I'm not sure if this can be made to work with hypotheticals, and I'm sure it won't interact kindly with continuation-taking, but there's _something_. As for the interaction with continuations, I was about to post some of my concerns when I received your long and well-thought-out mail. I need to think about the discussion so far a bit more, but briefly: (1) There's more than one way to go when combining dynamically-scoped variables with continuations: for example, do you use dynamic bindings from where the continuation was taken, or from where it's invoked? (see e.g. Scheme's dynamic-wind). (2) (internals) The functional-language people have found that full continuations are slow, and put a lot of effort into avoiding them where possible. Backtracking languages like Icon and Prolog are implemented by special mechanisms rather than general continuations, probably for this reason. So if we're forced to do a regex engine using full continuations, it will probably be dog-slow (3) On the other hand, we probably want people to intermix regex backtracking, continuation-taking, and hypothetical/dynamic variables, and have it do the right thing, where right means something like mind-bendingly difficult to reason about, but consistent. How do we want these features to play with each other? (4) (internals) Given that Parrot has so many different control mechanisms (call/ret, exceptions, closures, continuations, ...), how do we maintain consistency? And how much of that is parrot's responsibility (versus the perl6 compiler's)? /s
Re: Shortcut: ?=
On Mon, 3 Feb 2003, Dave Mitchell wrote: $var ??= 'succeeded' :: 'failed'; Aha! $var 'succeeded' || 'failed'; Thank you, precedence. /s
Re: Shortcut: ?=
Argh. Please disregard that last message as the ramblings of a pre-caffeinated mind. /s On Mon, 3 Feb 2003, Sean O'Rourke wrote: On Mon, 3 Feb 2003, Dave Mitchell wrote: $var ??= 'succeeded' :: 'failed'; Aha! $var 'succeeded' || 'failed'; Thank you, precedence. /s
Re: Arc: An Unfinished Dialect of Lisp
On Wed, 22 Jan 2003, Austin Hastings wrote: I'm done with 'P'. That's it. Putative planners of programming paradigms must proffer some prefix preferable to the pathetic palimpsest that is 'P'! As with operators, so with programming languages -- Unicode comes not a moment too soon. /s
Re: L2R/R2L syntax
On Sat, 18 Jan 2003, Michael Lazzaro wrote:
So 'if' and friends are just (native) subroutines with prototypes like:
sub if (bool $c, Code $if_block) {...};
IIRC it's not that pretty, unfortunately, if you want to support this:
if $test1 {
# blah
} elsunless $test2 {
# ...
}
since that gets parsed as
if($test1, { ... }) # aiee: too many arguments to if
One possible solution would be to say that there's an implicit whatever
we need after a closed curly. In that case there are two ways to go:
(1) we can define things like if to be statements rather than
expressions (a la C), and closed-curlies as the last arguments of
statement-like functions can always have an implicit ;; or (2) we can
say that } results in an implicit ; whenever we're at the end of an
argument list and see a term rather than an operator. I think we turned
up some nasty ambiguities with (2) last time we discussed this. It would
certainly wreak havoc with unary minus.
The other way is the newline after curly rule, which has a foul taste
for those of us who cuddle our ifs.
/s
Re: purge: opposite of grep
On 5 Dec 2002, Rafael Garcia-Suarez wrote: John Williams wrote in perl.perl6.language : If you want good'ol Unix flavor, call it vrep. Compare the ed(1) / ex(1) / vi(1) commands (where 're' stands for regular expression, of course) : :g/re/p :v/re/p Or, to follow the spirit rather than the letter of Unix, how 'bout ere for Elide REgex or tang for Tog's A Negated Grep? /s
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Sean O'Rourke wrote: On 5 Dec 2002, Rafael Garcia-Suarez wrote: John Williams wrote in perl.perl6.language : If you want good'ol Unix flavor, call it vrep. Compare the ed(1) / ex(1) / vi(1) commands (where 're' stands for regular expression, of course) : :g/re/p :v/re/p Or, to follow the spirit rather than the letter of Unix, how 'bout ere for Elide REgex or tang for Tog's A Negated Grep? Gah. s/Tog/Tang/. /s
Re: eq Vs == Vs ~~ ( was Re: Primitive Boolean type?)
See http://archive.develooper.com/perl6-internals;perl.org/msg11308.html for a closely-related discussion. /s On Fri, 1 Nov 2002, David Whipp wrote: In Perl6, everything is an object. So almost everything is neither a number nor a string. It probably doesn't make sense to cast things to strings/ints, just to compare them. We probably want a standard method: .equals(), that does a class-specific comparison. The question is, will we be modifying the definnitions of == and eq, so that one will call the .equals method explicity. And what does the other do? Do we want to define them in terms of identity vs equality? Then, is identity a class-specific thing (i.e. a .identical() method); or is it an address-in-memory kind of thing? Did I miss a previous discussion of this? Dave.
Re: perl6 operator precedence table
Thanks for taking the time to write this out.
On Thu, 26 Sep 2002, John Williams wrote:
perl6 operator precedence
leftterms and list operators (leftward) [] {} () quotes
left. and unary .
nonassoc++ --
leftis but
This would lead to some scary things, I think:
$a = 3 + 4 but false
= (= $a (+ 3 (but 4 false)))
Of course, so does having low precedence:
$a = 3 but false + 4
= (= $a (but 3 (+ false 4)))
but I think the latter is unnatural enough that it deserves parens, so I'd
put 'but' above comma (and probably '='), but below just about everything
else.
Larry mentions that other precedence unifications are possible. I can see
the following as possibilites. Are there others?
with
| with ||
It seems like a good idea to me to encourage people to think of bitwise
ops as mathematical, not logical, so I'd rather see them with different
precedences. Plus, anything that significantly goes against people's
hard-wired C expectations will just lead to confusion and pain. Finally,
having '|' below '' will probably lead to strange things, e.g.
1|2 3|4
= 1 | (2 3) | 4
/s
Re: hotplug regexes, other misc regex questions
On Fri, 20 Sep 2002, Larry Wall wrote: But if a fast implementation needs to keep pointers into a string rather than offsets from the beginning, we're asking for core dumps if the string is modified out from under the pointers, or we have to adjust all known pointers any time the string may be modified. With the current Parrot GC, keeping pointers into the string while doing unrelated allocation will get you a core dump, since the string body might be copied. So unless the regex engine copies strings off into its own private non-collected storage, we're stuck with offsets anyways. /s
RE: Passing arguments
On Fri, 20 Sep 2002, Larry Wall wrote:
The current thinking as of Zurich is that the given passes in
separate from the ordinary parameters:
sub ($a,$b,$c) is given($x) {...}
That binds the dynamically surrounding $_ to $x as an out-of-band
parameter. Can also bind to $_ to make it the current topic.
Does this mean that we allow/encourage uses of $_ other than as a default
for an optional argument? I think it would be less confusing and
error-prone to associate the underscore-aliasing with the parameter $_
will be replacing, i.e. this
sub foo($a, $b = given) { ... }
vs this
sub foo($a; $b) is given($b) { ... }
or this
sub foo($a; $b) is given($c) {
$b //= $c;
...
}
Furthermore, if the caller can pass undef for the second parameter, I
don't see a way to distinguish in the third variant between a legitimately
passed undef, for which we don't want $_, and a missing optional argument,
for which we do.
/s
Re: Second try: Builtins
On Sat, 7 Sep 2002, Chuck Kulchar wrote: Also, how do these perl6 builtins in perl6 work with the current P6C/Builtins.pm? (also, why are some that are already defined in pure pasm/part of the parrot core redefined as perl6 code?) For the moment, they don't. Eventually, I expect there will be some sort of a header file with the builtin declarations (P6C parses and interprets function declarations for this very reason), and a .pbc file containing their code. As for why they're written in perl 6 code, I expect it's easier to define their semantics in Perl than in assembly. /s
Re: Perl 6 parser, built in rules, etc.
On Wed, 4 Sep 2002, Erik Steven Harrison wrote: How are we planning on dealing with this, or do the implementers consider it a non issue? Well, to me this is a non-Yet issue, but a very real issue. I'm hoping that when Perl 6 goes 1.0, the grammar will have seen a lot of testing, and will be in some sort of final form. To me a language's grammar, once defined, shouldn't do a lot of changing, internally or otherwise. When was the last time C's grammar changed? Or even gcc's implementation of it? Of course, before 1.0 the grammar will likely undergo some major tweaking, fixing, and refactoring. It seems reasonable to expect people who do grammar mods before then to keep up with changes. /s
RE: atomicness and \n
On Tue, 3 Sep 2002, Luke Palmer wrote: On Tue, 3 Sep 2002, Brent Dax wrote: Damian Conway: # Neither. You need: # # $roundor7 = rx /roundascii+[17]/ # # That is: the union of the two character classes. How can you be sure that roundascii is implemented as a character class, as opposed to (say) an alternation? What's the difference? :) Neglecting internals, semantically what Iis the difference? None, I think. Of course, if we ignore internals, there's no difference bewteen that and rx /roundascii | 1 | 7/. /s
Re: Does ::: constrain the pattern engine implementation?
On Wed, 28 Aug 2002, Deven T. Corzine wrote: Would it be better for the matching of (Jun|June) to be undefined and implementation-dependent? Or is it best to require leftmost semantics? For an alternation spelled out explicitly in the pattern, it seems like undefined matching would be confusing. I regularly order the branches of regexes assuming they are tried left-to-right. On the other hand, and on a related note of constrained implementation, do we require leftmost matching for interpolated arrays of literals (e.g. /x/)? If, as with hyper-operators, we said the order of evaluation is undefined, we could use a fast algorithm (Aho-Corasick?) that doesn't preserve order. /s
Re: Hypothetical synonyms
On Thu, 29 Aug 2002, Markus Laire wrote: (only 32bit numbers, modulo not fully working, no capturing regexps, ) Where does modulo break? /s
Re: rule, rx and sub
On Wed, 28 Aug 2002, Damian Conway wrote:
Any subroutine/function like Cif that has a signature (parameter list)
that ends in a Csub argument can be parsed without the trailing
semicolon. So Cif's signature is:
sub if (bool $condition, block);
So the trailing semicolon isn't required.
Okay, so curlies always make surrounding commas optional (or verboten?),
and make trailing semis optional when no more arguments are expected.
This seems natural, and naturally extended to allow this
$x = { 1 = 2, ... }
$y = $x;
or even this
$x = { ... } $y = $x;
since the parser sees ($x, =, {) and, knowing that it only wants a
single value, takes the closing } to be the end of the statement. This
would let you do ugly things like this:
xs = (1 { $^x + 2 } 3, 4); # second element is a closure
but most of the time, people would probably write readable code by
accident.
Also, to follow up in two directions in two directions...
First, if if can be defined as above, is this a syntactic or a semantic
error (or not an error at all):
if $test { ... }
some_other_thing();
elsif $test2 { ... }# matching if above.
I personally think it would be nifty, and would fit in with the ability to
mix code with whens in a given. There'd be a bit of extra overhead
involved in tracking whether or not we'd seen a true condition yet in the
current if-sequence, but that's peanuts compared to other overhead.
Second, is there a prototype-way to specify the arguments to for
(specifically, the first un-parentesized multidimensional array argument)?
In other words, is that kind of signature expected to be used often enough
to justify not forcing people to explicitly extend the grammar?
/s
Re: rule, rx and sub
On Wed, 28 Aug 2002, Luke Palmer wrote:
Second, is there a prototype-way to specify the arguments to for
(specifically, the first un-parentesized multidimensional array argument)?
In other words, is that kind of signature expected to be used often enough
to justify not forcing people to explicitly extend the grammar?
If you're talking about parallel iteration, I know what you mean.
Yeah, that's what I was talking about, though IIRC parallel iteration
refers to how the data is used. I may be on crack here, but I think that
stuff before the arrow is just a multidimensional array, like
my a = (1, 2; 3, 4)
but, since we're expecting it, the parens are optional.
I think there's a time for a special case, and that's one of them.
I probably agree here (if mucking with the parser is a straightforward
thing to do).
If you're talking about the regular syntax:
for a, b - $x { ... }
Would that be:
sub rof (array *@ars, body) {...}
or
sub rof (*@ars is array, body) {...}
Being able to specify fixed arguments after a splat looks illegal, or at
least immoral. It opens the door to backtracking in argument parsing,
e.g.:
sub foo (*@args, func, *@more_args, $arg, func) { ... }
Saying specifically a list of arrays. Also, would that list gobble up
everything, or would it actually allow that coderef on the end?
I would expect it to be a syntax error, since the slurp parameter has to
be the last.
/s
Re: rule, rx and sub
On Tue, 27 Aug 2002, Luke Palmer wrote:
On 27 Aug 2002, Piers Cawley wrote:
Damian Conway [EMAIL PROTECTED] writes:
Debbie Pickett asked:
(Offtopic: can I say:
$c = - $xyz { mumble }
Yes. Though you need a semicolon at the end unless its the last
statement in a block.
Um... when did that rule come in? I thought a statement ending closing
brace merely had to match C rx/ \} [ ; | \s* \n] / .
Nope. It's C rx/^^ \s* \} \s* $$/ (or the usual C }; )
I hope this is wrong, because if not, it breaks this:
if 1 { do something }
foo $x;
in weird ways. Namely, it gets parsed as:
if(1, sub { do something }, foo($x));
which comes out as wrong number of arguments to `if', which is just
strange.
/s
Re: rule, rx and sub
On Mon, 26 Aug 2002, Glenn Linderman wrote: because the rules and patterns are no longer regular, but if rx isn't a short form of regex, what is it a short form of? It's a short form of r$x for some value of $x ;). /s
Re: Perl 6 regexes... (fwd)
What Dan says. If you're interested, there are at least three options: - a fairly well-developed compiler for perl 5 regexes (languages/regex). - a less well-developed compiler built into the prototype Perl 6 compiler (languages/perl6) - a set of regex ops in rx.ops, suitable for starting your own implementation from scratch. Since I'm working on #2, I'd of course most appreciate help on that ;). It unfortunately relies on a couple of other miscellaneous enhancements that haven't made it into CVS. If you're interested in taking a look before it gets into CVS, email me and I'll send you the duct tape I'm using to hold it together now. /s -- Forwarded message -- Date: Mon, 12 Aug 2002 03:00:27 -0400 From: Dan Sugalski [EMAIL PROTECTED] To: Sean O'Rourke [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Perl 6 regexes... At 10:01 PM -0700 8/11/02, Sean O'Rourke wrote: Working on it. I've got greedy quantifiers (including $n,$m), interpolated arrays and scalars, enumerated character classes, code assertions, embedded blocks. It's all static, so runtime-compiled regexes aren't going in. Hypotheticals will be hard, but should be doable. Same with the various cut operators (::). Yow. Cool. Pop a note to perl6-language if you want, to see about grabbing some folks to help out. On Mon, 12 Aug 2002, Dan Sugalski wrote: Well, we've got a pretty good description of perl 6's regexes courtesy of A5. Anyone care to take a shot at either modifying the regex compiler to deal with them, or writing a perl 6 regex compiler? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 'while {' in Perl 6
On Fri, 9 Aug 2002, Larry Wall wrote:
(Had an interesting typo there. I put = insteaqd of -. I wonder
how much trouble that sort of thing is gonna cause. Maybe pairs
can be disallowed or warned about where a pointy sub might be
expected.)
To add to the list of helpful warnings, I ran across the following
thinko:
for ($x = 0; $x 23; $x++) { ... }
which (I believe) is a legitimate for-loop across a multidimensional array
literal:
for (...) - $_ { ... }
but almost always means
loop (...) { ... }
We need to make a list of these.
/s
Re: of Mops, jit and perl6
On Mon, 29 Jul 2002, Dan Sugalski wrote: Just out of curiosity, I presume the (rather abysmal) perl 6 numbers include time to generate the assembly and assemble it--have you tried running the generated code by itself as a test? (At the moment, the assembler's rather slow) It's mostly the parser that's slow, not the assembler (about a second's worth of startup time to load the grammar and do a bunch of initialization). But even without that, I'd suspect that the perl6 numbers would suck, since the compiler does some pretty heavy pessimization. For example, I included the main loop at the end of the email, showing a number of painful things, including: - spilling inside the loop - re-initializing the constant zero on every iteration - putting things in PMC's only to take them out again Some of these would be easy to fix, but I think things need to advance more in the features and stability departments before going for speed. /s L_14: L_17: new P6, .PerlUndef set I0, 0 set P9, P31[1] #FETCH set N0, P9 new P0, .PerlUndef set P0, 0 set N1, P0 gt N0, N1, L_19 branch L_comparison18 L_19: set I0, 1 L_comparison18: set P6, I0 if P6, L_while_body20 branch L_while_end13 L_while_body20: L_15: new P6, .PerlUndef set P9, P31[1] #FETCH set P2, P31[3] #FETCH sub P6, P9, P2 clone P9, P6 set P31[1], P9 #STORE branch L_14 L_16: L_while_end13:
RE: Perl6 grammar (take V)
On Sun, 14 Jul 2002, Brent Dax wrote:
Deborah Ariel Pickett:
# My perl5 sensibilities tell me that that's likely to cause a
# problem when I want to do something like this:
#
# $hashref = { function_returning_hash() };
#
# because I won't get the function's return values put into a
# hash, because the stuff inside the { ... } isn't a list of
# pairs. Instead I'll get a (reference to) a closure, not at
# all the same thing.
You've got a point. There's an easy way to say I want a sub:
my $sub = - { ... }
But I can't think of a similarly punctuation-intensive way to say I want
a hash. (someone please step in and correct me).
# that this is being phased out for perl6 (the grammar backs that up).
I wouldn't take the grammar too seriously -- it's more or less one
person's interpretation of the Apocalypses, Exegeses, and recent mailing
list traffic.
my HASH $hashref;
my CODE $subref;
So if I have the above two declarations, and do this later:
$hashref = { ... };
$subref = { ... };
It does the right thing? This could work up to a point, but Perl can do
crazy things like this:
$foo ?? $hashref :: $subref = { ... };
and propagate context differently to different branches of the ternary
(try doing $x ? y : $z = (2,3,4) sometime -- very cool!). And while we
could interpret the block differently on each branch, that seems a bit too
scary.
(Alternatively, always parse it as a closure and afterwards run through
the parse tree, checking all the closures and converting those that only
contain pairs.)
Or use context to try and figure it out. Unfortunately, from the outside
I think either would just look like a reference. Maybe if the compiler
could figure out that your function would return pairs, it could fix
things up so that turns into a hash-ref. But then you can get into
trouble with a function that returns pairs only in non-hash-ref
contexts...
/s
Re: Perl6 grammar (take V)
It's time for my weekly post to this old thread. The grammar has
grown enough to deserve more than one file, and is starting to change
in new directions. For example, it's now Turing-complete, if you have
a Parrot engine and a bit of spare time. Call it a primitive demo
version of some of Perl 6's features. If nothing else, it will let
you start training your fingers to 'concatenate' _$like _$this.
What's currently supported:
- most binary operators
- arithmetic hyper-operators
- chained comparisons
- the ternary operator (both r- and l-value)
- if/elsif/else (even unless and the feared elsunless;)
- void subroutines with declared parameter lists (only)
- local variables (only -- i.e. use UberStrict).
- arrays and scalars (only -- no hashes, closures, references)
The fact that I've been able to whip this up in a couple thousand
lines of code is a remarkable testament to Parrot's maturity, and to
the wealth of tools available in Perl 5. In particular, without The
Damian's Parse::RecDescent, Melvin Smith's IMCC, and Sarathy's
Data::Dumper, it never would have been possible.
Grammar fixes:
- Fixed a bug with parameter initializers: sub f($x = 23, $y) now
parses as f(($x = 23), ($y)), not f($x = (23, $y))
- Fixed a number of bugs sent in by Jonh Kingsley:
- sub f($a; $b, *@c) (i.e. a sub with both optional and slurping
parameters) now parses.
- low-precedence 'and', 'or', 'xor' are now allowed within
suitably-parenthesized expressions, such as if (1 and 2).
Interestingly, you can now put a multi-dimensional array as the
test of an if. This is probably a feature that will go away at
some point in the future.
- if (a b) is parsed correctly, not as if (a (b))
- f(2,3),4 reverts to (f(2,3)),4 rather than f((2,3),4)
through a bit of chicanery that allows if and other control
structures to take parens around their first arguments.
- %a{somefunction($withargs)} is legal. It used to see
'somefunction' and treat it as a bare hash key, then freak out
about the open paren.
- last if $foo and related cases where a guard was parsed as a
label name.
- empty programs and blocks
- stmt until expr
Changes:
- Kingsley's changes:
- handles comments
- foreach decl(?) '(' expr ')' block
- statement guards (e.g. do_something() unless $foo) cannot be used
with functions taking a closure as their last argument (e.g. for,
elsunless). This avoids a nasty ambiguity with things like this:
if 1 { A }
if foo { B }
== guarded_stmt(if(1, {A}), if, foo({B}))
or == stmts(if(1, {A}), if(foo(), {B}))
- significant reorganization and tidying of files. The grammar now
lives in its own module, and doesn't stomp on main's namespace with
wild abandon. It's not a simple one-file install anymore, but it's
getting big enough to maybe justify jumping through more hoops.
- Human-readable output is gone, as it was more trouble than it was
worth to maintain. The default now is to output the parse tree
through Data::Dumper (there may be other tools to inspect Perl data
structures in a more legible format).
Next to do:
- Function return values.
- More informative error messages. They're currently... cryptic.
- Having no built-in functions is kind of frustrating. Adding a few
more things would be nice.
- sub declarations. A standard function for turning a prototype into
an argument context rule is needed eventually, and would eliminate
the current nasty builtin hack in the compiler and parser.
- rip out
- Globals.
- Handling of closures for if-blocks is completely bogus now --
they're always inlined, as there are no nested scopes. Once these
are in, the current closure-handling will go away.
(If you've read this far, I'm impressed. It took me several tries to get
here myself)
/s
grammar.tgz
Description: Binary data
Re: Reflection...
On 8 Jul 2002 [EMAIL PROTECTED] wrote:
caller with no args is the same as Ccaller(1) (for certain values of
'the same as'), caller(0) already returns the current execution
context.
You're right. I stand corrected.
If you can set a block's continuation at runtime, I think you should be
able to get it as well. Then you can splice a function into a dynamically
defined control sequence like this:
my $readfile is private = - $x { process_data $x, ... };
sub add_post_handler (CODE $block2) { # is public
$block2.continuation($readfile.continuation);
$readfile.continuation($block2.as_continuation);
}
sub read_file($data) { $readfile.($data) }
# ...
add_post_handler - $x { uncompress $x };
my $sum = blahblah;
add_post_handler - $x { die unless $sum eq md5sum $x; $x };
read_file $foo;
One good thing about this is that none of the blocks has to be aware of
continuations itself, and the continuation-handling ugliness can be
separated from the useful-work-doing ugliness.
I think if you *always* want a function to return via a post handler
then you should wrap that function:
old_sub := {
try {
if (wantarray) { () = $pre_handler-(@_) }
else { scalar $pre_handler-(@_) }
CATCH ShortCircuit { return .result }
}
my @res = wantarray ? old_sub(*@_) : scalar old_sub(*@_);
$post_handler.continuation(caller.as_continuation).(@_,@res);
}
What I want is always until I next reconfigure my program, something
that may happen at runtime. The wrapping approach will do this just fine
until you want to stick something in the middle. You can always go with
an explicit array that gets iterated through by some sort of
meta-function, then splice things into the middle when necessary, but
continuations are another way to do this, and some people might prefer
them. And they'd have the added benefit of handling want() contexts
automatically. The old function, and not our caller, should (arguably)
provide the context for the new function's return, since the new function
isn't returning to its calling context. Handling this doesn't seem
possible unless we have ways to get and set context along these lines:
my @fs;
sub meta_f {
my @wants = ((map { $fs[$_].want } 1..$fs.last), want());
for @fs; @wants - $f; $w {
state_my_desires($w);
@_ = $f(@_);
}
}
And manual want-handling will be more error prone in Perl 6, since calling
contexts are richer.
I was thinking it would be useful to modify $block's continuation,
so every caller of $block would get the new continuation. You could
always make a copy of $block (not sure of the syntax) if you wanted
to set up your own personalized version.
That sets you up for very scary action at a distance. Essentially
you're proposing Ccome_from BLOCK
But we can already do this in Perl 5:
my $func_next = sub { }
sub func {
# do stuff
goto $next;
}
sub foo {
$func_next = shift;
}
It is possible to create scary action at a distance, but not unavoidable.
We can describe this in terms of come_from, but I prefer to think of it as
BLOCK.go_to (It's to-MAY-to, I'm telling you!).
/s
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: Reflection...
On 5 Jul 2002 [EMAIL PROTECTED] wrote:
dan [EMAIL PROTECTED] writes:
At 8:29 AM -0700 7/4/02, Sean O'Rourke wrote:
Sick. Anyways, I think it seems like a more natural way to do things than
traditional call/cc. $block.continuation reads as where do I go after
$block?; $block.continuation($foo) as after executing $block, proceed
on to $foo; (call/cc func) as call func with a single argument being
the 'rest of the current computation'. This last definition makes Scheme
and Lisp people happy, but (at least for me) the first two are much easier
to grasp, as they refer to what's going on more concretely.
If you want really sick, consider that we are *not* limited to the
standard call/cc functionality. Continuations can reasonably be taken
at any statement boundary. (They don't work well if taken from within
an expression. Or, if they do, it hurts my brain enough that I'd
rather you didn't...) You also should be able to invoke them anywhere,
including within expressions.
You're not obligated to pass the continuation for the call/cc into
call/cc (you could pass another one in if you chose), nor, I suppose,
are you obligated to not keep it around for later use.
Okay, how about the following as a suggested syntax for getting
at/using continuations.
1. You can get the current continuation by doing
caller.continuation;
Does caller with no args mean current execution context, with
caller(1) referring to our caller? We also want to be able to take a
continuation right ahead of the current execution point within our current
function (kind of like a delayed fork), not just at the point where we
return to our caller. I had originally written caller(-1).continuation
for this in a previous mail, but deleted it because it seemed only a
matter of time before some asked what caller(-2) would do ;).
2. I don't think being able to do C$block.continuation is useful
because continuations are runtime things.
If you can set a block's continuation at runtime, I think you should be
able to get it as well. Then you can splice a function into a dynamically
defined control sequence like this:
my $readfile is private = - $x { process_data $x, ... };
sub add_post_handler (CODE $block2) { # is public
$block2.continuation($readfile.continuation);
$readfile.continuation($block2.as_continuation);
}
sub read_file($data) { $readfile.($data) }
# ...
add_post_handler - $x { uncompress $x };
my $sum = blahblah;
add_post_handler - $x { die unless $sum eq md5sum $x; $x };
read_file $foo;
One good thing about this is that none of the blocks has to be aware of
continuations itself, and the continuation-handling ugliness can be
separated from the useful-work-doing ugliness.
3. C$block.continuation($a_continuation) can be thought of as a kind
of curry. It sets up a 'version' of a block which will return to
C$a_continuation. This would mean you can then do:
$block.continuation($a_continuation).(*@arglist);
which calls C$block with @arglist, but the block then returns to
the continuation.
By a version, do you mean that $block.continuation($x) returns a copy of
$block with its new continuation? I was thinking it would be useful to
modify $block's continuation, so every caller of $block would get the new
continuation. You could always make a copy of $block (not sure of the
syntax) if you wanted to set up your own personalized version.
[Unsatisfactory attempt to explain what a continuation is deleted
because *my* head started to hurt as I tried to explain it...]
I thought your examples (elided) did a fine job...
/s
Re: Reflection...
On 4 Jul 2002 [EMAIL PROTECTED] wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
At 8:32 AM +0100 7/3/02, [EMAIL PROTECTED] wrote:
For true scariness, consider:
$sub.current_continuation($new_continuation);
Some days you really, really scare me Piers...
Heh. Scary can be good.
This would be an interesting thing to do, though. I don't see why it
couldn't be done.
You know, the more I think about it, I'm not sure it *is* a good
idea. Once you have continuations in play you could have multiple
'live' continuations associated with a single sub, so how would you
decide *which* continuation was the important one.
All of them! I don't see how the getter/setter mentioned above would
automatically lead down this path to madness, but it's madness I kind of
like. If I'm not confused, the insane version lets you do threading:
$current_block.push_continuation($some_continuation)
or quantum shenanigans:
$current_block.push_continuation(any(*@some_ccs))
And the sane one allows dynamically-joined blocks:
$block1 = { ... }
$block2 = { ... }
$block1.continuation($block2.as_continuation);
$block1($something);# evaluate block1 then block2, then keep going
Sick. Anyways, I think it seems like a more natural way to do things than
traditional call/cc. $block.continuation reads as where do I go after
$block?; $block.continuation($foo) as after executing $block, proceed
on to $foo; (call/cc func) as call func with a single argument being
the 'rest of the current computation'. This last definition makes Scheme
and Lisp people happy, but (at least for me) the first two are much easier
to grasp, as they refer to what's going on more concretely.
/s
Re: Perl6 grammar (take III)
Here's a later, greater version of the parser. It hopefully addresses all
the limitations listed for the previous parser. New limits:
- While I haven't specified argument contexts for the builtin functions,
it should be possible to do so in the same way as for control
structures).
- Error reporting is awful -- the error will appear at the start of
the top-level statement that failed. If it's a sub definition, this
will leave you with several iterations of remove the outermost
brackets and try again.
This iteration is somewhat faster, though still dog-slow. Run it as
$0 --cache [modulename]
to save or use a precompiled parser in modulename.pm. It parses an
updated[1] version of the calculator in Exegesis 4 in a blinding 12 sec,
including a bit over 2 sec in startup time. And yes, it still just
produces hideous LISP-like gibberish. Sorry. Some of the output cruft
results from squashing circular data references in the autotree output.
I haven't tracked down why they're there yet.
Differences from Perl 5 (and/or previous version), in order from good
to controversial:
- Bare blocks and all kinds of closures can appear anywhere. The rule
is: if it contains only pairs, it's an anonymous hash ref.
Otherwise, it's a block.
- Semicolons are very optional, in the sense that you can leave them
off of anything that ends in a closing bracket. So this:
for x - $y; $z { ... } $x = { a = 23 } $y += 3;
is actually accepted as three statements. I don't know if this is a
good thing or not, but I think it's unambiguous, and isn't too hard
to implement. Note that this
if 1 { 2 } else { 3 } +4
is a single statement whose value is 6, since if ... is treated
like a weird-looking function call.
- There are no right list operators. All declared functions have an
associated want rule that decides how what follows them should be
parsed. The default rule considers the rest of the statement as an
argument list. Unary operators want a high-precedence scalar item.
Control structures like for and if... want closures and other
strange things. Eventually, similar want-age should be created from
prototypes to user subs, but for now any subs you define take a
single flat list.
- There is only a single precedence level for prefix operators (sort
of -- context operators are top-precedence). This includes file
tests, unary =~ /!~\\-/, and named operators (function calls w/o
parens).
- The pair constructor (=) has precedence between =~ and unary
prefix operators, instead of being just a fat comma. Since it is
the constructor syntax for a datatype, I don't think the former low
precedence makes sense. Consider
a = blah =~ { ... }
(a = blah) =~ { ... }# with new precedence
a = (blah =~ { ... })# with old precedence
I think the first makes more sense if a pair is an object. I
initially had it as term-precedence, but people like to do things
like this:
-23 = 4 # == (-23) = 4, not -(23 = 4)
so it has to bind less tightly than high-precedence unary
operators.
- Precedence for the adverbial colon and 'but' (as well as 'err',
which appears in Exe 4) have migrated a bit. 'but' and 'err' bind
to scalar expressions (more tightly than commas), while the colon is
between 'or' and comma.
- Error reporting is awful -- the error will appear at the start of
the top-level statement that failed. If it's a sub definition, this
will leave you with several iterations of remove the outermost
brackets and try again.
Anyways, enjoy,
/s
[1] Need some class defs:
class Err::Reportable is Exception {...}
class NoData is Exception {...}
class Inf { ... }
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
##
my %WANT;
sub ::find_want {
my $f = shift;
$f = $f-{__VALUE__} || $f-{__PATTERN1__} if ref $f;
# print STDERR find_want $f: $WANT{$f}\n;
$WANT{$f} || '__fail__';
}
##
# 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 =
Re: Perl 6 grammar progress?
On Sun, 30 Jun 2002, Ashley Winters wrote:
I don't know how the grammars are going, and I'm not fit to write one
myself,
Hey, neither am I, but that hasn't stopped me from taking a stab or two,
figuring that through pain comes fitness. The attempt has certainly given
me a much better understanding of Perl (both 5 and 6) than I had before as
a mere user. If there's anyone else out there with the time for and
interest in working on a Parse::RecDescent grammar, feel free to speak up.
but I wrote a list of variables I'll try to parse using any
grammars which go by. Are all of these legal? I suppose that's more of
a -language question.
Cc'd accordingly.
# need more tests for ${}, I'm not evil enough for it
${foo};
Neither am I, but we might as well throw in {foo}, %{foo}, {foo}, maybe
even $*{foo} (global symbolic reference?).
# Also, there are globals to consider
[...]
And the wonderous *@$*foo (flattened dereferenced global $foo?).
# off the subject, but lets make sure $foo.. is parsed correctly
$foo..1;
$foo..[1];
$.foo..{1};
Color me slow, but are these even legal? What does an anonymous list
constructor do on the LHS of a range operator? I suppose it could just be
one example of something that is always true, but could it possibly be
useful other than by the perversity of overloading ..? And would the
second require whitespace before the '{' to be parsed as a closure/block?
foo{1}; # I ass_u_me {} [] and () can be overloaded?
Blech! Even if it's legal, this seems like it should be a mandatory smack
upside the head. If we allow this, someone will overload {} to do hash
slices on %foo, and we'll be right back to Perl 5 ;).
foo(1);
foo();
Strange overloading again, or am I missing something? If we allow
subscripting and calling to be overloaded on variables with any kind of
sigil, what's the point of having sigils at all?
foo{1}; # foo is unary here
Is this a hash subscript on a no-argument function returning a hash, or a
block passed to foo(block), or a malformed hash constructor being passed
to foo(%hash)? I vote for the first, because I thought blocks' and
hashes' opening brackets always needed preceding whitespace (or at least
/(?!\w){/).
foo.(); # Is this { foo() }() or foo()? I would vote former
aka foo()()? Sick...
# As a final sanity check, lets chain these things
.proc[$*PID].ps.{RSS};
== {.proc()[$*PID].ps().{RSS}}, right?
proc.[$*PID].ps().{RSS};
== {proc().[$*PID].ps().{RSS}}? Or is that '[]' overloaded on a '.'
operator on 'proc'? In either case, we may have to do a sick amount of
look-ahead and guess-work to figure out whether the leading '' is a sigil
or a dereference. Which has higher precedence: prefix '' or infix '.'?
You might also want to add a couple of directly-chained subscriptings,
e.g.
foo[1]{2}(3)[4..6].
/s,
sufferer at the fickle hands of PerlQt.
