[perl #59244] [TODO] Implement infix: for Pairs
# New Ticket Created by Moritz Lenz # Please include the string: [perl #59244] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59244 > %hash.pairs.sort needs infix: to work properly with Pair as input. It should be easy to add a multi that does this by first comparing the key, and if they are equal the value. When this is done most (or all) of the skip markers in t/spec/S29-hash/pairs.t can (hopefully) be removed. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Split with negative limits, and other weirdnesses
On Tue, Sep 23, 2008 at 9:38 AM, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
> Moritz Lenz wrote:
>
>> In Perl 5 a negative limit means "unlimited", which we don't have to do
>> because we have the Whatever star.
>>
>
> I like the notion of negative numbers as the other end of infinity.
> Where infinity here is the length of the split list which can be
> infinite if split is called on a file handle. So a negative number
> could be the number of splits to skip from the front of the list.
> And limits of the form '*-5' would deliver the five last splits.
>
As another data point, this is the first thing I thought of when I read the
email regarding negative limits. But then I thought "we're trying to get
away from so much implicit magic". And I'm not sure the failure mode is loud
enough when the skip-from-the-front semantics /aren't/ what you want (e.g.,
when the limit parameter is variable-ish)
A limit of 0 is basically ignored.
>
> Here are a few solution I could think of
> 1) A limit of 0 returns the empty list (you want zero items, you get them)
>
I think this is a nice degenerate case.
>
Me too.
2) A limit of 0 fail()s
>
This is a bit too drastic.
Indeed.
3) non-positive $limit arguments are rejected by the signature (Int
> where { $_ > 0 })
>
I think that documents and enforces the common case best. But I would
> include zero and use a name like UInt that has other uses as well. Are
> there pragmas that turn signature failures into undef return values?
>
>
> Regards, TSa.
> --
>
> "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
> "Simplicity does not precede complexity, but follows it." -- A.J. Perlis
> 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
>
my two cents,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: [perl #59240] Automate publishing of docs/*
Ahh, cool I didn't even know we had parrot.org. Publishing docs/book/* would be nice. On Tue, Sep 23, 2008 at 10:27 PM, Will Coleda via RT <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 9:04 AM, via RT Chris Davaz > <[EMAIL PROTECTED]> wrote: >> # New Ticket Created by "Chris Davaz" >> # Please include the string: [perl #59240] >> # in the subject line of all future correspondence about this issue. >> # http://rt.perl.org/rt3/Ticket/Display.html?id=59240 > >> >> >> I suggest we automate the publishing of everything under docs/* and >> putting it under parrotcode.org/docs in HTML format for easy access. >> This would probably help productivity and maybe even attract new >> developers. >> >> Just my two cents... >> > > we're moving to http://www.parrot.org/ ; I think Allison has said > we're going to automate this publishing process. > > In the meantime, most of the docs on parrotcode.org update > automatically once a link is put up; we can, in the meantime, add some > more if there are some particular docs you'd like to see. > > > -- > Will "Coke" Coleda > > >
[perl #57728] [TODO] avoid 2038 bug if we haven't already.
On Thu Aug 07 14:20:11 2008, coke wrote: > Open a ticket for TODO item. > > -- Forwarded message -- > From: jerry gay <[EMAIL PROTECTED]> > Date: Thu, Aug 7, 2008 at 4:34 PM > Subject: Re: time op inconsistent on Win32 > To: Ron Blaschke <[EMAIL PROTECTED]> > Cc: Jonathan Worthington <[EMAIL PROTECTED]>, p2 <[EMAIL PROTECTED]> > > we definitely need date/time pmc(s?) not only to have a common epoch > across platforms, but to deal with 2038. in particular, we should > leverage schwern's work on perl to address the 2038 bug. > ~jerry We definitely haven't already fixed this. Here's an easy test using libfaketime: $ cat time.pir .sub main :main .local int time_int time time_int say time_int .end $ ./parrot time.pir 113121 $ LD_PRELOAD=/usr/src/libfaketime-0.8/libfaketime.so.1 FAKETIME="+40y" ./parrot time.pir -1811314167
[perl #46677] [TODO] [C] Merge fixedbooleanarray.pmc with functions from BigInt PMC
On Mon Oct 22 09:47:52 2007, pcoch wrote: > In src/pmc/fixedbooleanarray.pmc there is the todo item; > > * TODO merge this with functions from BigInt PMC > > The functionality in this file should be merged with that in the BigInt PMC I propose to reject this ticket. Reducing code duplication is a good idea, but it's not at all clear to me what this ticket is referring to. If someone cares to point out what code should be merged, great. Otherwise this ticket is too vague to be useful. Christoph
Re: [perl #57728] [TODO] avoid 2038 bug if we haven't already.
>> we definitely need date/time pmc(s?) not only to have a common epoch >> across platforms, but to deal with 2038. in particular, we should >> leverage schwern's work on perl to address the 2038 bug. >> ~jerry > > We definitely haven't already fixed this. Here's an easy test using > libfaketime: > > $ cat time.pir > .sub main :main >.local int time_int >time time_int >say time_int > .end > $ ./parrot time.pir > 113121 > $ LD_PRELOAD=/usr/src/libfaketime-0.8/libfaketime.so.1 FAKETIME="+40y" > ./parrot time.pir > -1811314167 We can't make this example work. If you use an INTVAL, and the INTVAL can be signed 32 bits, there is no way to have a more than 31 bits unsigned stored on it as such. -- Salu2
Re: Revisiting lexicals, part 1
Patrick R. Michaud a écrit :
I've put together a draft with my ideas and design for
(re-)implementing lexicals in Parrot -- now available at
http://www.pmichaud.com/perl6/lexical.txt .
It's a first draft and might be a bit confusing in places,
but overall I think it's a far cleaner design than the
current implementation but also handles the vast bulk of
what we need (or can be made to do so easily).
Anyway, comments greatly appreciated.
Currently, the bigger issue in Lua on Parrot is lexical or upvalue in
Lua jargon (the reason for Lua on Parrot is not really Lua).
The following Lua code doesn't give the expected result (from
languages/lua/t/closure.t) :
a = {}
local x = 20
for i=1,10 do
local y = 0
a[i] = function () y=y+1; return x+y end
end
print(a[1]())
print(a[1]())
print(a[2]())
--[[
The loop creates ten closures (that is, ten instances of
the anonymous function). Each of these closures uses
a different y variable, while all of them share the same x.
]]
With the current Parrot, I never found a way to do it.
So, I'll be happy if this revisiting handles this issue.
François.
Pm
Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.
NotFound wrote:
Patches to bigint, complex, float and string applied in r31370, thanks.
Thanks. There is little bit more patches.
Just replacing most obvious calls.
--
Bacek
diff --git a/src/pmc/bigint.pmc b/src/pmc/bigint.pmc
index 0c00f18..b94d513 100644
--- a/src/pmc/bigint.pmc
+++ b/src/pmc/bigint.pmc
@@ -770,7 +770,7 @@ MMD_BigInt: {
bigint_add_bigint(INTERP, SELF, value, SELF);
}
MMD_Integer: {
-bigint_add_bigint_int(INTERP, SELF, PMC_int_val(value), SELF);
+bigint_add_bigint_int(INTERP, SELF, VTABLE_get_integer(INTERP, value), SELF);
}
MMD_DEFAULT: {
Parrot_ex_throw_from_c_args(INTERP, NULL,
@@ -828,7 +828,7 @@ MMD_BigInt: {
bigint_sub_bigint(INTERP, SELF, value, SELF);
}
MMD_Integer: {
-bigint_sub_bigint_int(INTERP, SELF, PMC_int_val(value), SELF);
+bigint_sub_bigint_int(INTERP, SELF, VTABLE_get_integer(INTERP, value), SELF);
}
MMD_DEFAULT: {
Parrot_ex_throw_from_c_args(INTERP, NULL,
diff --git a/src/pmc/env.pmc b/src/pmc/env.pmc
index 0655637..fcf3bd5 100644
--- a/src/pmc/env.pmc
+++ b/src/pmc/env.pmc
@@ -146,11 +146,12 @@ Returns the Parrot string value for the environment variable C<*key>.
VTABLE STRING *get_string_keyed(PMC *key) {
if ((PObj_get_FLAGS(key) & KEY_type_FLAGS) == KEY_integer_FLAG) {
-if (PMC_int_val(key) < 0 || PMC_int_val(key) >= SELF.elements()) {
+if (VTABLE_get_integer(INTERP, key) < 0
+|| VTABLE_get_integer(INTERP, key) >= SELF.elements()) {
return CONST_STRING(interp, "");
}
else {
-const char * const envp = environ[PMC_int_val(key)];
+const char * const envp = environ[VTABLE_get_integer(INTERP, key)];
const char * const p= strchr(envp, '=');
return string_from_cstring(interp, envp, (INTVAL)(p - envp));
}
diff --git a/src/pmc/integer.pmc b/src/pmc/integer.pmc
index d57d218..5985e34 100644
--- a/src/pmc/integer.pmc
+++ b/src/pmc/integer.pmc
@@ -415,7 +415,7 @@ MMD_Complex: {
}
MMD_DEFAULT: {
VTABLE_set_number_native(INTERP, SELF,
-PMC_int_val(SELF) + VTABLE_get_number(INTERP, value));
+SELF.get_integer() + VTABLE_get_number(INTERP, value));
}
}
Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.
> Thanks. There is little bit more patches. Applied in r31381, with some changes in the env.pmc part to avoid repeated calls. -- Salu2
Re: Revisiting lexicals, part 1
On Wed, Sep 24, 2008 at 12:09:37PM +0200, François Perrad wrote:
> Currently, the bigger issue in Lua on Parrot is lexical or upvalue in
> Lua jargon (the reason for Lua on Parrot is not really Lua).
> The following Lua code doesn't give the expected result (from
> languages/lua/t/closure.t) :
> a = {}
> local x = 20
> for i=1,10 do
> local y = 0
> a[i] = function () y=y+1; return x+y end
> end
>
> print(a[1]())
> print(a[1]())
> print(a[2]())
>
> --[[
> The loop creates ten closures (that is, ten instances of
> the anonymous function). Each of these closures uses
> a different y variable, while all of them share the same x.
> ]]
>
>
> With the current Parrot, I never found a way to do it.
>
> So, I'll be happy if this revisiting handles this issue.
Here's how I would expect this to look in PIR under the
new scheme (I'm not familiar with Lua, but I'm assuming 'local'
in Lua means 'lexical', and that the loop variable is lexical):
.sub 'main'
## set outer context of forbody_block
.const .Sub forbody = 'forbody_block'
capture_lex forbody
## a = {}
.local pmc a
a = new 'ResizablePMCArray'
store_global 'a', a
## local x = 20
.local pmc x
x = new 'Integer'
x = 20
.lex 'x', x
## for i = 1,10 do
.local pmc i
i = new 'Integer'
.lex 'i', i
for_loop:
if i > 10 goto for_done
forbody()
inc i
goto for_loop
for_done:
## print(a[1]())
$P0 = a[1]
$P1 = $P0()
say $P1
## ...
.end
.sub 'forbody_block' :outer('main')
## set outer context of lambda_block
.const .Sub lambda = 'lambda_block'
capture_lex lambda
## local y = 0
.local pmc y
y = new 'Integer'
y = 0
.lex 'y', y
## a[i] = function () y = y+1; return x+y; end
.local pmc a,i
a = get_global 'a'
i = find_lex 'i'
$P0 = clone lambda ## this creates the closure
a[i] = $P0
.end
.sub 'lambda_block' :outer('forbody_block')
## y = y + 1;
.local pmc y
y = find_lex 'y'
n_add $P0, y, 1
copy y, $P0
## return x+y;
.local pmc x
x = find_lex 'x'
n_add $P1, x,y
.return ($P1)
.end
Pm
[perl #50908] [CAGE] gcc -Werror=declaration-after-statement
On Mon Feb 18 18:07:43 2008, coke wrote: > On Feb 18, 2008 8:39 PM, chromatic <[EMAIL PROTECTED]> wrote: > > On Friday 15 February 2008 11:35:04 Will Coleda wrote: > > > > > According to http://gcc.gnu.org/onlinedocs/index.html#DIR, looks like > > > as of gcc 4.2.3 (but not 4.1.2), we can use the following option to > > > gcc: > > > > > > -Werror=declaration-after-statement > > > > > > To help enforce our C89 compliance by causing this particular style to > > > become an error instead of just a warning. This should be added as a > > > default to the build options if a recent enough version of gcc is > > > available. > > > > Works for me with gcc 4.1.3; I think this is closeable. > > > > -- c > > > > > > It's not checked in anywhere, though. We're just using > > -Wdeclaration-after-statement > > not > > -Werror=declaration-after-statement > Parrot builds with gcc 4.3.1 just fine when -Werror=declaration-after-statement is added after -Wdeclearation-after-statement in config/auto/warnings.pm . The option shows up in the generated Makefile and in the gcc invocation that's used. Adding this line with a gcc that doesn't support -Werror=declaration-after-statement doesn't cause any problems. It looks like this can safely be integrated into the build process. Once such a change is committed, this ticket can be closed. I'll do this tonight if nobody beats me to it.
Re: Revisiting lexicals, part 1
One of parrot current limitation is that eval is always a closure. When using rakudo interactively, one want to introduce new lexical variable that are not lost when accessing them from the next prompt. Pugs gets that right. My take on the subject 8 years ago! I don't know how that interacts with your new scheme. I just want you to know that constraint. -- cognominal stef
Re: Revisiting lexicals, part 1
On Tue, Sep 23, 2008 at 03:45:37AM -0500, Patrick R. Michaud wrote: > I've put together a draft with my ideas and design for > (re-)implementing lexicals in Parrot -- now available at > http://www.pmichaud.com/perl6/lexical.txt . Earlier today chromatic asked about recursion in the new design, so I've now updated the document with a section illustrating how recursion works. It's still at the same location. Pm
Re: Revisiting lexicals, part 1
On Wed, Sep 24, 2008 at 10:05:25PM +0200, Stéphane Payrard wrote:
> One of parrot current limitation is that eval is always a closure.
> When using rakudo interactively, one want to introduce new
> lexical variable that are not lost when accessing them from the
> next prompt.
> Pugs gets that right.
I would like to make sure we distinguish 'eval' from
'interactive prompt' -- they're probably not the same.
AFAICT while Perl 6's C function is able to access lexical
variables in the scope where it is used, it's not necessarily
able to create new ones in that scope. In other words:
{
eval 'my $x = 4'
say $x; # compile-time failure, $x doesn't exist
}
{
eval 'my $x = 4';
eval 'say $x'; # run-time failure, $x doesn't exist
}
I think this is most consistent with the statements in S02:1780, that
seem to indicate that lexical symbol tables are currently fixed at
compile time:
You may not use any lexically scoped symbol table, either by name or
by reference, to add symbols to a lexical scope that is done compiling.
(We reserve the right to relax this if it turns out to be useful though.)
So, in order to get the behavior you're describing from the interactive
prompt, we'll probably need more than just Perl 6's 'eval'. In
particular, the interactive prompt mode will need to be able to
maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have
some way of extracting any lexical changes from whatever code string
it evaluates.
At any rate, even though I don't discuss DynLexPad's in the new design,
I'm confident that it will be far easier to accommodate and use them
than the one that exists now, and to be able to achieve the
'interactive mode' semantics you've described above.
Pm
Re: Why no "is ro"? (Re: Subroutine parameter with trait and default.)
On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote: David Green wrote: Happily, brevity often aids clarity. The rest of the time, it should be up to one's editor; any editor worth its salt ought to easily auto-complete "ro" into "readonly". Eeep! The "your IDE should write your verbose code for you" argument! For that one, I brine and roast an adorable hamster. Fair enough. As long as you remember to share with the rest of us!! That's just another way of saying that your language is too verbose for a human to write it without hanging themselves. See also Java. But the problem with Java isn't just that it's too verbose to write; it's that it's too verbose to read, too. Why shouldn't your editor help with verbosity? The amount of typing shouldn't be a main concern in language design, because your editor can mostly compensate for that; there are other, better reasons to decide how verbose something should be. Anyhow, I see where you're going, and I understand the desire for no abbvs. But man, "ro" is pretty damn easy to remember. [1] This is even sillier when you hold it up against all the magic symbols we're supposed to remember. [EMAIL PROTECTED], :name, |$arg, $arg!, $arg?, : $arg. As a bear of limited recall, I sometimes feel a bit overwhelmed by all the stuff there is to remember. I'm certainly not against all abbreviations. I have a deeply ingrained instinct to name my variables x, y, and z, and to name files... x, y, and z. My shell profile is full of one-letter aliases (I don't have time to waste typing 2-char command names!). However experience has taught me the value of more robust names for anything but one-liners. I bet we actually don't disagree much; I'm not really against "ro" -- I'm just not against "readonly" because of its length. If I were writing casually, I'd use "rw" and "ro"; formally, I'd use "read only" and "read/write" (or even "readable and writable"). At an in-between level, which is where I believe we should be aiming, I think I'd put "rw" and "read-only". I'm not entirely sure why. Maybe psychologically, "ro" looks like it could be a word, whereas the unpronounceable "rw" has to be an abbreviation? Or maybe it's just because I see "rw" every day in ls output, but "ro" not so much. At any rate, if I wanted to argue in favour of "ro", I think symmetry (which you already mentioned) is the strongest argument. You're only a beginner once, and if everything is done right for a short time. The rest of your career, you're experienced. Ooh, now that I completely agree with! Software that thinks "user- friendly" means "dumbed-down" drives me nuts. -David
Re: Revisiting lexicals, part 1
2008/9/24 Patrick R. Michaud <[EMAIL PROTECTED]>: > So, in order to get the behavior you're describing from the interactive > prompt, we'll probably need more than just Perl 6's 'eval'. In > particular, the interactive prompt mode will need to be able to > maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have > some way of extracting any lexical changes from whatever code string > it evaluates. I wouldn't call them DynLexPad or lexicals at all, I would call them just globals. lexvars could shadow them though, but this a user problem then. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: Revisiting lexicals, part 1
On Thu, Sep 25, 2008 at 12:10:35AM +0200, Reini Urban wrote: > 2008/9/24 Patrick R. Michaud <[EMAIL PROTECTED]>: > > So, in order to get the behavior you're describing from the interactive > > prompt, we'll probably need more than just Perl 6's 'eval'. In > > particular, the interactive prompt mode will need to be able to > > maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have > > some way of extracting any lexical changes from whatever code string > > it evaluates. > > I wouldn't call them DynLexPad or lexicals at all, I would call them > just globals. lexvars could shadow them though, but this a user > problem then. This approach might expose some rough edges, though -- things like MY::, OUTER::, *::, etc. might not work as expected, or those constructs would have to know when they're dealing with "interactive mode pseudo-lexical-globals" instead of what the rest of the system is using. Still, we might consider something along these lines -- perhaps as a stopgap approach if nothing else. Pm
Re: Why no "is ro"? (Re: Subroutine parameter with trait and default.)
On 2008 Sep 24, at 17:45, David Green wrote: On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote: David Green wrote: Happily, brevity often aids clarity. The rest of the time, it should be up to one's editor; any editor worth its salt ought to easily auto-complete "ro" into "readonly". Eeep! The "your IDE should write your verbose code for you" argument! For that one, I brine and roast an adorable hamster. Fair enough. As long as you remember to share with the rest of us!! I would argue that if you need your editor to expand verbose language constructs to make the language usable or to express common idioms, then the language has a design deficiency. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: [svn:parrot] r31385 - trunk/docs/book
On Wednesday 24 September 2008 11:22:22 [EMAIL PROTECTED] wrote: > Modified: >trunk/docs/book/ch04_pir_subroutines.pod >trunk/docs/book/ch09_hlls.pod > > Log: > [Book] Add some basic info about VTables and HLL namespaces. > > Modified: trunk/docs/book/ch04_pir_subroutines.pod > --- trunk/docs/book/ch04_pir_subroutines.pod (original) > +++ trunk/docs/book/ch04_pir_subroutines.pod Wed Sep 24 11:22:22 2008 > @@ -490,6 +490,63 @@ > > =head3 VTABLE Methods They're not really methods in any PIR or C sense though (I usually use the term "entry"), as they're not really inherited nor invoked through a dispatch scheme and they're stored elseways from methods on classes and PMCs, and I've never seen them spelled other than VTABLE in the source and vtable in discussion. Otherwise, the information here is correct. -- c
Re: Revisiting lexicals, part 1
On Wed, 2008-09-24 at 18:09 -0500, Patrick R. Michaud wrote: > On Thu, Sep 25, 2008 at 12:10:35AM +0200, Reini Urban wrote: > > 2008/9/24 Patrick R. Michaud <[EMAIL PROTECTED]>: > > > So, in order to get the behavior you're describing from the interactive > > > prompt, we'll probably need more than just Perl 6's 'eval'. In > > > particular, the interactive prompt mode will need to be able to > > > maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have > > > some way of extracting any lexical changes from whatever code string > > > it evaluates. > > > > I wouldn't call them DynLexPad or lexicals at all, I would call them > > just globals. lexvars could shadow them though, but this a user > > problem then. > > This approach might expose some rough edges, though -- things like > MY::, OUTER::, *::, etc. might not work as expected, or those > constructs would have to know when they're dealing with "interactive > mode pseudo-lexical-globals" instead of what the rest of the > system is using. > > Still, we might consider something along these lines -- perhaps > as a stopgap approach if nothing else. Don't we have to solve all this to get the Perl 6 debugger working anyway? (Aside from which, it would be useful to have this capability properly exposed, for writing shell-style UIs that can escape to raw Perl.) -'f
Re: [perl #59244] [TODO] Implement infix: for Pairs
On Tuesday 23 September 2008 09:35:05 Moritz Lenz wrote:
> %hash.pairs.sort needs infix: to work properly with Pair as input.
>
> It should be easy to add a multi that does this by first comparing the
> key, and if they are equal the value.
>
> When this is done most (or all) of the skip markers in
> t/spec/S29-hash/pairs.t can (hopefully) be removed.
Something like this?
-- c
=== src/builtins/cmp.pir
==
--- src/builtins/cmp.pir (revision 31423)
+++ src/builtins/cmp.pir (local)
@@ -140,7 +140,7 @@
.end
-.sub 'infix:cmp'
+.sub 'infix:cmp' :multi(_,_)
.param pmc a
.param pmc b
$I0 = cmp a, b
=== src/classes/Pair.pir
==
--- src/classes/Pair.pir (revision 31423)
+++ src/classes/Pair.pir (local)
@@ -93,7 +93,28 @@
.return $P0.'new'('key'=>key, 'value'=>value)
.end
+.sub 'infix:cmp' :multi(Pair, Pair)
+.param pmc a
+.param pmc b
+.local pmc a_key
+.local pmc b_key
+a_key = a.'key'()
+b_key = b.'key'()
+$P0 = 'infix:'(a_key, b_key)
+unless $P0 goto compare_values
+.return( $P0 )
+
+ compare_values:
+.local pmc a_value
+.local pmc b_value
+a_value = a.'value'()
+b_value = b.'value'()
+$P0 = 'infix:'(a_value, b_value)
+.return ($P0)
+.end
+
+
=back
=cut
Re: [svn:parrot] r31385 - trunk/docs/book
On Wed, Sep 24, 2008 at 4:31 PM, chromatic <[EMAIL PROTECTED]> wrote: > On Wednesday 24 September 2008 11:22:22 [EMAIL PROTECTED] wrote: > >> Modified: >>trunk/docs/book/ch04_pir_subroutines.pod >>trunk/docs/book/ch09_hlls.pod >> >> Log: >> [Book] Add some basic info about VTables and HLL namespaces. >> >> Modified: trunk/docs/book/ch04_pir_subroutines.pod >> --- trunk/docs/book/ch04_pir_subroutines.pod (original) >> +++ trunk/docs/book/ch04_pir_subroutines.pod Wed Sep 24 11:22:22 2008 >> @@ -490,6 +490,63 @@ >> >> =head3 VTABLE Methods > > They're not really methods in any PIR or C sense though (I usually use the > term "entry"), as they're not really inherited nor invoked through a dispatch > scheme and they're stored elseways from methods on classes and PMCs, and I've > never seen them spelled other than VTABLE in the source and vtable in > discussion. Otherwise, the information here is correct. > i believe (without looking) that the pmc pdd calls them "vtable functions". i really wish the "vtable methods" meme would die. they're not methods. they are a collection functions which define the api to access the pmc, parrot's abstract data type. ~jerry
Re: [perl #59244] [TODO] Implement infix: for Pairs
On Wed, Sep 24, 2008 at 04:53:54PM -0700, chromatic wrote: > On Tuesday 23 September 2008 09:35:05 Moritz Lenz wrote: > > > %hash.pairs.sort needs infix: to work properly with Pair as input. > > > > It should be easy to add a multi that does this by first comparing the > > key, and if they are equal the value. > > > > When this is done most (or all) of the skip markers in > > t/spec/S29-hash/pairs.t can (hopefully) be removed. > > Something like this? Alas, there was another thread that shows that Parrot's 'sort' method can't seem to handle comparison functions that have :multi on them. See RT #59520, as well as the thread starting around http://lists.parrot.org/pipermail/parrot-dev/2008-September/28.html . Once that's fixed (or we come up with an alternative 'sort'), then this patch or something like it will probably work. Pm
Re: [svn:parrot] r31385 - trunk/docs/book
On Wed, Sep 24, 2008 at 05:00:31PM -0700, jerry gay wrote:
> On Wed, Sep 24, 2008 at 4:31 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > They're not really methods in any PIR or C sense though (I usually use the
> > term "entry"), as they're not really inherited nor invoked through a
> > dispatch scheme [...]
> [...]
> i really wish the "vtable methods" meme would die. they're not
> methods. they are a collection functions which define the api to
> access the pmc, parrot's abstract data type.
I'm curious about the "not really inherited" part -- if I declare
a new PMC class with
pmclass MyString extends String provides string ... {
}
then doesn't the MyString PMC "inherit" the vtable entries from
String?
I grant that there may be reasons why this isn't truly "inheritance",
but I think the use of the keyword "extends" (c.f. Java) may be
what makes all of this look like classes and methods.
Similarly, VTABLE_get_integer(pmc) acts an awful lot like a
polymorphic dispatch mechanism, even if it's a very simplistic
one.
I'm not at all arguing that this automatically means we should call
them "methods", but at a conceptual level they certainly seem a lot
like methods, and the vtable implementations contain references to
things like SELF and STATICSELF that make them look awfully method-like.
Regardless, I'll be happy to call them entries, methods, functions
or whatever the consensus and documentation ends up saying they are. :-)
Pm
Revisiting lexicals, part 1
From: "Patrick R. Michaud" <[EMAIL PROTECTED]> Date: Tue, 23 Sep 2008 03:45:37 -0500 I've put together a draft with my ideas and design for (re-)implementing lexicals in Parrot -- now available at http://www.pmichaud.com/perl6/lexical.txt . It's a first draft and might be a bit confusing in places, but overall I think it's a far cleaner design than the current implementation but also handles the vast bulk of what we need (or can be made to do so easily). Anyway, comments greatly appreciated. Pm Just a few: 1. In the translation of your Perl 6 example in "Runtime part 3: Closures and cloning", I notice that you do "get_global 'bar'" twice: .sub 'foo' ## bind inner sub 'bar' to current lexical environment $P0 = get_global 'bar' capture_lex $P0 ## ['bar' updated by side-effect] ## my $x = 1 $P1 = new 'Int' $P1 = 1 .lex '$x', $P1 ## return &bar $P2 = get_global 'bar' ## [updated 'bar' refetched] ## clone 'bar', preserving current lexical environment $P2 = clone $P2 ## [new 'bar' copy created] .return ($P2) .end Is this just an artifact, or is there something I'm missing? In any case, this looks like it has a race condition. If another copy of 'foo' is running concurrently, the other copy's "capture_lex" might happen before our "capture_lex" and "clone". Perhaps it would be better to suggest the following as the standard idiom: $P2 = get_global 'bar' ## [original 'bar'] $P2 = clone $P2 ## [new 'bar' copy created] capture_lex $P2 ## [copy updated] This "clone/capture_lex" combination acts as a drop-in replacement for "newclosure", and avoids capturing the outer context in a global (so that it could be garbage-collected sooner). 2. Compilers often know how many contexts outward to look when resolving a lexical reference; it might be useful to add another integer parameter to find_lex in order to support this optimization. 3. Since the whole context is captured, all of the :outer sub variables are preserved from GC for the life of all closures made for inner subs. That could be avoided if the LexPad stored the PMCs directly and not just their register indices. Doing so would require that the :outer sub also do store_lex and find_lex on lexical variables, and not just the inner ones. (That could be a drawback or a feature, depending on your point of view.) -- Bob Rogers http://rgrjr.dyndns.org/
Re: Revisiting lexicals, part 1
On Wed, Sep 24, 2008 at 10:11:07PM -0400, Bob Rogers wrote: > Just a few: > >1. In the translation of your Perl 6 example in "Runtime part 3: > Closures and cloning", I notice that you do "get_global 'bar'" twice: > > .sub 'foo' > ## bind inner sub 'bar' to current lexical environment > $P0 = get_global 'bar' > capture_lex $P0 ## ['bar' updated by side-effect] > [...] > ## return &bar > $P2 = get_global 'bar'## [updated 'bar' refetched] > ## clone 'bar', preserving current lexical environment > $P2 = clone $P2 ## [new 'bar' copy created] > .return ($P2) > .end > > Is this just an artifact, or is there something I'm missing? It's just an artifact of how I was originally thinking code generation might look -- you're correct, we only need it once. >In any case, this looks like it has a race condition. If another > copy of 'foo' is running concurrently, the other copy's "capture_lex" > might happen before our "capture_lex" and "clone". Perhaps it would be > better to suggest the following as the standard idiom: > > $P2 = get_global 'bar'## [original 'bar'] > $P2 = clone $P2 ## [new 'bar' copy created] > capture_lex $P2 ## [copy updated] That's a valid approach also (and one I also considered that the design should support -- taking a clone prior to capture_lex). I _hadn't_ thought of the concurrency angle, though, and I agree there could be a race condition here. However, the way I described it (capture_lex then clone) is the way that Synopsis 4 currently describes the bindings to take place, so I went with that. It'll be interesting to see how that plays with concurrency. >2. Compilers often know how many contexts outward to look when > resolving a lexical reference; it might be useful to add another integer > parameter to find_lex in order to support this optimization. I agree it could be a useful optimization, but I'll leave that decision to Allison and others. I'm just trying to get something that works for Perl 6. :-) >3. Since the whole context is captured, all of the :outer sub > variables are preserved from GC for the life of all closures made for > inner subs. That could be avoided if the LexPad stored the PMCs > directly and not just their register indices. Doing so would require > that the :outer sub also do store_lex and find_lex on lexical variables, > and not just the inner ones. (That could be a drawback or a feature, > depending on your point of view.) Given the way that code generation is currently working in PCT and Perl 6, I'm finding that register mapping of lexicals has _very_ limited utility, at least for languages (such as Perl 6) where binding is a much less common operation than assignment. So converting LexPads to store PMCs instead of register mapping might indeed be an improvement. It would probably also help with things like iterating over LexPads (which we can't seem to do at the moment). Pm
Re: Revisiting lexicals, part 1
In-Reply-To: Message from Geoffrey Broadwell <[EMAIL PROTECTED]> of "Wed, 24 Sep 2008 16:47:44 PDT." <[EMAIL PROTECTED]> > On Wed, 2008-09-24 at 18:09 -0500, Patrick R. Michaud wrote: >> On Thu, Sep 25, 2008 at 12:10:35AM +0200, Reini Urban wrote: >>> 2008/9/24 Patrick R. Michaud <[EMAIL PROTECTED]>: So, in order to get the behavior you're describing from the interactive prompt, we'll probably need more than just Perl 6's 'eval'. In particular, the interactive prompt mode will need to be able to maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have some way of extracting any lexical changes from whatever code string it evaluates. >>> I wouldn't call them DynLexPad or lexicals at all, I would call >>> them just globals. lexvars could shadow them though, but this a >>> user problem then. >> This approach might expose some rough edges, though -- things like >> MY::, OUTER::, *::, etc. might not work as expected, or those >> constructs would have to know when they're dealing with >> "interactive mode pseudo-lexical-globals" instead of what the rest >> of the system is using. >> Still, we might consider something along these lines -- perhaps as >> a stopgap approach if nothing else. > Don't we have to solve all this to get the Perl 6 debugger > working anyway? Although I'm unsure why that might be, I also recognize the possibility that there may well exist hypothetical documents, unread by me, which mandate some scenario or behavior wherein the answer to your question can only be yes. However, from a perl5 perspective, the answer is surely not. I'm going to do a quick review of *why* that answer is "surely not" before then going on to consider whether perhaps this *might* not apply to perl6 and ask that, should this indeed be what's afoot, that I be gently enlightened. So please bear with me or skip over, as you prefer. *In perl5*--and PLEASE hold that proviso for nearly the remainder of this letter; you'll immediately recognize once it no longer applies--all Cs provide a scope that, though separate and complete, is nevertheless deemed to be logically nested within its own surrounding scope. This behavior is no different than the expected one seen in common C and constructs, nor does it differ from the somewhat less common C and C constructs. Notably, the eval construct does this *NO MATTER WHETHER* it should occur in its dynamically compiled C guise, or in its hm, hm... earlier-compiled[?] C form. No distinction between these two occurs as far as scoping: both are self-contained but nested. Granted, distinctions unrelated to scoping do occur: the most important being *when* certain classes of exceptions are thrown. C throws compile-time exceptions at compile time but catches those thrown during run-time. C throws no exceptions at all, catching both sorts rather indiscriminately. (Shhh: no fatalistic out-of-memory mumbles, please.) This is at significant distinction with the scoping behavior(s!) exhibited by the otherwise similarly paired C and companion C constructs. For while C creates a nested scope just as most other BLOCKs you can think of do, including both BLOCK and STRING varieties of eval, a C critically differs form all these others by alone providing a scope *WHOLLY*UNRELATED* to the one textually surrounding its own execution (or caller, if you prefer). I said critical because of the highly desirable, impermeable partitioning of scope-related namespace also exhibited by both of C's derivative constructs, C and C. However, the timing of exception reporting is unchanged. Both C report compile-time errors during compile time (inarguably the optimal point for such reporting :-). And both C constructs, which wait until run-time to compile their strings (indirectly after filename catting for C), indiscriminately catch all exceptions (or, if you prefer, concealing them in an easily overlooked $@) occurring during compilation phase and execution phase alike. I regret making those readers already savvy with these fundamentals suffer through reading the preceding preambulatory text, but I was worried that without its exposition, I risked not all of us starting on equal footing. And now at last to the matter at hand. When "the debugger" (meaning, the run-time agent's debugger-hooks, whatever these should be used for) "stops" (well, other times, too, like actions, but anyway), it pauses with the pad that applies to that point in the code to be *its* pad--its scope. It runs auxiliarly code it compiles on the fly (because you typed in Perl code instead of any specific debugger "command") as an C. Since yours is the same (starting) pad as the code whose line you've stopped at, your C has complete access to that pad in a way that a C would not. This allows you to type in expressions and have names resolve first according to the pad you are logically stopped with in. Notably, it also allows for perl5 modules like PadW
Re: [perl #59006] stringifying Floats into PIR literals loses (a lot of) precision
On Tuesday 23 September 2008 21:37:09 Patrick R. Michaud wrote: > +1 in favor of applying this patch (and updating any tests to match) -- > this will _really_ improve things for PCT and Rakudo. Thanks! Applied as r31402. -- c
Re: Revisiting lexicals, part 1
On Wed, Sep 24, 2008 at 10:44:23PM -0600, Tom Christiansen wrote: > In-Reply-To: Message from Geoffrey Broadwell <[EMAIL PROTECTED]> > > Don't we have to solve all this to get the Perl 6 debugger > > working anyway? > > Although I'm unsure why that might be, I also recognize the possibility > that there may well exist hypothetical documents, unread by me, which > mandate some scenario or behavior wherein the answer to your question > can only be yes. > > However, from a perl5 perspective, the answer is surely not. First, a big thank you to Tom for the time and effort spent in describing the perl5 perspective here. I've not had much (okay, any) experience with "the debugger" in perl5, so reading Tom's description has greatly increased my understanding of what we may be looking at for Perl 6, and calms a few minor anxieties I had on the topic. So, this message was a big help to me and I really appreciate it. :-) To respond to a couple of other items I saw in the message: > I'm going to do a quick review of *why* that answer is "surely not" before > then going on to consider whether perhaps this *might* not apply to perl6 > and ask that, should this indeed be what's afoot, that I be gently > enlightened. As far as I'm aware, there's nothing in the current Perl 6 design or synopses that indicate that things are substantially different in this area from Perl 5. So, I'm comfortable that what we have thus far in a lexicals redesign for Parrot doesn't cause a conflict here. > [...] > However, I have no idea whether Parrot might not change all of this > existing situation around completely. I'm completely ignorant of > this, but I'd not be astonished to learn it did. > > If you told me yes, that's what happens, and then pushed me into guessing > why, I'd only get as far as making the uneducated guess that this must > somehow be due to *its* own assumptions, constraints, or expectations about > just what it means to execute newly eval code "in scope". > > Is this so, or is it not so? Taking a pure Parrot perspective, Parrot doesn't and probably shouldn't impose a particular view of debugging on the languages it supports. Clearly we can support the style of debugging and interactive execution that you've described happens with perl 5, but Parrot might also come across a dynamic language where eval'd code is "in scope" and can modify the current lexical environment. So, while Parrot probably won't impose this view on Perl (5 or 6), it may still need to evolve to support it at some point. What I can say with confidence is that what we have so far in Parrot today acts pretty much as you've described, and that in the lexical redesign work I'm doing now I'm explicitly not (yet?) addressing the situation of an eval being able to modify the (outer) scope in which is embedded. But I'm also fairly comfortable that the design I'm putting together can (with not too much work) accommodate that capability if/when we decide that Parrot needs it. >From a Perl 6 perspective, given that Pugs provides an interactive mode where one can do "my $variable" and have it stick, it may be that this becomes a standard feature in Perl 6 in general. Fortunately that's not my call, but I can see why people may want something like it for Rakudo as well, and people running Python on Parrot will certainly expect interactively entered lexical variable declarations to work. Anyway, none of what I've said above should be taken as Parrot or Perl's "official" stance; it's just how things currently look to me. Thanks again for the excellent and helpful message. Pm
