Larry wrote:
> But the language in the following lexical scope is a constant, so what can
> :syntax($foo) possibly mean? [Wait, this is Damian I'm talking to.]
> Nevermind, don't answer that...
Too late! ;-)
Regex syntaxes already are a twisty maze of variations, mostly alike. I
can easily env
Not at all.
Unlike CPAN Testers, this is designed with standalone components.
So as long as you can create a Distribution::Harness object and run it,
it should spit out PITA::Report XML content/files for you, without any
of the system image stuff needed.
So if you wrap up your tests as somet
# New Ticket Created by jerry gay
# Please include the string: [perl #37730]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37730 >
i've attached a patch with some modifications to Test::Builder in
order to fix some bugs,
On 11/23/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> >
> > for ^5 { say } # 0, 1, 2, 3, 4
>
> I read this and I'm trying to figure out why P6 needs a unary operator
> for something that is an additional character written the more legible
> w
On 11/22/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> :syntax
> :syntax
> :syntax
> :syntax
> :syntax
> :syntax
Aren't we providing an interface to define your own regex modifiers?
All of these can easily be mapped into Perl 6 patterns, so...
Modules welcome! ;-)
On Nov 23, 2005, at 4:42, Will Coleda wrote:
I'd like to provide an easy way to provide this mapping for language
developers so the users of the language don't have to remember to add
the second line whenever they use, e.g. Tcl.
Whenever some code is using e.g. Tcl, a library is loaded that
Luke wrote:
On 11/22/05, Damian Conway <[EMAIL PROTECTED]> wrote:
:syntax
:syntax
:syntax
:syntax
:syntax
:syntax
Aren't we providing an interface to define your own regex modifiers?
Sure. But it'd lead to much less namespace pollution and much greater
readabilit
On Nov 23, 2005, at 6:13, Josh Isom wrote:
When I first installed parrot, curses worked with it, but it fails to
work
anymore for me, either under darwin or freebsd. On darwin, it clears
the
screen, and can only read "assertation failed" before it clears and
dies,
so I can't see diagnostics
On Tue, 2005-11-22 at 22:42 -0500, Will Coleda wrote:
> > .HLL "foo", "" # or "foo_group" - load dynamic PMCs too
> > .HLL_map .LexPad -> .DynLexPad # (2)
> >
>
> I'd like to provide an easy way to provide this mapping for language
> developers so the users of the language don
On Nov 23, 2005, at 3:06, chromatic wrote:
On Wed, 2005-11-23 at 01:39 +0100, Leopold Toetsch wrote:
But my argument was: whenever you
start introspecting a call frame, by almost whatever means, this will
keep the call frame alive[1] (see Continuation or Closure). That is:
timely destruction
Can we have:
say 1..Inf;
to output an infinite stream, instead of just looping forever?
OTOH, it would be nice if
say substr( ~(1..Inf), 0, 10 )
printed "1 2 3 4 5".
Flattened lists would still loop forever (or fail):
say **(1..Inf);
$s = substr( ~( **(1..Inf) ), 0, 10 );
- Flavio
I ran into a problem trying to convert Leo's "Case 1" example so that it
uses methods instead of subs. Here's how far I got:
.HLL 'Amber', 'amber_kernel'
.sub main :main
newclass $P0, 'FOO'
$P1 = new 'FOO'
$P1.main()
.end
.namespace [ "FOO" ]
.sub main :method
$P0 = self.do_add3(20
Larry Wall:
> for ^5 { say } # 0, 1, 2, 3, 4
The 'for' can go if a list (and also an array) would imply looping, when
it is positioned next to a block:
a. say (0..4);
b. { say; say } (0..4);
c. (0..4) { say; say }
d. @{0..4} { say; say }
(etc.)
b. now produces 2 lines with 01234 (in p
On Nov 23, 2005, at 4:39 AM, Roger Browne wrote:
On Tue, 2005-11-22 at 22:42 -0500, Will Coleda wrote:
.HLL "foo", "" # or "foo_group" - load dynamic PMCs too
.HLL_map .LexPad -> .DynLexPad # (2)
I'd like to provide an easy way to provide this mapping for language
develop
On Wed, 2005-11-23 at 09:09 -0500, Will Coleda wrote:
> I can, of course, add the C now, and have it be functional. I was
> just pondering what might be a simpler way for future PMC authors.
A bigger problem will occur for any HLL that has no PMCs of its own, yet
wishes to use DynLexPad. How to
Roger Browne wrote:
.sub add3 :method :outer('do_add3')#(4)
.param pmc arg
$P0 = n_add arg, 3 #(5)
.return($P0)
.end
This segfaults at #(3).
Actually at #(5)
- replace line #(5) by "$P0 = n_neg arg" (the significance
The reason was lexical lookuo inside M
On Wed, 23 Nov 2005, Ruud H.G. van Tol wrote:
for ^5 { say } # 0, 1, 2, 3, 4
The 'for' can go if a list (and also an array) would imply looping, when
it is positioned next to a block:
a. say (0..4);
b. { say; say } (0..4);
I'm not really sure: while I like it for its conciseness -and
I thought that was one of the issues leo was addressing with
the .HLL_map directive... From leo's initial email:
.HLL "foo", "" # or "foo_group" - load dynamic PMCs too
.HLL_map .LexPad -> .DynLexPad # (2)
Regards.
On Nov 23, 2005, at 9:28 AM, Roger Browne wrote:
On Wed,
On 11/23/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
>
> > On 11/22/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> >
> >> :syntax
> >> :syntax
> >> :syntax
> >> :syntax
> >> :syntax
> >> :syntax
> >
> >
> > Aren't we providing an interface to define your own r
Roger Browne wrote:
A bigger problem will occur for any HLL that has no PMCs of its own, yet
wishes to use DynLexPad. How to specify that?
As coke writes this is in the intial posting of this thread, but he has
cited only half ot the show. Here is all again:
SYNOPSIS
.sub _load :immediat
Luke~
On 11/23/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 11/23/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> > On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> > >
> > > for ^5 { say } # 0, 1, 2, 3, 4
> >
> > I read this and I'm trying to figure out why P6 needs a unary operator
> > f
On 11/23/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 11/23/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> > On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> > >
> > > for ^5 { say } # 0, 1, 2, 3, 4
> >
> > I read this and I'm trying to figure out why P6 needs a unary operator
> > for some
Matt Fowles skribis 2005-11-23 11:55 (-0500):
> I think using C< ..5 > to mean (0, 1, 2, 3, 4) would be a more
> sensible option. Makes sense to me at least.
.. as a unary is uncomfortable, because of the different whitespace
styles people use with this operator. I personally use both "0..15"
an
Rob Kinyon skribis 2005-11-23 11:58 (-0500):
> I don't use 0..$n-1 very often. I use 0..$#arr most often.
Good point. Doesn't ^5 encourage [EMAIL PROTECTED] too much? After all, we
should
write what we mean, instead of something that happens to evaluate to the
same list. We mean to use indexes,
On 11/23/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote:
> Can we have:
>
> say 1..Inf;
>
> to output an infinite stream, instead of just looping forever?
>
> OTOH, it would be nice if
>
> say substr( ~(1..Inf), 0, 10 )
>
> printed "1 2 3 4 5".
>
> Flattened lists would still loop forever (or fa
Ruud H.G. van Tol:
> b. { say; say } (0..4);
>
> b. now produces 2 lines with 01234 (in pugs). With implied looping
> that would be 10 lines, starting with two 0-lines.
Standard:
do {say; say} for 0..4
for 0..4 {say; say}
Wishful:
(0..4) »{say; say}
pugs doesn't seem to do the
("f","o
On Wed, Nov 23, 2005 at 02:23:51PM +0100, Ruud H.G. van Tol wrote:
: Larry Wall:
:
: > for ^5 { say } # 0, 1, 2, 3, 4
:
: The 'for' can go if a list (and also an array) would imply looping, when
: it is positioned next to a block:
:
: a. say (0..4);
: b. { say; say } (0..4);
: c. (0..4)
Larry Wall skribis 2005-11-23 9:19 (-0800):
> ^5.each { say }
Without colon?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
On Wed, Nov 23, 2005 at 11:58:23AM -0500, Rob Kinyon wrote:
: Here's an issue - if ^$x would be one($x), then what will [EMAIL PROTECTED]
be? To
: me, that seems like it should be one(@x), which is entirely useful.
: Except, if I try and use it as [EMAIL PROTECTED] (which, to me, would be
useful)
On Wed, Nov 23, 2005 at 11:55:35AM -0500, Matt Fowles wrote:
: I think using C< ..5 > to mean (0, 1, 2, 3, 4) would be a more
: sensible option. Makes sense to me at least.
That doesn't derive well from any of:
..
^..
..^
^..^
If the rule is "you can omit the 0", then it's ..^5
On Wed, Nov 23, 2005 at 06:21:56PM +0100, Juerd wrote:
: Larry Wall skribis 2005-11-23 9:19 (-0800):
: > ^5.each { say }
:
: Without colon?
Yeah, that one doesn't work a couple of way. Unfortunately .each still
binds tighter than ^ too. So it'd have to be:
(^5).each: { say }
unless w
On Wed, Nov 23, 2005 at 09:09:00AM -0500, Will Coleda wrote:
> >Why bother with an artifical subclass?
>
> Mainly to avoid having the C code in my .pmc
I'm very much in favor of adding explicit metadata, which is
parseable, rather than just limiting ourselves to writing the
executable consequence
Flavio S. Glock skribis 2005-11-23 10:13 (-0200):
> Can we have:
> say 1..Inf;
It's important, I think, to note that this isn't item context, but list
context. Str list context, but still list context. Which means 1..Inf
isn't stringified as a whole. &say will have an array that represents
the l
Larry Wall wrote:
On Wed, Nov 23, 2005 at 06:21:56PM +0100, Juerd wrote:
: Larry Wall skribis 2005-11-23 9:19 (-0800):
: > ^5.each { say }
:
: Without colon?
Yeah, that one doesn't work a couple of way. Unfortunately .each still
binds tighter than ^ too. So it'd have to be:
(^5).ea
Juerd:
> Doesn't ^5 encourage [EMAIL PROTECTED] too much?
Can you explain when that creates a problem?
Maybe someone doing
for ([EMAIL PROTECTED])->$i { say @foo[$i] }
in stead of
say for @foo
> After all, we should
> write what we mean, instead of something that happens
> to evaluate to t
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 expression.
[EMAIL PROTECTED] returns the *number of elements*, not the index of the last
elemen
On Wed, Nov 23, 2005 at 03:14:40PM -, [EMAIL PROTECTED] wrote:
> implement Sub.get_caller() method; test
You keep confusing static and dynamic call information.
Like I've said (repeatedly :-)), rule #1 of call info is:
Subs don't have callers.
Call frames have callers.
Therefore, this co
Juerd wrote:
Rob Kinyon skribis 2005-11-23 11:58 (-0500):
I don't use 0..$n-1 very often. I use 0..$#arr most often.
Good point. Doesn't ^5 encourage [EMAIL PROTECTED] too much? After all, we
should
write what we mean, instead of something that happens to evaluate to the
same list. We mean
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 expression.
:
: [EMAIL PROTECTE
On Wed, Nov 23, 2005 at 10:45:21AM -0800, Mark A. Biggar wrote:
: Actually I like that and think that ^$x should be 0..($x-1) and that
: [EMAIL PROTECTED] should be define to return the array's index set (usually
: 0..$#foo) but maybe something else for a non-zero based array.
Well, as I said in
On Wed, Nov 23, 2005 at 10:58:53AM -0800, Larry Wall wrote:
: Well, as I said in my other reply, that's not a big problem for
: 1-dimensional arrays. But it does possibly make sense that ^ on a
: multidimensional array or hash would return a zip of all the key sets.
: Plus it generalizes ^%hash to
On Wed, Nov 23, 2005 at 12:07:08PM -0500, Rob Kinyon wrote:
: On 11/23/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote:
: > OTOH, it would be nice if
: >
: > say substr( ~(1..Inf), 0, 10 )
: >
: > printed "1 2 3 4 5".
: This would work, I think, if ranges were convertable to iterators,
Range obje
Larry~
On 11/23/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 23, 2005 at 11:55:35AM -0500, Matt Fowles wrote:
> : I think using C< ..5 > to mean (0, 1, 2, 3, 4) would be a more
> : sensible option. Makes sense to me at least.
>
> That doesn't derive well from any of:
>
> ..
> ^
Juerd:
2005/11/23, Juerd <[EMAIL PROTECTED]>:
> Flavio S. Glock skribis 2005-11-23 10:13 (-0200):
> > Can we have:
> > say 1..Inf;
>
> It's important, I think, to note that this isn't item context, but list
> context. Str list context, but still list context. Which means 1..Inf
> isn't stringifi
Larry Wall skribis 2005-11-23 11:16 (-0800):
> Range objects are supposed to *be* iterators, but pugs isn't there yet,
> last I checked.
Is the associated sigil @ or $? Either way, there's a problem. $foo
can't flatten in list context, which .. does want, which would be
inconsistent, but with @, i
On Wed, Nov 23, 2005 at 05:24:11PM -0200, Flavio S. Glock wrote:
: Ah, ok - but I believe that say() is slurpy, which means the list must
: be instantiated first.
It's * instantiated, but not ** instantiated, so the iterators buried
in the .specs of the list aren't forced to evaluate yet. And ran
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> One of the other reasons I like ^5 is that the uparrowness of it
LW> naturally reads as "up to 5". But for containers we could certainly
LW> abstract it out to the domain.
it also harkens back to apl's iota op which did similar thing
On Wed, Nov 23, 2005 at 08:35:09PM +0100, Juerd wrote:
: Larry Wall skribis 2005-11-23 11:16 (-0800):
: > Range objects are supposed to *be* iterators, but pugs isn't there yet,
: > last I checked.
:
: Is the associated sigil @ or $? Either way, there's a problem.
No, either way it does what you
On Wed, Nov 23, 2005 at 02:21:15PM -0500, Matt Fowles wrote:
: I like C< ..^5 > better than C< ^5 > actually. I was going for the
: rule that an omitted LHS was 0 and an omitted RHS was infinity (your
: probably cannot omit both).
But that only saves you 1 keystroke, and eliminates unary .. for a
Larry Wall:
> I can see the mathematical appeal of coming up with a language in
> which there is a meaning for every possible combination of tokens.
Yes, that sounds like my language. I agree it's not Perl. And not a lot
of other things too.
> It's a counterintuitive fact
> that languages that
Thanks to Leo and Will for clarifications, and to Leo for the r10150
bugfix. That has enabled me to implement lexical handling for Amber.
With Parrot doing most of the heavy lifting, it wasn't too hard. Now I
just have to write the tests and documentation :-)
Leo wrote:
> BTW I had to change (r101
2005/11/23, Larry Wall <[EMAIL PROTECTED]>:
>
> I think the last one is more feasible than the middle one, at least
> by default. The problem is that stringification is considered a result
> of a kind of scalar context, and ordinary scalar context is not lazy
> in Perl 6. So we'd probably need to
On Tue, 22 Nov 2005 14:34:12 -0800, Larry Wall wrote:
> What tipped me over the edge, however, is that I want ^$x back for a unary
> operator that is short for 0..^$x, that is, the range from 0 to $x - 1. I
> kept wanting such an operator in revising S09. It also makes it easy to
> write
>
>
On Wed, Nov 23, 2005 at 08:04:32AM -0800, Peter Scott wrote:
: On Tue, 22 Nov 2005 14:34:12 -0800, Larry Wall wrote:
: > What tipped me over the edge, however, is that I want ^$x back for a unary
: > operator that is short for 0..^$x, that is, the range from 0 to $x - 1. I
: > kept wanting such an
On Nov 23, 2005, at 19:08, Chip Salzenberg wrote:
On Wed, Nov 23, 2005 at 03:14:40PM -, [EMAIL PROTECTED] wrote:
implement Sub.get_caller() method; test
You keep confusing static and dynamic call information.
Not confusing actually, maybe abusing the static sub structure by
adding a d
On 11/21/05, jerry gay <[EMAIL PROTECTED]> wrote:
> i've checked in a subset of Perl 5.9.2's regexp tests for PGE to chew
> on. for now, i modified the stolen harness to emit PIR. the harness is
> currently very ugly... that won't be for long, however, as i'll
> refactor it soon.
>
it's been refact
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 skribis 2005-11-23 13:10 (-0800):
> : It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n.
> But then you'd usually want 1..$n instead...
I think this illustrates very well that it's a bit silly to have a
shortcut for just one of the three much-used ranges. My view
Juerd skribis 2005-11-24 0:39 (+0100):
> Personally, I think even ^.., ^..^ and ..^ are too much, but that I can
> live with.
For the record, I don't want to die if ^ is introduced. If it's there,
I'll use it. If using [EMAIL PROTECTED] becomes accepted style, I'll use it.
The "live with" isn't
On Tue, Nov 22, 2005 at 09:32:37AM -0800, Chip Salzenberg wrote:
> On Tue, Nov 22, 2005 at 03:28:02PM +0100, Leopold Toetsch wrote:
> > sub do_add3 {
> > my $a = $_[0];
> > sub add3 {
> > $a + 3;
> > }
> > add3();
> > }
>
> What Perl 5 does with that case is just a plain ol
I've checked in the code to transform PunieGrammar match objects into
AST trees. The core pieces are:
- A tree grammar for the transformation in languages/punie/lib/
pge2past.g
- A series of AST node classes in languages/punie/lib/PAST/
- A script that parses a Punie source file, transforms t
On 11/23/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote:
> How about allowing reduce() to return a scalar with the same laziness
> as the list:
>
> [EMAIL PROTECTED] - a lazy string if @list is lazy
> [EMAIL PROTECTED] - a lazy number if @list is lazy
>
> It would look like:
>
> $foo = s
On 11/23/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> : I'm also puzzled that you feel the need to write 0..$n-1 so often; there
> : are so many alternatives to fenceposting in P5 that I almost never write
> : an expression like that, so why is it cropping up that much in P6?
>
> Couple reasons occu
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> I don't think it is, no. ParTcl implements global/lexical storage
> rather naively at the moment (because I didn't understand that the lex
> opcodes worked this way when I implemented this over the summer).
> Right now we always use store_lex to assign to
On 11/23/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> Basically, we're attaching the whole lazy/nonlazy mess to the
> list/scalar distincion, which I think is a really good default.
> We use ** and lazy() to violate those defaults.
I think you might be mixing up the "scope" of laziness here. Havin
On Nov 23, 2005, at 19:08, Chip Salzenberg wrote:
You keep confusing static and dynamic call information.
While at static objects like subroutine PMCs - there is some code
around that is setting properties on .Sub objects.
$ find . -name '*.imc' -o -name '*.pir' | xargs grep -w setprop
At
66 matches
Mail list logo