Re: [perl #35144] Core dump with computed-goto core
Nick Glencross <[EMAIL PROTECTED]> wrote: > Guys, > This isn't a highly critical segfault I imagine, although it might be of > interest to someone. > I discovered 'make fulltest' this evening. One of the debuginfo tests > (#7) fails as follows with r7942 on i386 Linux: > [EMAIL PROTECTED] parrot $ /usr/bin/perl5.8.5 t/harness --gc-debug > --running-make-test -g t/op/debuginfo.t [ ...] > t/op/debuginfoNOK 7# Looks like you failed 1 tests of 8. [ ...] Yep. GC bug with CGoto run cores. Resetting the lo_var_ptr (the stack "top" used for C stack tracing) was wrong. It did work some time ago, but gcc seems to create different code now. The intention was to exclude the rather big jump table from stack tracing. Anyway, I have removed this hack, which fixes the segfault. > Nick Thanks for reporting, leo
Pugs documentation & comments
As a newcomer to the Pugs project, I figured I would try to first read the code and understand what it does. Unfortunately, without a handy architectural overview or a reference to all the various custom types, that can be pretty tricky. Thus I'm interested in adding documentation and comments to Pugs, both as a learning exercise for myself, and as an aid to future contributors. I seem to recall a mention of Haddock on #perl6, but I'm not sure if that's leading anywhere. Is anyone else interested? Stuart
object/method tailcalls ?
Is it (yet?) possible to use tailcalls from/to object methods? I looked through the various pod files and couldn't find anything, and I remember seeing some discussion about tailcalls in general a couple of months ago but didn't stumble across the answers in the archives. I'd appreciate any gentle nudges towards the appropriate documentation, source file, or answer. Thanks! Pm
Re: Sun Fortress and Perl 6
Autrijus Tang wrote:
1. Type variables as role parameters
> [..]
Curiously, A12 and S12 already allows something like that:
role List[Type $t] {
method first() returns ::($t);
method rest() returns List[::($t)];
method cons(::($t) $x) returns List[::($t)];
method append(List[::($t)] $xs) returns List[::($t)];
}
But I am not at all sure if this is the correct notation --
specifically, the "Type" type is not explained, and I'm not sure
how they are instantiated during the type checking phase at the
compile time. Furthermore, I'm not sure that the ::($t) notation
is correct above.
Well, the ::() is the symbolic name syntax while ::Type is a
sigiled type/class/role etc. without prior declaration. This
is at least the way Damian used it. So the above could be
role List[ ::Type ] # immediately introduces Type
{
method first() returns Type;
method rest() returns List[Type];
method cons(Type $x) returns List[Type];
method append(List[Type] $xs) returns List[Type];
}
Actually the same applies for all types:
my ::Foo $foo;
Even I don't know exactly when ::Foo has to be available at the latest.
-
2. Tuple types
sub foo () returns (Int, Bool, Array) {
I think we have that. It's
sub foo () returns :(Int, Bool, Array) {...}
If you like you could use :() for the sig as well.
And it might be applicable for variables, too.
my @a:( Int, Bool, Array) = (23, true, [1,2,3] );
my %h:( count => Int, state => Bool, data => Array )
= { count => 23, state => true, data => [1,2,3] };
%h = "blubb"; # type error "no such field"
%h = 8; # type error "%h:(Bool)"
A function type could be &:(Str,Int,Int):(Str) or so.
Actually &(Str,Int,Int):(Str) looks better.
But we have &foo:(Str,Int,Int) OTOH. So I'm unsure here.
Even sub foo():(Int) {...} might be OK.
In general I think we have:
( term )
:( type spec )
::( symbolic ref/name )
-
3. Labels applies to blocks, not statements
Accordding to Luke that hasn't really been on the agenda.
But the postfix colon is heavily wanted elsewhere. With
Block as a Code subclass we might have:
block foo
{
say "Hello!";
say "Hi!";
}
Regards,
--
TSa (Thomas Sandlaß)
unary and infix ops summary and todo
1) we now have a rather complete set of opcodes that return a new result PMC, all prefixed by "n_", e.g. n_add Px, Py, 1 n_abs Px, Py These opcodes can/should be used by HLLs like Python, which have the semantics of immutable scalars and newly created result PMCs. 2) Tests for all these opcodes are very welcome 3) Proposal: PIR syntax enhancement .pragma n_operators ... Px = Py + 1 ... [EOF] Within this pragma (valid inside and until end of file) the shortcuts '+', '-', ... should translate to "n_add", "n_sub", ... This simplifies the adaption of already existing compiler code and is a bit more readable. 4) HLL to Parrot core type mappings. Most of Parrot's core classes functionality can now be inherited by HLL-specific classes. But there are still some explicit type enums in classes/*.pmc that should be HLL-dependent. E.g. Complex.absolute() result = pmc_new(.. enum_class_Float) This should rather be a TclFloat, PyFloat, whatever. To achieve this, we'd need a mapping for core PMCs and an HLL language specifier. E.g.: # file1 .HLL python python_group # language, shared lib .type_mapFloat => PyFloat .type_mapInteger => PyInt ... # file2 .HLL tcl tcl_group .type_mapFloat => TclFloat .type_mapInteger => TclInt The C<.type_map> has to be specified just once. The C<.HLL> in each source file. If no C<.HLL> was seen, the language defaults to parrot. Instead of the bare words, we could demand quoted strings too. Comments welcome, leo
Re: [svn:parrot] rev 7942 - in trunk: compilers/pge dynclasses runtime/parrot/dynext
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: boemmels > Date: Thu Apr 28 14:29:39 2005 > New Revision: 7942 > Modified: >trunk/compilers/pge/ (props changed) >trunk/dynclasses/ (props changed) >trunk/runtime/parrot/dynext/ (props changed) > Log: > Ignore some generated *.so files Ah, good. and *.dll Apropos: $ svn st [ ... my test files ... and ] ? .gdb-history ? .ddd ? core ? tags ? src/revision.c ? dynoplibs/myops_ops_cg.so ? dynoplibs/dan_ops_cg.h ? dynoplibs/dan_ops_switch.so ? dynoplibs/dan_ops_switch.c ? dynoplibs/myops_ops_switch.so ? dynoplibs/dan_ops_switch.h ? dynoplibs/dan_ops_cgp.so ? dynoplibs/dan_ops_cgp.c ? dynoplibs/dan_ops_cgp.h ? dynoplibs/myops_ops_cgp.c ? dynoplibs/dan_ops.so ? dynoplibs/myops_ops_cgp.h ? dynoplibs/myops_ops_cg.c ? dynoplibs/myops_ops_cg.h ? dynoplibs/myops_ops_switch.c ? dynoplibs/myops_ops_switch.h ? dynoplibs/myops_ops_cgp.so ? dynoplibs/dan_ops.c ? dynoplibs/myops_ops.so ? dynoplibs/dan_ops.h ? dynoplibs/myops_ops.c ? dynoplibs/dan_ops_cg.so ? dynoplibs/dan_ops_cg.c ? dynoplibs/myops_ops.h ? config/gen/makefiles/root.in.orig ? languages/lisp/lisp.pbc ? languages/lisp/Makefile Can *.rej, *.orig be ignored globally, or remove em in make clean? Thanks, leo
Re: object/method tailcalls ?
Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > Is it (yet?) possible to use tailcalls from/to object methods? Well, there is a C opcode in ops/object.ops. But I don't know, if it works correctly. $ find t -name '*.t' | xargs grep tailcall t/pmc/sub.t:tailcall P0 t/pmc/sub.t:tailcall P0 That seems to be it what we have WRT tests :-( > I looked through the various pod files and couldn't find anything, $ perldoc -F docs/ops/object.pod > I'd appreciate any gentle nudges towards the appropriate documentation, > source file, or answer. Thanks! Feedback and tests welcome. Thanks to you! > Pm leo
Re: Pugs documentation & comments
Stuart, I have been planning on doing much the same thing to try and increase my understanding of Haskell (although my free time is fairly limited lately). Autrijus had recommended beginning with src/Eval.hs and using the Haddock tool (http://haskell.org/haddock/). You are welcome to start right there. If you need svn commit access, just ask on #perl6 and someone will be glad to give it to you. Also if you look in docs/src/ there is a Junc.hs and a Junc.pod which was created by metaperl earlier in the project. This might be helpful for you as well. Stevan On Apr 29, 2005, at 4:59 AM, Stuart Cook wrote: As a newcomer to the Pugs project, I figured I would try to first read the code and understand what it does. Unfortunately, without a handy architectural overview or a reference to all the various custom types, that can be pretty tricky. Thus I'm interested in adding documentation and comments to Pugs, both as a learning exercise for myself, and as an aid to future contributors. I seem to recall a mention of Haddock on #perl6, but I'm not sure if that's leading anywhere. Is anyone else interested? Stuart
RE: parrot and refcounting semantics
Isn't there something like:
{
my $s does LEAVE { destroy $s } = new CoolClass;
# ... do stuff that may throw ...
}
Or something like that?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Martin D Kealey
Sent: Thursday, April 28, 2005 11:00 PM
To: perl6-internals@perl.org
Subject: Re: parrot and refcounting semantics
On Thu, 28 Apr 2005, Luke Palmer wrote:
> Or, with the "block hooks" that I keep claiming makes timely
destruction
> almost never needed, it is:
>
> {
> my $s = new CoolClass;
> # ... do stuff that may throw ...
> LEAVE { destroy $s }
> }
>
> This destroys properly and even propagates the exception.
That's good ... but can we have a shorthand; stealing an old C keyword,
I'd
suggest:
{
auto $a = new CoolClass;
# ... do stuff that my throw ...
}
The information contained in this e-mail message is privileged and/or
confidential and is intended only for the use of the individual or entity
named above. If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please immediately
notify us by telephone (330-668-5000), and destroy the original
message. Thank you.
Re: Sun Fortress and Perl 6
On Wed, 2005-04-27 at 09:46, Matt wrote: > On Wed, 27 Apr 2005 03:32:12 -0400, Autrijus Tang <[EMAIL PROTECTED]> > wrote: > > 3. Labels applies to blocks, not statements [...] > I've missed out on some Perl6 stuff, so excuse me as this was probably > already discussed. > > Does that mean this is possible? Keep in mind that you are replying to a description of Fortress, a sort of "next generation FORTRAN" language specification from Sun, as it could apply to Perl 6. The example was "perlish" (but note the lack of ";"s) So, what you're asking is "if we did this kind of thing in Perl 6, would this then be possible?" Just clarifying. PS: I read over the Fortress document last night after a friend who I introduced to LtU had looked at it, and left it on my chair (I have such good friends). It's a great read, and I recommend it. There are many things in there that Perl 6 could snarf, but most of the really good bits would probably be better just implemented as a grammar module. I like the way you can lay out a matrix, and the auto-parallelization stuff is kind of cool. By default a generator that you loop over with for is parallelized, so: for x â g do action x end would perform the action for all values of x in an arbitrary and potentially simultaneous order (threading where available). You can, of course, request that such things happen sequentially if you want. Then you get into the multi-generator loops: for x â g1, y â g2, z â g3 do action x, y, z end This would execute all permutations of x, y and z in parallel (or as close to parallel as the execution environment allowed for). Kind of neat. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: Sun Fortress and Perl 6
On Wed, 2005-04-27 at 03:32, Autrijus Tang wrote:
> (via http://lambda-the-ultimate.org/node/view/673 )
LtU is a great site, BTW, I highly recommend it to anyone interested in
languages.
> There are a few things in that spec, though, that makes me wonder
> if Perl 6 should have it too:
[...]
> 2. Tuple types
>
> sub foo () returns (Int, Bool, Array) {
>
> Currently per S09, Perl 6 collection types all have uniform types,
> so one has to use the `List of Any` or `Array of Any` return type
> instead. That seriously hinders inference and typechecking; however,
> I wonder if it is a design decision already made... :)
I don't think Parrot would have any support for signature checking of
this sort... just a thought.
> 3. Labels applies to blocks, not statements
I would say that this is a bad idea. We're keeping goto because it's
just darn useful for generated code, and for that same reason, it really
needs to be on a statement level, not a block level.
> 4. Software Transaction Memory
This is a good idea, but most of the things that it provides would
probably be better provided in a Parrot module, mocked up into each
client language in a module of their own, rather than as a core language
feature.
> 5. Macro model based on syntax expanders.
I'm pretty sure the combination of macros and grammar could easily
provide this in P6. It too is more of a module than a core language
feature, however.
> 6. Database-indexed module management
>
> An embedded database (such as SQLite) can be used to track different
> revisions of installed modules on the local machine, manage upgrades,
> check api compatibility, and keep related logs;
And a darned good idea, that!
> 7. AST definition
[...]
> Is there something like it that exists somewhere for Perl 6?
Isn't that called Pugs? ;-)
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: parrot and refcounting semantics
On Fri, Apr 29, 2005 at 08:14:38AM -0400, Butler, Gerald wrote:
:
: Isn't there something like:
:
: {
: my $s does LEAVE { destroy $s } = new CoolClass;
: # ... do stuff that may throw ...
: }
:
: Or something like that?
Yes,it's
my $s will leave { destroy $s } = new CoolClass;
and then it only destroyes if $s has been initialized. Also handy
are transactional versions that work on success or failure of the block:
my $s will keep { destroy $s } = new CoolClass;
my $s will undo { destroy $s } = new CoolClass;
There is no requirement for timely destruction in Perl 6.
Larry
Re: Sun Fortress and Perl 6
On Fri, Apr 29, 2005 at 08:33:56AM -0400, Aaron Sherman wrote:
> > Currently per S09, Perl 6 collection types all have uniform types,
> > so one has to use the `List of Any` or `Array of Any` return type
> > instead. That seriously hinders inference and typechecking; however,
> > I wonder if it is a design decision already made... :)
>
> I don't think Parrot would have any support for signature checking of
> this sort... just a thought.
Sure, but Parrot is not the compiler, it's just something I need to
target. Hierarchical signature checking should probably not be done in
the VM level.
> > 4. Software Transaction Memory
>
> This is a good idea, but most of the things that it provides would
> probably be better provided in a Parrot module, mocked up into each
> client language in a module of their own, rather than as a core language
> feature.
Sure, but saying atomic {} requires that the core Perl* PMCs has
STM support built in. Unless there is an easy way to swap out
Perl* PMCs from underneath, I don't think that STM can be done
as an extra add-on.
> > 7. AST definition
> [...]
> > Is there something like it that exists somewhere for Perl 6?
>
> Isn't that called Pugs? ;-)
Not until Pugs is machine-translated to Perl 6, and having that
form of AST definition in Perl 6 would help the process. I think
the translation needs to happen one way or another, anyway. :)
Thanks,
/Autrijus/
pgpjl41fK5Mnc.pgp
Description: PGP signature
Re: Quickcheck of context of index expressions
On Tue, Apr 26, 2005 at 03:33:44AM +0800, Autrijus Tang wrote: : Another quick check on expression context for indexed expressions. : Please sanity-check the return value of want() below: : : @x[0] = want(); # scalar context Good. : @x[want()] = $_; # scalar context : @x[want()] = @_; # scalar context Maybe "unknown" context, which defaults to list. : @x[0,] = want(); # list context : @x[want(),] = $_; # list context : @x[want(),] = @_; # list context : $_ = @x[want()]; # scalar context : @_ = @x[want()]; # list context No, I think they're all list context. Larry
Re: Quickcheck of context of index expressions
On Tue, Apr 26, 2005 at 03:56:37AM +0800, Autrijus Tang wrote:
: On Tue, Apr 26, 2005 at 03:33:44AM +0800, Autrijus Tang wrote:
: > Another quick check on expression context for indexed expressions.
: > Please sanity-check the return value of want() below:
: >
: > @x[0] = want(); # scalar context
: > @x[want()] = $_;# scalar context
: > @x[want()] = @_;# scalar context
: > @x[0,] = want();# list context
: > @x[want(),] = $_; # list context
: > @x[want(),] = @_; # list context
: > $_ = @x[want()];# scalar context
: > @_ = @x[want()];# list context
:
: Oh, and under the S02 rules above (the index expression inherits
: outer context on RHS), Pugs currently does this:
:
: $_ = %x{ 1, 2 }
: --- reduces to ---
: $_ = %x{ [1, 2] }
: --- reduces to ---
: $_ = %x{ "1 2" }
:
: Which is, well, very surprising. Where did I get wrong?
I think S02 is probably wrong. It should be unknown/list context.
Sorry for the short answers, but I'm in Russia behind a flakey network
connection, which is probably going away entirely at any moment (the
network connection, not Russia.) I can clarify more next week when
I get back.
Larry
Re: Quickcheck of context of index expressions
On Fri, Apr 29, 2005 at 06:22:57AM -0700, Larry Wall wrote: > : @x[want()] = $_; # scalar context > : @x[want()] = @_; # scalar context > > Maybe "unknown" context, which defaults to list. I think allowing unknown LHS index expression to default to scalar context is a bit more useful here. Since we have: @x[0] = @y;# scalar @x[0,] = @y;# list This may be more intuitive: @x[idx()] = @y;# scalar @x[idx(),] = @y;# list Than this: @x[+idx()] = @y;# scalar @x[idx()] = @y;# list But I don't really feel strongly one way or another, as long as it is specced down. :) Thanks, /Autrijus/ pgpKrdyICJNXu.pgp Description: PGP signature
Re: parrot and refcounting semantics
Gerald Butler <[EMAIL PROTECTED]> wrote:
> Isn't there something like:
> {
> my $s does LEAVE { destroy $s } = new CoolClass;
> # ... do stuff that may throw ...
> }
> Or something like that?
Not currently. There used to be a C opcode, but I've deleted
it, because I thought it's too dangerous. But it could be useful *if*
the compiler or parrot hacker really knows that there is not any
reference to that object around.
Above would roughly translate to
leave = newsub .Closure, _LEAVE
pushaction leave
...
s = newclass "CoolClass"
...
.end
.sub _LEAVE
s = find_lex "$s"
destroy s
.end
(variable declarations omitted)
leo
DYNSUPER bust for dynamic PMCs
pmc2c.pl says: =item C Calls the overridden implementation of the current method in the nearest superclass, using the static type of C. =item C As above, but uses the actual dynamic type of C. but for a dynamic class, if I try to use it I get errors such as: perl5null.pmc: In function `Parrot_Perl5NULL_set_pointer_keyed_int': perl5null.pmc:24: `enum_class_Perl5cargo_cult' undeclared (first use in this function) perl5null.pmc:24: (Each undeclared identifier is reported only once perl5null.pmc:24: for each function it appears in.) make: *** [perl5null.o] Error 1 1: Perl5cargo_cult is the correct (static) superclass of Perl5NULL, so I think that the description of DYNSUPER is inaccurate - it's actually calling through the vtable of the defining class' parent (rather than SUPER that goes direct), rather than what it might imply, which is going to the superclass of the class of the invocant PMC. 2: Either way, it's bust for dynamic classes, as you can't know the type number of the parent class at compile time. I'm not sure what to do about either. Nicholas Clark
Re: unary and infix ops summary and todo
On 4/29/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > 3) Proposal: PIR syntax enhancement > > .pragma n_operators > ... > Px = Py + 1 > ... > [EOF] > > Within this pragma (valid inside and until end of file) the shortcuts > '+', '-', ... should translate to "n_add", "n_sub", ... > This simplifies the adaption of already existing compiler code and is a > bit more readable. will this pragma affect all '.include'd files too? i dunno if this is good or bad. can it be reversed? something like: .pragma n_operators ... Px= Py + 1 ... .pragma a_operators Pz= Pi + 1 [EOF] i'm remembering my days with 'perl -w' and would rather have the 'use warnings;' functionality (scoping, both on AND off switches, etc.) ~jerry
Re: Quickcheck of context of index expressions
On Fri, Apr 29, 2005 at 06:22:57AM -0700, Larry Wall wrote: > : @x[want()] = $_; # scalar context > : @x[want()] = @_; # scalar context > > Maybe "unknown" context, which defaults to list. > > : @x[0,] = want(); # list context > : @x[want(),] = $_; # list context > : @x[want(),] = @_; # list context > : $_ = @x[want()]; # scalar context > : @_ = @x[want()]; # list context > > No, I think they're all list context. Okay. r2478 has them reverted to the original form, which inspects the declared return type of want() to see if it is a subtype of Scalar; if it is, then it is taken as scalar context; otherwise (or if multiple multisubs are possible), it defaults to list context. Thanks, /Autrijus/ pgpBtLbpCyzJx.pgp Description: PGP signature
S04 -- closure traits clarification
Greetings,
In trying to hack closure trait support into pugs, I have some
questions about closure traits, variable with "will" traits and
introspection. (Apologies if some of this has been discussed on the
list before -- I'm just going off of the synopses, which if definite
clarification on some of these issues has been made, should probably be
updated to reflect the decisions made.)
Firstly, it is suggested in S04 that variables indicated with a "will"
predicate contribute to the corresponding block-level trait. I.e., if
we have the following bit of code:
if $dbh {
my $sth will undo {$dbh.rollback} will keep {$dbh.commit} = FIRST
{$dbh.prepare($query)};
UNDO {
say "DB error!";
}
KEEP {
say "We're good!";
}
}
Then the block has in effect 5 total traits, 2 UNDO block, 2 KEEP
blocks and 1 FIRST blocks. From what I understand, the blocks for each
trait are executed in FIFO order, thus we would rollback before we
report the error in this contrived example.
Questions:
1) What type of introspection, if any, are we providing to the language
level? I.e., are we providing something along the lines of
%traits = &?BLOCK.traits
where %traits is keyed on trait name (FIRST, LAST, whatever) and in
turn is an array of closures? This would mean, for instance that we
could say
&?BLOCK.traits
to get the current block's FIRST closures, if any. When parsing the
block for traits, coming across a new FIRST block would be akin to
saying:
push &?BLOCK.traits, {...block contents...}
Specifically, I'm looking for definition of the syntax, which is only
alluded to in the Synopsis.
2) If we accept the introspection at the block-level above, it seems
clear that we should also accept the same .traits method on variables.
I.e., in the above DBI example, we should get back the closure(s) for
undoing by referring to $sth.traits. Is a variable-level trait a
single entry, or can we have multiple "will undo {...}" predicates on a
single variable? (The utility of such is left as an exercise to the
reader.)
3) User-definable traits. Now, this may be a closed domain of sorts,
but do we need to allow for the possibility of user-defined traits?
(I'm thinking here of variable-level "will" predicates.) If so, do
user-defined traits get normalized to UPPER? It would seem like we
would want consistency here, because if "will undo {...}" and "UNDO
{...}" get stored in the same trait slot, we're obviously transforming
one of the identifiers -- should this behavior be specific to our
"built-in" ones, or to all traits?
4) Which of the closure traits are supported as "will" predicates on
variables? Not all of the closure traits make sense on the
variable-level -- this information will be useful when trying to parse
the "will" predicates.
Thanks,
David Christensen
Re: DYNSUPER bust for dynamic PMCs
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> pmc2c.pl says:
>=item C
> As above, but uses the actual dynamic type of C.
> but for a dynamic class, if I try to use it I get errors such as:
> perl5null.pmc: In function `Parrot_Perl5NULL_set_pointer_keyed_int':
> perl5null.pmc:24: `enum_class_Perl5cargo_cult' undeclared (first use in this
> function)
You could try this:
static int enum_class_Perl5cargo_cult;
pmclass Perl5NULL dynamic extends Perl5cargo_cult {
void class_init() {
enum_class_Perl5cargo_cult = pmc_type(interp, "Perl5cargo_cult");
}
...
}
leo
Re: unary and infix ops summary and todo
Jerry Gay <[EMAIL PROTECTED]> wrote: > On 4/29/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote: >> 3) Proposal: PIR syntax enhancement >> >> .pragma n_operators >> ... >> Px = Py + 1 >> ... >> [EOF] >> >> Within this pragma (valid inside and until end of file) the shortcuts >> '+', '-', ... should translate to "n_add", "n_sub", ... >> This simplifies the adaption of already existing compiler code and is a >> bit more readable. > will this pragma affect all '.include'd files too? i dunno if this is > good or bad. .include files are just included and become part of the source file, so yes. But that's not good, if the .include file contains code too. Seems tath we need: .pragma n_operators push 0 # or 1 .pragma n_operators pop > can it be reversed? something like: > .pragma n_operators > ... > Px= Py + 1 > ... > .pragma a_operators Good idea. So maybe just: .pragma n_operators 0 # file default .pragma n_operators 1 > ~jerry leo
Re: S04 -- closure traits clarification
David Christensen writes:
> Greetings,
>
> In trying to hack closure trait support into pugs, I have some
> questions about closure traits, variable with "will" traits and
> introspection. (Apologies if some of this has been discussed on the
> list before -- I'm just going off of the synopses, which if definite
> clarification on some of these issues has been made, should probably be
> updated to reflect the decisions made.)
>
> Firstly, it is suggested in S04 that variables indicated with a "will"
> predicate contribute to the corresponding block-level trait.
Not really. `will` is just defined as:
$a will foo {...}
Is the same as:
$a is foo({...})
So it's up to foo to associate itself with the block.
> I.e., if we have the following bit of code:
>
> if $dbh {
> my $sth will undo {$dbh.rollback} will keep {$dbh.commit} = FIRST
> {$dbh.prepare($query)};
> UNDO {
> say "DB error!";
> }
> KEEP {
> say "We're good!";
> }
> }
>
> Then the block has in effect 5 total traits, 2 UNDO block, 2 KEEP
> blocks and 1 FIRST blocks. From what I understand, the blocks for each
> trait are executed in FIFO order, thus we would rollback before we
> report the error in this contrived example.
Nope. Entry-time blocks are executed in declaration order. Exit-time
blocks are executed in reverse declaration order. Just like CHECK and
END in Perl 5.
> Questions:
>
> 1) What type of introspection, if any, are we providing to the language
> level? I.e., are we providing something along the lines of
>
> %traits = &?BLOCK.traits
>
> where %traits is keyed on trait name (FIRST, LAST, whatever) and in
> turn is an array of closures? This would mean, for instance that we
> could say
>
> &?BLOCK.traits
>
> to get the current block's FIRST closures, if any. When parsing the
> block for traits, coming across a new FIRST block would be akin to
> saying:
>
> push &?BLOCK.traits, {...block contents...}
>
> Specifically, I'm looking for definition of the syntax, which is only
> alluded to in the Synopsis.
What you are saying here seems reasonable. However, we have to remember
that the closures are different for each run. So the traits are not
associated with the block, but with the particular runtime instance of
the block. Maybe that's what &?BLOCK refers to anyway.
I wonder how you could talk about the traits of a sub that isn't
currently executing.
> 2) If we accept the introspection at the block-level above, it seems
> clear that we should also accept the same .traits method on variables.
> I.e., in the above DBI example, we should get back the closure(s) for
> undoing by referring to $sth.traits. Is a variable-level trait a
> single entry, or can we have multiple "will undo {...}" predicates on a
> single variable? (The utility of such is left as an exercise to the
> reader.)
The question is, are you asking about the variable or the value? For
instance:
my $block = &?BLOCK; # _not_ calling
$block.traits;# variable traits or &?BLOCK traits?
We probably just use whatever the equivalent of `tied` is these days.
Let's call it, er, `tied`.
$block.traits; # &?BLOCK traits
(tied $block).traits; # variable traits
> 3) User-definable traits. Now, this may be a closed domain of sorts,
> but do we need to allow for the possibility of user-defined traits?
No. By which I mean OF COURSE!
> (I'm thinking here of variable-level "will" predicates.) If so, do
> user-defined traits get normalized to UPPER?
No. Block level traits are different from variable traits, and they
should be declared separately. The variable trait `undo` for instance
probably just pushes an UNDO handler on its caller. Likewise, the UNDO
macro (?) does precisely the same thing.
But people are allowed to declare traits that are all caps, and block
handlers which are lowercase, and any combination of the above. Perl
culture will try to enforce against that, however.
> It would seem like we would want consistency here, because if "will
> undo {...}" and "UNDO {...}" get stored in the same trait slot, we're
> obviously transforming one of the identifiers -- should this behavior
> be specific to our "built-in" ones, or to all traits?
>
> 4) Which of the closure traits are supported as "will" predicates on
> variables? Not all of the closure traits make sense on the
> variable-level -- this information will be useful when trying to parse
> the "will" predicates.
Hmm, not quite sure. Traits are a pretty big thing, and I'm not sure
what it buys you to hack them in. I'd start by implementing the block
handlers without variable traits.
Luke
Re: Junctions of classes, roles, etc.
On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote: > so we had junctions of Code references some days ago, what's with > junctions of Class and Role objects? :) Could we see some code that shows why this is a good idea? My initial reaction is horror; I can very easily see huge numbers of subtle, hard-to-reproduce bugs coming out of this. On the other hand, I do not immediately see major applications...most of what I can see is things that reduce the amount of code needed, but don't actually accomplish anything fundamentally new. What do junctions of Class|Role objects give us that can't be achieved in other ways? I'm quite willing to believe that there are such things, but I'm not coming up with them. --Dks
Re: Sun Fortress and Perl 6
On Fri, 2005-04-29 at 08:54, Autrijus Tang wrote:
> On Fri, Apr 29, 2005 at 08:33:56AM -0400, Aaron Sherman wrote:
> > > Currently per S09, Perl 6 collection types all have uniform types,
> > > so one has to use the `List of Any` or `Array of Any` return type
> > > instead. That seriously hinders inference and typechecking; however,
> > > I wonder if it is a design decision already made... :)
> > I don't think Parrot would have any support for signature checking of
> > this sort... just a thought.
> Sure, but Parrot is not the compiler, it's just something I need to
> target. Hierarchical signature checking should probably not be done in
> the VM level.
How do other languages call P6 subroutines and methods? Parrot has a
rather sophisticated signature checking scheme built into it's MMD.
Ignoring it and building your own will cost you heavily in performance.
Using it and name-mangling will cost you in inter-language operation
(Ponie comes to mind), and cost you slightly in performance.
Do we have enough call for this that it's worth the hit?
> > > 4. Software Transaction Memory
> >
> > This is a good idea, but most of the things that it provides would
> > probably be better provided in a Parrot module, mocked up into each
> > client language in a module of their own, rather than as a core language
> > feature.
>
> Sure, but saying atomic {} requires that the core Perl* PMCs has
> STM support built in. Unless there is an easy way to swap out
> Perl* PMCs from underneath, I don't think that STM can be done
> as an extra add-on.
I'm not sure. I would think you could redefine them as needed, but I
don't know that.
> > > 7. AST definition
[...]
> > Isn't that called Pugs? ;-)
>
> Not until Pugs is machine-translated to Perl 6, and having that
> form of AST definition in Perl 6 would help the process. I think
> the translation needs to happen one way or another, anyway. :)
Yeah, yeah. I was joking.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: Sun Fortress and Perl 6
On Fri, Apr 29, 2005 at 02:35:26PM -0400, Aaron Sherman wrote:
> > Sure, but Parrot is not the compiler, it's just something I need to
> > target. Hierarchical signature checking should probably not be done in
> > the VM level.
>
> How do other languages call P6 subroutines and methods? Parrot has a
> rather sophisticated signature checking scheme built into it's MMD.
> Ignoring it and building your own will cost you heavily in performance.
> Using it and name-mangling will cost you in inter-language operation
> (Ponie comes to mind), and cost you slightly in performance.
>
> Do we have enough call for this that it's worth the hit?
Well, complex hierarchical types is mandated by S06 and S09 already:
my sub get_book () of Hash of Array of Recipe {...}
my num @nums = Array of num.new(:shape(3;3;3));
Does Parrot's MMD carry this type information natively? I think the
type information has to be encoded somehow anyway, and Ponie can then
reuse the same name-mangling to call into Perl 6 subroutines.
If you have specific issues w.r.t inter-language operation between
Perl 5 and Perl 6, I'd love to hear about it. I do hope you are not
suggesting that we drop the Perl 6 type system to shoehorn into the
Perl 5's /prototype/ signature semantics, though. :-)
Thanks,
/Autrijus/
pgpa3KwFR5ZF0.pgp
Description: PGP signature
Re: parrot and refcounting semantics
At 3:05 PM +0200 4/29/05, Leopold Toetsch wrote:
Gerald Butler <[EMAIL PROTECTED]> wrote:
Isn't there something like:
{
my $s does LEAVE { destroy $s } = new CoolClass;
# ... do stuff that may throw ...
}
Or something like that?
Not currently. There used to be a C opcode, but I've deleted
it, because I thought it's too dangerous.
We really need to put it back in -- I knew it was dangerous, but it
was necessary. We should probably make it 'safe' by forcing the
destroyed PMC to be an Undef after destruction, in case something was
still referring to it.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: parrot and refcounting semantics
At 12:37 AM -0400 4/29/05, Uri Guttman wrote: > "RR" == Robin Redeker <[EMAIL PROTECTED]> writes: RR> I don't think circular references are used that much. This is RR> maybe something a programmer still has to think a little bit RR> about. And if it means, that timely destruction maybe becomes RR> slow only for the sake of collecting circular references... don't RR> know if thats a big feature. ever do any callback stuff? an object needs to be called back from a service (say a i/o handler). it must pass itself to the service to be stored there. the service returns a handle which needs to be stored in the object so it can be used to manage it (start/stop/abort/etc.). there is a quick circular ref. Oh, I realize that, along with a number of other useful uses of circular references. I can't speak for Robin, but when I said circular refs weren't that common I was talking in the overall number of things case. The large majority of objects are dead-stupid things that have no finalizers and no references to anything, the second largest (and definitely smaller case) is objects that refer to other objects in a non-circular fashion, then circular objects, then objects that need timely destruction. Anyway, that usage pattern argues for efficiency handling simple PMCs first, reference/aggregate PMCs second, and ones with timely destructors last, which is how parrot's DOD/GC system's set up. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: parrot and refcounting semantics
At 10:55 PM -0400 4/28/05, Bob Rogers wrote: From: Robin Redeker <[EMAIL PROTECTED]> Date: Thu, 28 Apr 2005 00:12:50 +0200 Refcounting does this with a little overhead, but in a fast and deterministic O(1) way. This is the first half of an apples-to-oranges comparison, and so is misleading even if partly true. Refcounting may be proportional (approximately) to the amount of reference manipulation, but GC is proportional (though even more approximately, and with a different constant) to the amount of memory allocated [1]. Actually it's proportional to the number of live objects. A refcounting scheme has to touch *all* objects at least twice, while a tracing scheme generally has to touch only the objects that are live at trace time. For the most part, refcount O(n) time is proportional to the total number of objects created, while tracing O(n) time is proportional to the number of live objects. It's definitely possible to work up degenerate examples for both refcount and tracing systems that show them in a horribly bad light relative to the other, but in the general case the tracing schemes are significantly less expensive. From: Dan Sugalski <[EMAIL PROTECTED]> Date: Thu, 28 Apr 2005 13:10:00 -0400 . . . >I don't think circular references are used that much. This is maybe >something a programmer still has to think a little bit about. >And if it means, that timely destruction maybe becomes slow only for the >sake of collecting circular references... don't know if thats a big >feature. Circular references are far more common than objects that truly need timely destruction, yes, and the larger your programs get the more of an issue it is. Neither are terribly common, though. I'm astounded. Do neither of you ever design data structures with symmetrical parent<->child pointers? No trees with parents? No doubly-linked lists? In my (probably skewed) experience, circular references are used frequently in languages like C or Lisp that don't penalize them. I responded to Uri on this, but note that I said "neither are terribly common", and they aren't. Relative to the total number of GC-able things, objects in circular structures are a very small minority. Which, of course, doesn't help much as an app designer when you have to deal with these things, but it is important to know when doing the design of the back end, since relative usage of features needs to be kept in mind when making design tradeoffs. One of those annoying engineering things. (Just once I'd love to have my cake *and* eat it too, dammit! :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
ANN: JavaScript TestSimple 0.03
Hi All, I've released TestSimple 0.03, the port of Test::Simple/::More/::Builder to JavaScript. You can find the details here: http://www.justatheory.com/computers/programming/javascript/ test_simple-0.03.html The most significant change in this version is the addition of control over where output is sent. Where Test::Builder uses file handles, since JS has no I/O, I'm using function references, instead. By default, output goes to document.write, but you can send it to any function reference. So for my next trick, a harness! I have to give some thought for how to combine a bunch of JS tests into one output. Maybe a JS script that spawns hidden frames and runs the tests in them, then collects the output from them (directly from details(), actually). But I'd welcome other ideas and suggestions. Once I have that problem solved, I'll probably stop sending announcements here, as it'll be more about JavaScript-QA, and I'll try to find or found another venue. Cheers, David
Re: ANN: JavaScript TestSimple 0.02
On Apr 19, 2005, at 6:07 PM, Adam Kennedy wrote: Consider the idea of creating a Document that doesn't actually exist in a window and is thus not seen. (I believe this is possible). Yes, I think that this is what I'll do for the harness. Your tests can write out to this document, and the harness can do counting of test results without spewing the entire test results to the screen. The harness can then print the summary of the test results directly to the screen, in the same way we get either a "show all test results" or "show the summary of all the tests". Once you are writing to an invisible document, why are you using a document? :) Just use an Array, or file-handle-like thing. Or perhaps an object that mocks/simulates a document, so that if you want to run just a single test, it will print out to the document, but in harness mode it's writing to an internal fake document. Yes, this is what TestBuilder already does. It writes all the test results to the array returned by details(). Test::Harness can't use this because it runs tests in their own processes and can't get at their data. But that's not an issue for JS, which doesn't have the I/O support to fork processes. So I can just reach into a child document and grab the details and use them to output a summary or, with ?verbose=1, all the test output. Great suggestions, Adam, thanks! Cheers, David
Re: Junctions of classes, roles, etc.
David Storrs <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote:
> > so we had junctions of Code references some days ago, what's with
> > junctions of Class and Role objects? :)
>
> Could we see some code that shows why this is a good idea? My initial
> reaction is horror; I can very easily see huge numbers of subtle,
> hard-to-reproduce bugs coming out of this. On the other hand, I do
> not immediately see major applications...most of what I can see is
> things that reduce the amount of code needed, but don't actually
> accomplish anything fundamentally new. What do junctions of
> Class|Role objects give us that can't be achieved in other ways?
>
> I'm quite willing to believe that there are such things, but I'm not
> coming up with them.
What do you think this is?
sub foo(Str | Int $bar) { ... }
Or this one, which is even more important?
sub foo(Any | Junction $bar) { ... }
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
"I used to have a life, but I liked mail-reading so much better."
Re: parrot and refcounting semantics
From: Dan Sugalski <[EMAIL PROTECTED]> Date: Fri, 29 Apr 2005 15:23:47 -0400 At 10:55 PM -0400 4/28/05, Bob Rogers wrote: >From: Robin Redeker <[EMAIL PROTECTED]> >Date: Thu, 28 Apr 2005 00:12:50 +0200 >Refcounting does this with a little overhead, but in a fast and >deterministic O(1) way. > >This is the first half of an apples-to-oranges comparison, and so is >misleading even if partly true. Refcounting may be proportional >(approximately) to the amount of reference manipulation, but GC is >proportional (though even more approximately, and with a different >constant) to the amount of memory allocated [1]. Actually it's proportional to the number of live objects. When running a sweep, yes, but the frequency of sweeping is in turn proportional to the rate at which new memory is allocated, depending of course on GC settings. So the overall cost is proportional to the product, which (and this was my point) can be effectively zero for some programs some of the time [1]. A refcounting scheme has to touch *all* objects at least twice, while a tracing scheme generally has to touch only the objects that are live at trace time. That is true for a copying GC, but a mark/sweep GC also needs to visit both the quick and the dead during the sweep phase in order to free them. For the most part, refcount O(n) time is proportional to the total number of objects created, while tracing O(n) time is proportional to the number of live objects. But you have to increment/decrement/test the refcount each time you pass a refcounted object to a sub, don't you? So that makes the cost of refcounting proportional to runtime, doesn't it? (I don't know how Perl5 does it in detail.) It's definitely possible to work up degenerate examples for both refcount and tracing systems that show them in a horribly bad light relative to the other, but in the general case the tracing schemes are significantly less expensive. Agreed. >I'm astounded. Do neither of you ever design data structures with >symmetrical parent<->child pointers? No trees with parents? No >doubly-linked lists? In my (probably skewed) experience, circular >references are used frequently in languages like C or Lisp that don't >penalize them. I responded to Uri on this, but note that I said "neither are terribly common", and they aren't. Relative to the total number of GC-able things, objects in circular structures are a very small minority. I can think of many programs I've written or otherwise hacked on where this is not the case. In some cases, the majority of objects are directly circular (i.e. part of a cycle as opposed to being referenced from an object in a cycle). But I suppose that just means that we've worked on very different apps. Before Perl5, I used to use parent pointers at the drop of a hat. But, 'nuff said, I guess. Which, of course, doesn't help much as an app designer when you have to deal with these things, but it is important to know when doing the design of the back end, since relative usage of features needs to be kept in mind when making design tradeoffs. One of those annoying engineering things. (Just once I'd love to have my cake *and* eat it too, dammit! :) -- Dan In engineer heaven, perhaps. "RePentium, and ye shall be saveall'ed!" ;-} -- Bob [1] This was commonly true of programs written for the early Lisp Machines; programmers tried really hard to avoid allocation of short-term garbage, since real memory was expensive and GC was painfully slow.
Re: DYNSUPER bust for dynamic PMCs
Nicholas Clark <[EMAIL PROTECTED]> wrote: >=item C Another note: we might as well create a C vtable call as well. We need some such (and an opcode) anyway for HLL objects. How could/should that beast look like? $ python >>> help(super) class super(object) | super(type) -> unbound super object | super(type, obj) -> bound super object; requires isinstance(obj, type) | super(type, type2) -> bound super object; requires issubclass(type2, type) | Typical use to call a cooperative superclass method: | class C(B): | def meth(self, arg): | super(C, self).meth(arg) > Nicholas Clark leo
