:syntax (was: \x{123a 123b 123c})
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 envisage Perl users occasionally needing/wanting/using
patterns which are any of:
:syntax
:syntax
:syntax
:syntax
:syntax
:syntax
Not just because people are used to different syntaxes, but also because
programs will want to accept search patterns in different (generally: more
restrictive) syntaxes so as to be able to interpolate them safely:
use Regex::Google;
for =<> :prompt -> $search {
for @texts {
say if m:syntax/$search/;
}
}
> And there aren't that many regexish languages anyway.
That depends on how broadly you define regexish. Search is a *very* common
activity and people are (re-)inventing notations for it all the time.
Damian
Re: TAP as XML
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 something that _looks_ like a CPAN dist (directory layout, Makefile.PL etc) then it should work. And I'm hoping we can implement some math in the PITA::Report class too, so that you can just $Report1 += $Report2 to merge the two together. So in your case, you need Distribution::Harness + PITA::Report, and the rest is irrelevant. As for the schema, it's _potentially_ a little richer than you need, as it offers the chance for a smarter analyzer later on to re-evaluate the conclusions, but it does have all of the TAP output in raw form in it as well. Should be just what you need. Adam K Michael Peters wrote: Adam Kennedy wrote: Michael There's existing work happening in this area you may want to get involved in. We even have a draft XML schema that does exactly what you are talking about. Go read http://ali.as/pita/ Definitely an interesting project. It is much wider in scope than my little idea. There are a couple of reasons that I think might make it too much, or too different from what I'm trying to do (at least initially). While I want to test module packages I would also like to test whole applications. I don't want the developers to have to do anything special with their dev machines, or smoke machines, just send their reports to my app. This makes it a lot simpler. But I am interested in the XML schema that you have so far. Is it tied heavily to PITA, or mainly focused around the data output from TAP tests?
[perl #37730] [PATCH] Test::Builder
# 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, bring it up to the latest calling conventions, fix a couple code formatting details, and make it more pir-friendly. also in the patch is a test file for Test::Builder's basic operations (that's how i found the bugs.) the test file includes tests for the public methods, as well as loading the bytecode, isa, and can. incedentally, these are three tests i'd like to have in the pir framework under development (load_bytecode_ok, isa_ok, can_ok.-- along with load_library_ok, include_ok, does_ok, is, isnt, and the like would make for a mighty good test module.) i marked some tests as todo, as i'm not sure Test::Builder is responding correctly to the input i've given it. since this is chromatic's module, i don't want to step on his toes by checking it in. i'll keep it here for review, and if there's no negative feedback, i'll commit it in a few days. ~jerry test_builder.patch Description: Binary data
Re: type sigils redux, and new unary ^ operator
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
> way.
Huh? Are you saying that 0..^5 is one more character than ^5?
In any case, I'm not sure that this unary helps readability, or that I
like it all that much, but I can say that it's damned useful. I use
ranges of the form 0..$n-1 more than any other range, by a very long
shot.
> To me, ^ indicates XOR, so unary ^ should really be the bit-flip
> of the operand.
Except in Perl 6, XOR is spelled +^ or ~^, and ^ is Junctive one().
So it seems that ^$x should be one($x). But that's an entirely
useless, trivial junction, so it makes sense to steal the syntax for
something else.
Luke
Re: :syntax (was: \x{123a 123b 123c})
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! ;-) Luke
Re: DynLexPad
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 hopefully has registered the HLL name along with it's types. No further .HLL directives are needed for the user of such code. leo
Re: :syntax
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 readability if there were only one standard modifier that subsumed all future possibilities. Damian
Re: Curses and parrot problems?
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, but under freebsd I get this. Running it inside gdb shows a bit more. But is not really helpful otherwise. Anyway I remember that I have seen a wrong function signature (or using wrong arguments) somewhere inside the ncurses NCI code. Please go through all the dlfunc ops and compare the signatures with the man page(s). Then check the calls of the functions for correctness. Joshua leo
Re: DynLexPad
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't have to remember to add > the second line whenever they use, e.g. Tcl... > > Seems like the cleanest thing to do is add a subclass for DynLexPad > (with no overrides) and map it in the PMC definition to LexPad. Why bother with an artifical subclass? You could choose an arbitrary Tcl PMC and do the mapping of DynLexPad to LexPad in the class_init of that arbitrary PMC. You wouldn't need another 'pmclass' keyword if you call Parrot_register_HLL_type. Regards, Roger Browne
Re: Perl 6 Summary for 2005-11-14 through 2005-11-21
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 doesn't work for example...
Destruction or finalization?
We don't have these two separated yet, but it wouldn't matter. Both can
only happen after the GC has decided that the object is unreferenced.
That is, if I have a filehandle I really
want to close at the end of a scope but I don't care when GC drags it
into the void, will the close happen even if there's introspection
somewhere?
*If* introspection sets the life bit ("increments refcount") of the
refered item(s) then destruction/finalization can only happen, after
that introspection object is also dead.
It's the same as: when you store a filehandle into an array, the
filehandle will be bound to the life period of that array.
The problem now is that there isn't any guarantee that such an
introspection PMC stays in that call frame, the function could just
return it to the caller (or store it into globals) as any other PMC.
Which implies that the whole call chain (with its contents) would have
to be kept alive.
-- c
leo
Lazy lists in Str context
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 S. Glock
Re: pdd20 and :outer
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)
print $P0
print "\n"
.end
.sub do_add3 :method
.param pmc arg
.const .Sub add3sub = 'add3'#(1)
.local pmc add3closure
add3closure = newclosure add3sub
#$P1 = self.add3sub(arg)#(2)
$P1 = self.add3closure(arg) #(3)
.return ($P1)
.end
.sub add3 :method :outer('do_add3')#(4)
.param pmc arg
$P0 = n_add arg, 3 #(5)
.return($P0)
.end
This segfaults at #(3). Possibly, I need to specify the FOO namespace at
#(1) and/or #(4). But how? It doesn't work to write 'FOO\0add3', for
example.
Now for the really strange thing: I can make this example work by doing
any one of several apparently-unrelated things:
- uncomment line #(2)
- remove the ":outer('do_add3')" part of line #(4)
- remove the .HLL declaration at the top of the program
- replace line #(5) by "$P0 = n_neg arg" (the significance
of this might be that 'n_neg' is redefined in the
Amber_INTEGER PMC - other operations are inherited
unchanged from the Integer PMC)
Does anyone have any ideas where I can look for clues?
Regards,
Roger Browne
Here's Leo's original example:
> .pragma n_operators 1 # add creates new PMC result below
> .sub do_add3
> .param pmc arg # looks nicer than get_params
> .lex '$a', arg
> .lex '&add3', $P1
> .const .Sub add3 = "add3"
> $P1 = newclosure add3
> $P2 = $P1()# tailcall eventually - b0rked
> .return ($P2)
> .end
>
> .sub add3 :anon :outer(do_add3) :lex
> $P0 = find_lex '$a'
> $P1 = $P0 + 3 # create/return new value
> .return ($P1)
> .end
>
> .sub main :main
> $P0 = do_add3(20)
> print $P0
> print "\n"
> $P1 = do_add3(21)
> print $P1
> print "\n"
> .end
>
implied looping (was: Re: type sigils redux, and new unary ^ operator)
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 pugs). With implied looping that
would be 10 lines, starting with two 0-lines.
--
Grtz, Ruud
Re: DynLexPad
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 developers so the users of the language don't have to remember to add the second line whenever they use, e.g. Tcl... Seems like the cleanest thing to do is add a subclass for DynLexPad (with no overrides) and map it in the PMC definition to LexPad. Why bother with an artifical subclass? You could choose an arbitrary Tcl PMC and do the mapping of DynLexPad to LexPad in the class_init of that arbitrary PMC. You wouldn't need another 'pmclass' keyword if you call Parrot_register_HLL_type. Mainly to avoid having the C code in my .pmc: I'd rather have a way to declare things in the PMC and have that generate code via pmc2c.pl. (Same reason I just added the hll/maps directives.) 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. Regards, Roger Browne
Re: DynLexPad
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 specify that? Roger
Re: pdd20 and :outer
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 MMD code. Fixed in r10150. Your
example works fine now, printing 23.
BTW I had to change (r10148) 2 amber PMCs to comply to c89.
leo
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
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 in
particular I've often desired a very short, but clear, way to say: "do
this #n times"- IIUC (Perl6 new rules for blocks/closures and
dereferencing) this is only one dot or even whitespace away from passing a
list into an anonymous sub. Which may be confusing after all...
The problem (if any!) does not persist for the postponed block form. But
as far as code like
^5 { do_it };
is concerned, it is even _too_ concise, and I'd prefer some additional
syntactical indication about what's going on. For my tastes,
^5: { do_it }; # But then also 5: { do_it }; [*]
would be perfect, were not the colon already taken for a bazillion other
uses...
OTOH if I remember correctly there should be (provision for) a C
variant that takes a closure and executes it over and over again.
[*] Or 5 -> { do_it }; but I strongly suspect this would interfere with
pointy subs.
Michele
--
I am a deeply religious nonbeliever.
This is a somewhat new kind of religion.
- Albert Einstein
Re: DynLexPad
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, 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 specify that? Roger
Re: :syntax
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 regex modifiers? > > Sure. But it'd lead to much less namespace pollution and much greater > readability if there were only one standard modifier that subsumed all future > possibilities. Okay, I don't think this is an important part of the design of the language, so I'll not fuss over it. However, I think it's a good case study that covers some important issues. Something I've learned from Haskell: if you have the following three things: * Fine-grained control over your lexical environment * A compiler that tells you when you're referring to something ambiguously, rather than just having one symbol hide the other * A way in all cases to refer to an export that you have *not* imported, using some fully-qualified form Then namespace pollution is not an issue... at all. I don't believe we have the last of those for regex modifiers. We should get it. Now, by grouping all these different modules under a standard :syntax, the following things follow: * The string has to be evaluated at compile-time; i.e. $syn = "vim"; rx:syntax($syn)/.../ is not legal. It takes a fair amount of maturity in the workings of Perl to understand why that doesn't work. * Various :syntax modifiers will probably do very different things inside the regex (one approach is not likely to work for everyone), so our common interface will add little to nothing over the standard modifier interface, other than another name to sift through in the docs. * We have to provide our own registry for these, which map strings onto implementations, rather than using the already existing symbol table. By reinventing this registry, we lose fully-qualified referrability to these symbols, which was one of the requirements for avoiding namespace pollution. It seems we've made that problem worse... but see below: :-) * The :syntax modifiers cannot take arguments, further worsening the namespace pollution problem rather than helping it. Or... if they can take arguments, it would be like this: :syntax['POSIX', :charclasses], which means reinventing the calling conventions already in place in much of the language (and losing some features in the process of reinventing, as usual), and losing any type information in the process. Also it's butt ugly. So... those have some strong language in there. I don't really want to go back and sugar them up, but pretend I did. Anyway, I think the biggest point is that when you substitute a string for a first-class object, you have to emulate (poorly) all the fancy mechanisms that the language designers have meticulously crafted. Luke
Re: DynLexPad
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 :immediate# (1) $P0 = loadlib 'dynlexpad' .end .HLL "foo", "" # or "foo_group" - load dynamic PMCs too .HLL_map .LexPad, .DynLexPad # (2) Roger leo
Re: type sigils redux, and new unary ^ operator
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
> > for something that is an additional character written the more legible
> > way.
>
> Huh? Are you saying that 0..^5 is one more character than ^5?
>
> In any case, I'm not sure that this unary helps readability, or that I
> like it all that much, but I can say that it's damned useful. I use
> ranges of the form 0..$n-1 more than any other range, by a very long
> shot.
>
> > To me, ^ indicates XOR, so unary ^ should really be the bit-flip
> > of the operand.
>
> Except in Perl 6, XOR is spelled +^ or ~^, and ^ is Junctive one().
> So it seems that ^$x should be one($x). But that's an entirely
> useless, trivial junction, so it makes sense to steal the syntax for
> something else.
I think using C< ..5 > to mean (0, 1, 2, 3, 4) would be a more
sensible option. Makes sense to me at least.
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: type sigils redux, and new unary ^ operator
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 something that is an additional character written the more legible
> > way.
>
> Huh? Are you saying that 0..^5 is one more character than ^5?
No, I'm saying that 0..$n-1 is one more character than 0..^$n. And, it
has the added benefit of being legible to people who don't know the
ins and outs of every single operator of the 60+ P6 looks like it will
have.
> In any case, I'm not sure that this unary helps readability, or that I
> like it all that much, but I can say that it's damned useful. I use
> ranges of the form 0..$n-1 more than any other range, by a very long
> shot.
I don't use 0..$n-1 very often. I use 0..$#arr most often. But,
frankly, I don't use ranges very much at all. I try to avoid parallel
arrays, which is really the only time I can see using a range like
that. I try and let the datastructure (IO handle, array, etc) control
when it's done.
> > To me, ^ indicates XOR, so unary ^ should really be the bit-flip
> > of the operand.
>
> Except in Perl 6, XOR is spelled +^ or ~^, and ^ is Junctive one().
> So it seems that ^$x should be one($x). But that's an entirely
> useless, trivial junction, so it makes sense to steal the syntax for
> something else.
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).
So, now, is it 0..one(@x) or [EMAIL PROTECTED]
Rob
Re: type sigils redux, and new unary ^ operator
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" and "0 .. 15". I have yet to discover the pattern in my decisions. foo .. bar # foo(..bar)? foo..bar? A similar thing occurs with unary single-dot, which is defined to be able to have whitespace on its LHS. foo .bar# foo.bar, not foo(.bar) Of course, the same rule could be used for .., but then for consistency, whitespace on its RHS would need to be disallowed. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
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, but [EMAIL PROTECTED] doesn't return an index. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Lazy lists in Str context
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 fail): > > say **(1..Inf); > > $s = substr( ~( **(1..Inf) ), 0, 10 ); This would work, I think, if ranges were convertable to iterators, stringification was lazy, and substr() informed the stringification of how much it needed to do. I'm not sure how feasible that last one is ... Rob
Re: implied looping
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","oo","bar")».chars
from S3 yet
(I assume it just ignores the hyper)
--
Grtz, Ruud
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
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) { say; say }
: d. @{0..4} { say; say }
: (etc.)
:
: b. now produces 2 lines with 01234 (in pugs).
Which is wrong by the current spec, by the way. It should be a syntax
error to have two terms in a row. Bare parens can't be function args
unless they're abutted or use ".".
: With implied looping that would be 10 lines, starting with two 0-lines.
I don't like that much deep magic without a keyword to clue the reader,
and we have plenty of keywords to work it already:
for ^5 { say }
^5.each { say }
(0..4).each ==> say
say for ^5;
I can see the mathematical appeal of coming up with a language in
which there is a meaning for every possible combination of tokens.
But there's an important linguistic principle here that I think has
never been adequately researched, and is probably worth a doctorate
to whoever does it. But it's a subtle principle, so it's rarely
mentioned. That principle is that there has to be some kind of
"self-clocking" aspect to a syntax, or you never realize if you've
gotten out of sync. In other words, there have to be some sequences
in the syntax that are syntax errors, or you'll never get any syntax
errors. That sounds like a tautalogy, but I don't mean it that way.
The self-clocking, phase-locked-loop aspect of Perl is driven by the
fact that we almost never allow two terms in a row, and also by the
fact that it's pretty easy to distinguish terms from operators most
of the time. This is what allows Perl to be a language that does,
in fact, overload leading characters between terms and operators
rather heavily. But if we allowed you to say "$foo %bar" and gave
it some meaning, you wouldn't be able to tell whether that % should
be a sigil or a modules operator.
And we also have to be careful about terms like {...} and (...) and
[...]. We've already made the exception that you can have {...} where
an operator is expected--that's exactly how the grammar recognizes
the difference between
for foo 1,2,3 {...}
and
for foo 1,2,3,{...},{...},{...} {...}
But it's easy enough to get tangled up with that exception, and if we
start making any sequence of bare brackets mean something, we'll not
get a syntax error but an unexpected successful parse, which can be
far more devastating than a syntax error.
However, in order to milk our bracketing characters for all they're
worth, as well as all the other operators, we finessed it in Perl 6
depending on the whitespace (or ".") so that we can tell which
operators are intended as postfix operators and which ones are
misplaced terms. And that's why
{say} (1)
has to be a syntax error, while
{say}(1)
{say}.(1)
are just function calls. We really have to make that rule, or people
will be very confused a very large amount of the time. And the worst
part of it is that they'll think it's because they're stupid, not
because the language is poorly designed. It's a counterintuitive fact
that languages that are too efficiently coded induce inefficiencies in
communication. We're already dancing on the brink of "too efficient",
and it would be easy to fall over the edge. Some would say we already
have...
Larry
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
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
Re: type sigils redux, and new unary ^ operator
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). : So, now, is it 0..one(@x) or [EMAIL PROTECTED] It's the latter, regardless of whether you visually parse it as 0 .. [EMAIL PROTECTED] 0 ..^ @x Perl parses it the latter way, of course, but the visual pun is part of why I wanted ^ to be short for 0..^. Larry
Re: type sigils redux, and new unary ^ operator
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 rather than ..5. Larry
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
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 we made an infix: operator of looser precedence:
^5 each { say }
Or we don't have infix:, so maybe
^5 do { say }
Larry
Re: DynLexPad
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 consequences of the metadata.
Hm. That was a little opaque. Let me try again. I almost always
prefer a declaration like (e.g.)
foo isa bar
over the executable equivalent such as (e.g.)
foo::class_init { copy_stuff_from('bar') }
You can always generate code from parseable data, but not vice versa.
Of course, if the code is formalized enough, you can treat it as data,
but that way lay either a black hole of hackery or Lisp.
Y'know, it's at times like this I envy the Lisp guys, who pulled off
the greatest scam in programming history: skipping the real language
and getting the programmers to write ASTs.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: Lazy lists in Str context
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 lazy list. It should iterate over that rather than output it all at once, anyway, for reasons of conserving memory. > to output an infinite stream, instead of just looping forever? How do you imagine anything outputs infinite stuff, without looping forever? I don't think stdout knows about our kind of laziness :) > OTOH, it would be nice if > say substr( ~(1..Inf), 0, 10 ) > printed "1 2 3 4 5". Here, 1..Inf is stringified as a whole, while with say, each of the individual elements of the list are separately stringified. The question of lazy strings is an interesting one. It would be very useful, and would also allow GREAT things like my $revfoo := reverse $foo; $revfoo ~~ s/foo/bar/g; I wonder if it's doable, though... Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: implied looping
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).each: { say }
unless we made an infix: operator of looser precedence:
^5 each { say }
Or we don't have infix:, so maybe
^5 do { say }
Well, or we go back to ^ beeing the kind sigil that, like $5 retrieves
matched data, captures some countably 5 numbers singly stepping
to result in the lazy list (0,1,2,3,4) with five elements
as ordered. I would call that 'five out of void' :)
Note that ^5[-1] obviously is 4. And also ^5[-5] == 0. Welcome to the
heart of cardinal numbers. Or was that a card attack? Perhaps we call
that idiom a cardiogram? Or cardiarray? Might sound funny, but is
running very deep! To the heart of Perl6 arrays, actually.
--
Re: type sigils redux, and new unary ^ operator
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 the same list.
I read ^5 as a range-list, like (in some mathematical notation) [0..5>
or [0..4].
Such a list can be stored as (start;count;step=1).
Yes, it could use a step:
^42.7 = (0, 7, 14, 21, 28, 35)
^42.-7 = (35, 28, 21, 14, 7, 0)
^-42.7 = (-35, -28, -21, -14, -7, 0)
^-42.-7 = (0, -7, -14, -21, -28, -35)
and (^-42.7 + ^42.7) has length 11, maybe better expressed as ^-42.7.42,
which makes '^5' the short way to write '^5.1.0'.
--
Grtz, Ruud
Re: type sigils redux, and new unary ^ operator
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
element plus one. It should not be used for index math.
There are cases where we should write @foo.last + 1, even though the
result will in almost all cases be the same as [EMAIL PROTECTED], and there are
cases where we should write @foo - 1, even though the result will be the
same as that of @foo.last.
That almost all arrays range from 0..i is no reason to write bad code.
> Maybe someone doing
> for ([EMAIL PROTECTED])->$i { say @foo[$i] }
That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
latter.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Subs may not contain dynamic call info, ever (was Re: r10151)
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 code is not OK, because the Parrot_sub structure has
information it can't have:
> +METHOD PMC* get_caller() {
> +struct Parrot_sub * sub = PMC_sub(SELF);
> +PMC* cont, *sub_pmc;
> +cont = sub->ctx->current_cont;
> +sub_pmc = PMC_cont(cont)->to_ctx->current_sub;
> +return sub_pmc ? sub_pmc : PMCNULL;
> +}
Parrot_sub must not have a ctx member. Parrot_sub must have no
members which reflect dynamic calls, because with recursion you can
guarantee that there's no one correct answer for any dynamic query on
a Sub. (Continuations just make it worse.)
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: type sigils redux, and new unary ^ operator
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 to use indexes, but [EMAIL PROTECTED] doesn't return an index. 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. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: type sigils redux, and new unary ^ operator
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 PROTECTED] returns the *number of elements*, not the index of the last
: element plus one. It should not be used for index math.
:
: There are cases where we should write @foo.last + 1, even though the
: result will in almost all cases be the same as [EMAIL PROTECTED], and there
are
: cases where we should write @foo - 1, even though the result will be the
: same as that of @foo.last.
:
: That almost all arrays range from 0..i is no reason to write bad code.
:
: > Maybe someone doing
: > for ([EMAIL PROTECTED])->$i { say @foo[$i] }
:
: That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
: latter.
I don't think that's a big problem. Formal arrays are allowed to view
all incoming array parameters as 0-based even if created elsewhere as
non-0-based arrays. Forcing everyone to use the same circumlocutions
because someone somewhere *might* use a non-0-based view of their
arrays is just falling back into one of those magical action at a
distance traps, I think. A non-0-based view is fine in a particular
lexical scope, but it shouldn't leak out.
Which means you can use [EMAIL PROTECTED] and know it's right in your lexical
scope.
Larry
Re: type sigils redux, and new unary ^ operator
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 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 mean %hash.keys. Flipping it the other way, does that argue that 5.keys means 0..4? Hmm. Doesn't do much for me. One of the other reasons I like ^5 is that the uparrowness of it naturally reads as "up to 5". But for containers we could certainly abstract it out to the domain. Larry
Re: type sigils redux, and new unary ^ operator
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 mean %hash.keys. Or maybe not. We need some way of getting the keys of just the first dimension, and maybe .keys is that, on the model of Perl 5, where all multidims are really XoX in form, and .keys only ever gives you the top level. Then ^%hash and %hash.keys would mean the same thing only for 1-dimensional hashes. Likewise for arrays. Larry
Re: Lazy lists in Str context
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 objects are supposed to *be* iterators, but pugs isn't there yet, last I checked. : stringification was lazy, and substr() informed the stringification of : how much it needed to do. I'm not sure how feasible that last one is : ... 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 set up some way of declaring "this particular string is lazy". 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. Larry
Re: type sigils redux, and new unary ^ operator
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: > > .. > ^.. > ..^ > ^..^ > > If the rule is "you can omit the 0", then it's ..^5 rather than ..5. 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). Regardless, my gut tells me that C< ^5 > is just a little too short for what it does. Also, I find the argument that people will type [EMAIL PROTECTED] and get confused fairly convincing. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Lazy lists in Str context
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 stringified as a whole. &say will have an array that represents > the lazy list. It should iterate over that rather than output it all at > once, anyway, for reasons of conserving memory. Ah, ok - but I believe that say() is slurpy, which means the list must be instantiated first. > > to output an infinite stream, instead of just looping forever? > > How do you imagine anything outputs infinite stuff, without looping > forever? I don't think stdout knows about our kind of laziness :) There are some reasons for this - you can see what's happening, and press ctrl-C; or you may wish for it to output until there is a timeout; or maybe you are writing a daemon which is supposed to run forever anyway. > > OTOH, it would be nice if > > say substr( ~(1..Inf), 0, 10 ) > > printed "1 2 3 4 5". > > Here, 1..Inf is stringified as a whole, while with say, each of the > individual elements of the list are separately stringified. The question > of lazy strings is an interesting one. It would be very useful, and > would also allow GREAT things like > > my $revfoo := reverse $foo; > $revfoo ~~ s/foo/bar/g; > > I wonder if it's doable, though... I believe it is - I've come to this idea while trying to write down the Array spec, and it seems pretty feasible. > Juerd Thanks! - Flavio
Re: Lazy lists in Str context
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 @, it cannot be copied, because that flattens in list context, which is provided by assignment to another @-thing. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Lazy lists in Str context
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 ranges are iterator objects. The hidden iterators of a * list are evaluated when the values are requested from the slurpy array. So say 1...; ought to produce lots of output without ever running out of memory. (In reality, iterators are allowed to produce their values in batches for efficiency, so there's a slight possibility that an iterator could exhaust memory while producing the next batch.) Larry
Re: type sigils redux, and new unary ^ operator
> "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 things. iota is an integer range generation operator which returned 1 .. N in monadic (prefix) mode and M .. N in dynadic (infix) mode. and ^ used to be a full up arrow with a shaft (teletypes) and that is vaguely similar to the iota char. but given larry's stretchable imagination i don't think this mnemonic would hurt anyone. you just need to know some computer history. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Lazy lists in Str context
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 want.
: $foo can't flatten in list context, which .. does want, which would be
: inconsistent,
If you say
$r = 1..10;
you are intentionally putting the range object in a place where you
have to explicitly iterate it, so in list context you'd have to say
for =$r { say }
: but with @, it cannot be copied, because that flattens in
: list context, which is provided by assignment to another @-thing.
It only flattens notionally as * lazy, which means if you say
@r = 1..10;
@s = @r;
the iterator doesn't have to be evaluated, but just passed along as
part of the .specs to the next array, presumably with COW so the two
arrays can then have the appearance of having flattened the iterator.
But it's all * magic, not ** magic.
Larry
Re: type sigils redux, and new unary ^ operator
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 any other use. : Regardless, my gut tells me that C< ^5 > is just a little too short : for what it does. I'd've felt the same way before I started revising S9, whereupon I discovered I wanted ^5 all over the place. It was either that or make special exceptions for lists containing one element, and that was gross. : Also, I find the argument that people will type : [EMAIL PROTECTED] and get confused fairly convincing. I dunno. I'm not confused by it, and I'm easily confused. Or maybe I'm just confused about not being confused... Larry
[OT] (was: Re: implied looping)
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 are too efficiently coded induce inefficiencies in > communication. Many of us will experience that every day, for example when telling somebody what to do and how to do it. > We're already dancing on the brink of "too efficient", > and it would be easy to fall over the edge. Some would say we already > have... I know some. As a coincidence I am working on a project in which we remove topping layers from texts, to deduce a (quite artificial) skeleton from each text. This to make it possible to find and define relations between the texts. We use the skeleton-format also to link to very different data, like to parts of scanned images of the same kind of texts, to sound bytes, etc. -- Grtz, Ruud
Re: pdd20 and :outer
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 (r10148) 2 amber PMCs to comply to c89. Thanks. I'm not a C expert, that's for sure. Leo's Perl/Python example is now working in Amber, and looks like this: print_line(do_add3(20)) print_line(do_add3(21)) f := mk_add3(39) print_line(f.call) f := mk_add3(40) print_line(f.call) private f do_add3(arg) local add3 := (agent outer arg do result := arg + 3 end) do result := add3.call end mk_add3(arg) do result := (agent outer arg do result := arg + 3 end) end end Regards, Roger Browne
Re: Lazy lists in Str context
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 set up some way of declaring > "this particular string is lazy". > > 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. 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 = substr( [~](1..Inf), 10 ); my $revfoo := reverse $foo; $revfoo ~~ s/foo/bar/g; - Flavio S. Glock
Re: type sigils redux, and new unary ^ operator
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
>
> for ^5 { say } # 0, 1, 2, 3, 4
It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n.
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?
--
Peter Scott
Re: type sigils redux, and new unary ^ operator
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 operator in revising S09. It also makes it easy to
: > write
: >
: > for ^5 { say } # 0, 1, 2, 3, 4
:
: 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'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 occur to me offhand. First we're doing away with $#foo.
Second is all the array sizing in P5 is implicit, whereas S9 style
arrays are all about explicit array sizing, and 0..$n-1 comes up all
the time there. But I also am liking the generalization of unary ^
to mean domain.
And in an axiomatic sort of way, it corresponds to those theories
of math that build up the integers by counting set elements. The
"argument" that produces 5 is 0..4. And it works out that +^5 == 5.
But the generalization to hashes is even cooler because I can say
my %thishash{^%thathash};
or some such to duplicate the "shape" regardless of the typology
of %thathash.
Larry
Re: Subs may not contain dynamic call info, ever (was Re: r10151)
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 dynamic field 'ctx' - yes.
Like I've said (repeatedly :-)), rule #1 of call info is:
Subs don't have callers.
Call frames have callers.
And callframes aren't PMCs (because we don't have weak pointers)
therefore an introspection of :outer can only return the 'Sub' of outer
but not actually the real call frame aka the context ...
The introspection $frame.get_lexpad (pdd20) can't be implemented w/o
that currently.
outer_sub - (the static sub PMC info) can't refer to :outer because the
:outer can be a closure too. There are many incarnations of the :outer
then. Therefore the implementation needs sub->ctx (currently and IMHO).
Therefore, this code is not OK, because the Parrot_sub structure has
information it can't have:
+METHOD PMC* get_caller() {
It returns the sub PMC of the caller, which is rather useless for the
one case of recursive subs - yes.
There is still the interpreter based interface, so I can just remove
this code - np.
Parrot_sub must not have a ctx member.
Ack all, but how do I implement this then:
me = interpinfo .INTERPINFO_CURRENT_SUB
outer = me."get_outer"()
pad = outer."get_lexpad"()
leo
Re: [svn ci] Perl 5 tests for PGE::P5Regexp (update)
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 refactored, and is much less ugly now. the refactoring has allowed me to expand on the ability to parse perl match result vars like '$&', '$-[4]', '$1', etc. and that has allowed me to include even more of the 960 perl 5 tests, in fact, 800 of them. the final 160 are skipped by the harness because there are too many of them which cause parrot to crash, so i'll wait until the bugs are fixed before enabling those tests. of the 800 tests the harness cares about, i decided to skip 290 tests; those which are designed to produce errors, expose perl bugs, those with syntax PGE doesn't understand (e.g. trailing modifiers,) and those which cause parrot to devour system resources just as vonnegut's Ice-Nine enveloped the earth. failing tests (there are approximately 155 of them) are currently marked todo, to prevent noise in parrot's test harness from PGE::P5Regexp, which is far from complete. i'm much happier seeing unexpected success messages rather than expected failures during development, so this should be the norm in the test suite. subtracting the skipped and todo tests from the total leaves about 360 passing tests from perl 5's test suite. thanks to patrick's work on PGE and P5Regexp, we now have a perl 5 regular expression parser capable of handling things like 'a:[b]:' =~ /([[:]+)/ nice work, patrick. ~jerry
Re: type sigils redux, and new unary ^ operator
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 expression.
| :
| : [EMAIL PROTECTED] returns the *number of elements*, not the index of the
last
| : element plus one. It should not be used for index math.
| :
| : There are cases where we should write @foo.last + 1, even though the
| : result will in almost all cases be the same as [EMAIL PROTECTED], and there
are
| : cases where we should write @foo - 1, even though the result will be the
| : same as that of @foo.last.
| :
| : That almost all arrays range from 0..i is no reason to write bad code.
| :
| : > Maybe someone doing
| : > for ([EMAIL PROTECTED])->$i { say @foo[$i] }
| :
| : That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
| : latter.
|
| I don't think that's a big problem. Formal arrays are allowed to view
| all incoming array parameters as 0-based even if created elsewhere as
| non-0-based arrays. Forcing everyone to use the same circumlocutions
| because someone somewhere *might* use a non-0-based view of their
| arrays is just falling back into one of those magical action at a
| distance traps, I think. A non-0-based view is fine in a particular
| lexical scope, but it shouldn't leak out.
|
| Which means you can use [EMAIL PROTECTED] and know it's right in your lexical
| scope.
What about array with holes as supported by Parrot?
Does .elems return the number of elements with or without
the holes?
Does iterating over the array iterates over the holes as well?
That would sound inefficient to do that over a mostly empty array.
Related question, Is there a way to get a list of iterators
that iterate only over the non-holey parts of an array?
--
cognominal stef
|
| Larry
|
Re: type sigils redux, and new unary ^ operator
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 is that this shortcut hurts clarity. It's almost as if a purpose was sought for the available ^, rather than there is something that will be used a lot, that needs a shortcut. Personally, I think even ^.., ^..^ and ..^ are too much, but that I can live with. > Couple reasons occur to me offhand. First we're doing away with $#foo. Yea, and there's @foo.last to replace it. Indexes and numbers (counts) just aren't the same thing, and I think source code should communicate meaning using the right words. The word for "the last index" is .last, that of "the number of elements" is .elems, or [EMAIL PROTECTED] If you need the last index, plus one, you shouldn't use the number of elements, and if you need the number of elements, minus one, you shouldn't use the last index. Am I the only one who cares about this distinction? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
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 to be interpreted implying anything :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: pdd20 and :outer
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 old bug, or more
> precisely, a consequence of how Perl 5 implements capturing a lexical
> environment. It's just bad. Don't even try supporting it.
As the current "owner" of the perl5 closure code, (and as someone who
hasn't been following this thread :-( ), I'm interested to know what the
p6 semantics of this are. The p5 semantics seem to me to be logical and
consistent, if not particularly useful in this case: ie subs capture their
outside lexical scope at the time they are created. So at compile time,
add3() captures the first instance of do_add3()'s $a and hangs onto it for
dear life.
In p6, will $a remain shared between the two subs? In which case, at what
point is $a considered to have gone out of, or come into scope, from the
perspective of creating and destroying instances of lexicals variables?
Dave
--
Monto Blanco... scorchio!
Punie to AST
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 the match result into an AST tree, and dumps the tree in a text format for verification. This is named punie2.pir, because it's still not far enough along to replace punie.pir. If you want to play with it, run it in languages/punie as: parrot punie2.pir demo.p1 The current set of PAST node types is inspired by Pugs' PIL, but has some significant differences. Allison
Re: Lazy lists in Str context
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 = substr( [~](1..Inf), 10 );
> my $revfoo := reverse $foo;
> $revfoo ~~ s/foo/bar/g;
That would violate the principle of least surprise. If all scalars
are, by default, eager, then:
foo( [EMAIL PROTECTED] );
foo( @list.join('') );
could potentially do different things, including possibly run out of
memory in some cases. Plus, what if the @list isn't lazy?
Better, I think, would be:
say substr( ~(1..Inf) is lazy, 0, 10 );
Or, have substr()'s signature be:
sub substr( Str $str is rw is lazy, Int $start, Int $?end, Int $?replacement );
Rob
Re: type sigils redux, and new unary ^ operator
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 occur to me offhand. First we're doing away with $#foo.
> Second is all the array sizing in P5 is implicit, whereas S9 style
> arrays are all about explicit array sizing, and 0..$n-1 comes up all
> the time there. But I also am liking the generalization of unary ^
> to mean domain.
What about @array.indices instead? Then, there's no possible
fenceposting, your code is self-documenting, and we're not introducing
another unary operator?
> And in an axiomatic sort of way, it corresponds to those theories
> of math that build up the integers by counting set elements. The
> "argument" that produces 5 is 0..4. And it works out that +^5 == 5.
So, +^5 is the way to generate the Church number for 5 through the use
of an iterator masquerading as a range?
> But the generalization to hashes is even cooler because I can say
>
> my %thishash{^%thathash};
>
> or some such to duplicate the "shape" regardless of the typology
> of %thathash.
my %thishash{%thathash.keys};
Much easier to read. The methods are there for a reason. Don't re-add
operators where there's a perfectly good method. Plus, overwriting
methods is much easier to grok for the average programmer than the
corresponding operator, unless you're aliasing the operator, in which
case I have problems figuring out why this is good, unless we're
deliberately designing P6 for the obfu/golf crowd.
Re: Lexical store semantics - Q for Tcl guys
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 a lexical variable > instead of using the assign opcode, which breaks things like [global]. I fixed this tonight in r10164. (And added a test.) -- matt diephouse http://matt.diephouse.com
Re: Lazy lists in Str context
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. Having a
lazy string to me is much like:
my @a = 1...;
my $b = [EMAIL PROTECTED];
Scalar context is strict, but that doesn't necessitate strict
evaluation the whole way down. The scalar context in that example is
saying "evaluate the reference *now*", not the list.
The kind of lazy string that would be affected by scalar context is:
my $str = do { say "hi there"; "foo" };
say "intermediate";
say $str;
If scalar context were lazy, it would say "hi there" *after*
"intermediate" (but before "foo", of course).
But we're talking about a string with a lazy internal representation,
like a reference to a lazy list. That's perfectly okay to pass around
in scalar context. And I think it's perfectly okay to have
stringification return this kind of lazy string.
Luke
Re: Subs may not contain dynamic call info, ever (was Re: r10151)
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 least one in runtime/parrot/library/Stream/Writer.imc is bogus if
not illegal:
.const .Sub stub = "_reader_stub"
setprop stub, "CALL", source
What should we do WRT e.g. setprop:
- disallow it at all for .Sub PMCs (it would be ok for .Closures,
because these are distinct)
- only allow it for 'clone'ed subroutine PMCs
...
See also src/packfile.c:3200 and :377. The latter ('mark_1_seg') is run
from GC to keep PMC 'constants' alive and I really don't like this. If
PMC constants are created in the constant PMC pool, DOD-marking isn't
needed anymore.
leo
