Note that I sent a patch to that effect to p6c Jun 2 in a mail titled
"support of parsing from a non TOP rule"
that has not been applied. It still works. Attached below. Testable by :
use Test; grammar A { token hi { hi } }; ok A.parse( 'hi',
:rule) eq 'hi', "Grammar.parse: :rule"
On Sun, J
When doing an analyse of a sample parse tree, I note that it is
cluttered by the reduction of optional subrules
to generate a zero length parse subtree. That is, rules with a '?'
quantifier matching zero time.
Suppressing such matching rules from the parse tree would make it
easier to read.
Additi
On Tue, Sep 16, 2008 at 6:11 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 15, 2008 at 10:09:41PM -0500, John M. Dlugosz wrote:
>> Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote:
So, how does one get an object to pretend to be a value type for
purposes of assign
what is the equivalent convention for yadayadayada in regex. Cuz ...
is alread meaningful in regex. Should I use <...> or {...} ?
Should the first be predefined?
I want something that is a placeholder that parses but fails if
someone pastes it. In other words the equivalent of
a sub yada yada ya
In Perl5, the meaning of the undef value is overloaded. It can mean
either the value an uninitialized variable or it may indeed mean a
genuine undefined value. Perl5 is biased toward the first meaning: in
string context, the value behaves as an empty string; In integer
and float context, it respe
Larry Wall a écrit :
| On Wed, Nov 23, 2005 at 07:10:39PM +0100, Juerd wrote:
| : Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
| : > > Doesn't ^5 encourage [EMAIL PROTECTED] too much?
| : > Can you explain when that creates a problem?
| :
| : It's not about problems in execution, it's about
Larry Wall a écrit :
| On Fri, Nov 11, 2005 at 08:42:44AM -0500, Joe Gottman wrote:
| : Do functions like map and grep, which in Perl5 return lists, return
| : Iterators in Perl6?
|
| A list may contain iterators. Lists don't eagerly flatten in Perl 6.
|
| : Can an Iterator be passed to a functi
On Thu, Jun 30, 2005 at 06:17:14AM -, David Formosa (aka ? the Platypus)
wrote:
> On Thu, 30 Jun 2005 05:17:56 +0300, Yuval Kogman
> <[EMAIL PROTECTED]> wrote:
> [...]
>
> > I gave Perl 6 to Mr. Clean, and he said that if type inferrence was
> > formalized, and used always, except that it's
On Fri, May 13, 2005 at 12:31:09PM -0700, Larry Wall wrote:
> On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote:
> : Well, the value's pretty easy--just pass in a variable:
> :
> : my $b = $a is foo($bar);
>
> As we currently have it, that is not legal syntax. "is" may
On Fri, May 13, 2005 at 06:37:50PM +, [EMAIL PROTECTED] wrote:
>
>
> > There is syntax to define trait and properties
> > but is there an API?
> >
> > my $b = eval '$a but true'; # setting a true property
> > # API to do it without an eval?
> I don't understand why you think you need the
There is syntax to define trait and properties
but is there an API?
my $b = eval '$a but true'; # setting a true property
# API to do it without an eval?
A trait setter probably does not make sense but for the
implementer because it should not be set at run time.
Incidentally, in a interacti
On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote:
Thank you for your detailled answer. I still don't get what you mean
by "[] pattern matching arguments".
Do you mean smart pattern matching on composite values?
>
> A lot of features are making it into Perl 6 that have historically
Hi,
I am making a presentation about Perl6 this week end. My point will
be: the next generation of applicative languages will be scripting
languages because they have come of age.
Alternatives don't cut it anymore. Indeed C and C++ are memory
allocation nightmare; Java and C# don't have read-ev
On Thu, Feb 24, 2005 at 09:42:30AM -0800, Larry Wall wrote:
>
> Anyway, I don't profess to have thought deeply about type inferencing.
> But I do know that I don't want to turn Perl 6 into ML just yet...
>
> Larry
>
Speaking of ML, it appears to me that Perl6 rules are a mechanism that
can act
Giving scoping functions the status of list operators
would allow to drop parentheses when not used in conjunction
with initializer so one could write:
my $a, $b, $c;
instead of
my ($a, $b, $c);
Most people use scoping functions as the top most function of the
corresponding statement AST s
On Sun, Jan 09, 2005 at 06:31:24AM -0600, Luke Blanshard wrote:
> David Storrs wrote:
> >Out of curiosity, why are we all spelling 'subject' without a 'c'?
> >Or is 'subjet' a word I'm not familiar with? (Honest question.)
>
> I assume it's a spelling error on the part of the original poster.
> F
On Fri, Jan 07, 2005 at 09:55:39PM +0100, Juerd wrote:
> Stéphane Payrard skribis 2005-01-07 21:23 (+0100):
> > > my $s := $subjet;
> > > my $c := $complement;
> > That's what I wanted to avoid.
>
> Why? Do you expect to use lots of one letter alia
On Fri, Jan 07, 2005 at 10:28:32AM -0800, Larry Wall wrote:
> On Thu, Jan 06, 2005 at 11:07:47PM +0100, Stéphane Payrard wrote:
> : To get an huffmanized name and a clear one, I would like some support
> syntax:
> :
> : sub canon( $subjet as $s , $complement as $c ) {
>
I expect Perl6 to be a language with a mix of dynamically typed and
statically typed variables. In a purely statically typed language like
OCAML, you generally don't need to declare the type of variables
when it can be inferred. So one can benefit from the speed of static
typing (no type info must
On Sun, Dec 19, 2004 at 06:44:33PM -0800, chromatic wrote:
> On Sun, 2004-12-19 at 20:25 -0600, Rod Adams wrote:
> > [snipped]
> >
> > $x = 4;
> > $y = 7;
> > $z = 12;
> > $r = 4543;
> > $q = 121;
> >
> > With a fixed width font, like all code editors use, all the =' like up,
> > and I can quick
S2:
my $foo = 42;
say %MY::<$foo>;# prints "42"
S6:
Perl5ish subroutine declarations
...
sub say { print qq{"@_"\n}; } # args appear in @_
Because C has no final newline, I would expect C will have
one. Final newline or not. What is your say?
--
stef
On Fri, Dec 03, 2004 at 06:38:42PM -0800, Larry Wall wrote:
> On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
> : This whole issue kind of makes me go 'ugh'. One of the things I like
> : best about Perl is the amazing simplicity of the <> input construct.
>
> Hmm.
>
> while
On Mon, Jul 26, 2004 at 10:29:15AM -0700, Brent 'Dax' Royal-Gordon wrote:
> The Perl 6 Summarizer wrote:
> > The infinite thread
> >Pushing onto lazy lists continued to exercise the p6l crowd (or at
> >least, a subset of it). Larry said that if someone wanted to hack
> >surreal numbers
On Fri, Jun 25, 2004 at 03:38:51PM +0200, [EMAIL PROTECTED] wrote:
>
>
>Hello,
>
> I have a wish for Perl6. I think it would be nice to have the possibility
> for more than one modifier after a simple statement.
>
> For example:
>
>print $a+$b if $a if $b for 1..3;
>
>
> Gerd P
Le Thu, May 27, 2004 at 12:34:32AM +0200, le valeureux mongueur Gabriel Ebner a dit:
> Hello,
>
> Mark Lentczner wrote:
> > http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html
>
> What's periodic about it?
We hope it will be periodically updated. :)
> Otherwise, _nice_ table.
indee.d
I use over and over this idiom in perl5:
$a{$_}++ for @a;
This is nice and perlish but it gets easily pretty boring
when dealing with many list/arrays and counting hashes.
I thought overloading the += operator
%a += @a;
Probably that operator should be smart enough to be fed with
a mixed
Le Wed, May 12, 2004 at 02:00:42AM +0200, le valeureux mongueur Pedro Larroy a dit:
> Hi
>
> Is there any chance that in perl6 there will be the possibility to write
> if/else statements without {}s with the condition at the beginning?
>
> Like
>
> if (condition)
> statement;
>
> In orde
On Fri, Apr 30, 2004 at 11:14:55AM +0200, Aldo Calpini wrote:
> let's suppose I want to build a class that keeps track of the objects it
> creates.
>
> let's suppose that I want this class to be the base for a variety of
> classes.
>
> let's suppose that I decide, rather than fiddling with the
I have confused assignement and initialisation in my previous
mail. Because they are two different operations, there is no
problem they have different semantics. A6 described both
operations. It described pairs as arguments used to initialize
parameters and pairs in assignement.
--
stef
My understanding of the semantic of pairs as in A6:
A pair in a given scalar context should return its first element
coerced to match the said context.
This seems to be a prerequisite to use pairs as function arguments.
Example with the boolean context:
bool $b = a => 10; # $b == 1
On Thu, Feb 12, 2004 at 09:38:47AM -0800, Larry Wall wrote:
> Yes, that's a very good paper, which is why Perl 6 now has something
> called Roles, which are intended to degenerate either to Traits or
> Interfaces. My take on it is that Roles' most important, er, role
> will be to abstract out the
On Sat, Dec 13, 2003 at 12:12:59PM -0800, Larry Wall wrote:
>
> print $ref
>
> it doesn't do what you want, but
>
> print $ref.as(Array)
>
> might work a lot better, though of course
>
> print @$ref
>
What is supposed to do the splat operator in this context? My
understanding is
>
> A role can also supply one or more attributes.
>
> : inheritance (and maybe some other stuff, too). Used with C.
The smalltalk paper you mentionned which talked about roles (under
the name of traits) said that roles were stateless.
What are the consequences of using stateful roles?
Hi,
I don't remember anything about enums and bitenums in the
apocalypses. This is probably not very difficult to roll out
something using macros but I feel that should belong to the
standard language.
--
stef
s/// in string context should return the string after substituion.
It seems obvious to me but I mention it because I can't find it
in the apocalypses.
--
stef
On Thu, Sep 18, 2003 at 02:12:31PM -0700, chromatic wrote:
> On Thursday, September 18, 2003, at 12:33 PM, Gordon Henriksen wrote:
>
> >Ah, shouldn't optimization be automatic? Much preferrable to provide
> >opt-out optimizations instead of opt-in optimizations.
>
> No. That's why I tend to opt-
On Wed, Mar 26, 2003 at 05:40:56PM +0100, Robin Berjon wrote:
> Dan Sugalski wrote:
> >At 4:47 PM +0100 3/26/03, Robin Berjon wrote:
> >>Fast and efficient graphs of all sorts would be very useful. A way to
> >>define a complex graph of interlinked arbitrary objects while being
> >>reasonable on
On Wed, Feb 12, 2003 at 09:17:22AM +0100, Stéphane Payrard wrote:
> On Tue, Feb 11, 2003 at 11:42:27PM -0800, Brent Dax wrote:
> > Stéphane Payrard:
> > # I was so sure that, in case of success, the file operators
> > # would return the filename that I wrote the following
On Tue, Feb 11, 2003 at 11:42:27PM -0800, Brent Dax wrote:
> Stéphane Payrard:
> # I was so sure that, in case of success, the file operators
> # would return the filename that I wrote the following code to
> # print where are the perl interpretors in the PATH. But, in
> #
On Fri, Feb 07, 2003 at 02:30:47PM -0500, Mark J. Reed wrote:
> On 2003-02-07 at 14:26:42, Mark J. Reed wrote:
> > Not really, though. A list can be an lvalue, provided it is a list
> > of lvalues:
Note that to avoid the burden of writing an explicit slice, 'undef' is
considered as a lvalue in su
On Mon, Feb 03, 2003 at 08:19:29PM -0500, Miko O'Sullivan wrote:
> On Tue, 4 Feb 2003, [iso-8859-1] Stéphane Payrard wrote:
>
> > In the tradition of Perl concision, I would like newline to be a
> > statement terminator everywhere it can: that is when
> >a) t
On Mon, Feb 03, 2003 at 06:11:23PM -0700, Luke Palmer wrote:
[snip]
>
> See, this is the main, unPerlish thing you're doing. You're enforcing
> particular styles upon people, something Perl is proud of *not* doing.
>
> Let's not forget the often occurence of:
>
> $fh = open 'foobar'
>
>
> Multiline atomic statements just have to be broken at the right
> place to avoid to break them:
Sorry about my English. Let me reformulate.
When folding an atomic statement, it becomes two statements or its
meaning is unchanged depending if an operand is expected or not at the
position of th
In the tradition of Perl concision, I would like newline to be a
statement terminator everywhere it can: that is when
a) the parser expects an operator
_and_ b) we are not in the middle of a parenthesised expression.
Accessorily, it would also help people to switch back and forth
betwee
On Thu, Jan 30, 2003 at 09:11:10AM -0800, Damian Conway wrote:
> >What was the reason again which Larry rejected unifying the syntax for
> >array
> >and hash indexing?
>
> Because some things have both, and do different things with each.
> And because some built-in redundancy is useful for error
On Wed, Jan 29, 2003 at 09:44:27AM -0500, Aaron Sherman wrote:
>
> Yes, I would expect that. In my opinion there is no difference between
> an array and a hash other than the underlying storage and the
> type-management of the key. I'm increasingly of the opinion that a)
> there should be no @ vs
On (09/12/02 06:00), Stéphane Payrard wrote:
> Date: Mon, 9 Dec 2002 06:00:40 +0100
> From: Stéphane Payrard <[EMAIL PROTECTED]>
> To: Damian Conway <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Subject: right-to-left pipelines
&g
[snipped]
> so it's easy to build up more complex right-to-left pipelines, like:
>
> (@foo, @bar) :=
> part [/foo/, /bar/],
> sort { $^b <=> $^a }
> grep { $_ > 0 }
> @data;
>
>
I wo
On (02/11/02 11:18), Philippe 'BooK' Bruhat wrote:
> Date: Sat, 2 Nov 2002 11:18:22 +0100 (CET)
> From: Philippe 'BooK' Bruhat <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Subject: Re: [RFC] Perl6 Operator List, Take 5
>
> On Thu, 31 Oct 2002, Damian Conway wrote:
>
> > Lar
On (22/09/02 10:37), Me wrote:
> From: "Me" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Subject: <( )> vs <{ }>
> Date: Sun, 22 Sep 2002 10:37:59 -0500
>
> In several forms of courier, and some other text fonts
> I view code in, I find it hard to visually distinguish the
> pattern e
- Original Message -
From: "Cameron Laird" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 11, 2001 8:43 PM
Subject: Re: dLoo releases peer-to-peer programming language
> > From [EM
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: "Nathan Torkington" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 11, 2001 6:59 PM
Subject: Re: dLoo releases peer-to-peer programming language
> At 10:16 AM 7/11/2001 -0600, Natha
52 matches
Mail list logo