Namespaces Redux
I've started implementing namespace support in Tcl this week (yay!). But I've run into a bit of trouble, so I have a couple questions: The get_namespace opcode gets namespaces from the root namespace. Should it get namespaces from the HLL namespace instead? The PDD isn't explicit either way, but the usage I had in mind works better if it works from the HLL namespace. I've added a failing test that tries to get a namespace from the HLL. Is there any reason that [...; ''] and [...] couldn't refer to the same namespace? Tcl uses C .namespace [''] to refer to the root namespace (correctly, I think) and I can't think of any language that would want to differentiate between the two. It would simplify code generation for Tcl to have '' act like this. Here's some Perl that models what I'm trying to write for Tcl in PIR: my $command = ...; my @namespace = split /::+/, $command; $name = pop @namespace; my $namespace = get_namespace(@namespace); my $sub = find_global($namespace, $name); $sub-(); Without the changes, I'll have to unshift 'tcl' to the front of every array I use to lookup namespaces, as well as check for empty strings (consider the input ::puts, which should refer to the puts global in the '' namespace). It's a lot of code that's not really necessary. Also, is there any reason we can't/shouldn't add find_global variants that lookup globals in HLL's? Right now we have find_global_p_p_s. Adding find_global_p_s_p_s would let me reach into Tcl's private very easily instead of having to crawl the namespaces myself. $P0 = find_global '_tcl', ['Foo'; 'Bar'], baz Thanks, -- matt diephouse http://matt.diephouse.com
Re: Test::Harness wrangling
Maybe slightly unrelated, but have you guys considered adding some extra (optional) meta info to the TAP spec? For instance at $work, we group our individual assertions into higher level tests like this: # TITLE: Some test case ok 1 ok 2 - awesome not ok 3 I believe we also have an ACTION: tag. Cheers, Luke On 28-Jun-06, at 9:13 PM, Andy Lester wrote: Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on Test::Harness. Any bugs that we especially need to work on? xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Test::Harness wrangling
Luke Closs wrote: Maybe slightly unrelated, but have you guys considered adding some extra (optional) meta info to the TAP spec? For instance at $work, we group our individual assertions into higher level tests like this: # TITLE: Some test case ok 1 ok 2 - awesome not ok 3 I believe we also have an ACTION: tag. another useful meta info for TAP: # LINENO: (pugs links test messages to higlighted version of the test script) -- Michael Peters Developer Plus Three, LP
Re: Test::Harness wrangling
Andy Lester wrote: Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on Test::Harness. Finalize Test::Harness::Straps. Make it possible to programatically run tests and to capture output. Eg. Module::Build has need to run tests, displaying output as normal, but to also capture that output (screen output as well as test results) so that it can feedback those results to calling processes. I guess that would be a low priority item since very very few apps would need that feature... Randy.
Re: Test::Harness wrangling
Andy Lester wrote: Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on Test::Harness. Any bugs that we especially need to work on? Not a bug, but a feature request. Abstract out the TAP parsing into a separate module so that it can be done by more than just Test::Harness::* modules. -- Michael Peters Developer Plus Three, LP
Re: Test::Harness wrangling
On Thursday 29 June 2006 07:13, Andy Lester wrote: Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on Test::Harness. Any bugs that we especially need to work on? Well, giving my angle as the Test::Run maintainer (which is a fork of Test::Harness): 1. I may have eliminated some bugs in Test::Run without reporting them in Test::Harness yet. (not maliciously - it was an accident). 2. Some of my refactorings caused some bugs by accident (which was visible in the output) which were not caught by the test suite. As a result, I added some tests to Test::Run, but did not send a patch with them to Test::Harness. Hoping that I'm not defaming Andy or something, he told me that he isn't interested in such tests at this point, because the output is still dynamically changing. I think that instead the tests should still be there, and would need to be modified (preferably before the behaviour is modified). Otherwise, a wrong refactoring can easily break something. (As was the case for me). 3. I separated Test::Harness into Test::Run and Test::Run::CmdLine. Test::Run is the backend with a (hopefully) sane programmable API (with no global variables, environment variables, command line processing, etc.). Test::Run::CmdLine handles all the command line stuff. Both can be inherited or over-rided with plugins (or possibly traits/roles which I did not play with yet, but think I understand). Normally a T::R::CL plugin also registers an appropriate T::R plugin. The default behaviour for Test::Run currently is to behave much like Test::Harness. However, that may change as I may wish to move some of the functionality to plugins, so one can more easily customise it. 4. I implemented the prove command as a class, with a small command line wrapper: http://xrl.us/nsub (Link to search.cpan.org) 5. One important note: Test::Run is not backwards-compatible with Test::Harness. The documented external API (and the internals even more so) were broken. I once contemplated writing a Test::Harness-like wrapper for Test::Run but I did not get to it yet. In any case, I've been actively using the Test::Run::CmdLine runprove utility to run some of my own test files. See: http://flickr.com/photos/[EMAIL PROTECTED]/68430623/ I also would like to integrate it with the makefile/Buildfile generated by Module::Build and ExtUtils::MakeMaker (at least using some wrappers inside the Build.PL or Makefile.PL scripts, which I have yet to figure out how to write.) All these are just notes for what I did with Test::Run - you can take them or leave them. I don't mind you hacking on Test::Harness (it could use some work), but naturally would also love to receive any patches to Test::Run, which also still has some issues (like the fact most of the Test::Harness POD documentation was not forward-ported). The code can be checked out using svn: http://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/trunk/ (or alternatively with https) If you register at Berlios.de and send me a patch, I'll add you as a commiter so you can commit it. (Following Audrey Tang's on IRC lead). Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Test::Harness wrangling
On Thursday 29 June 2006 13:27, Michael Peters wrote: Andy Lester wrote: Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on Test::Harness. Any bugs that we especially need to work on? Not a bug, but a feature request. Abstract out the TAP parsing into a separate module so that it can be done by more than just Test::Harness::* modules. A very good idea, which was already discussed in the Perl blogospher. Here, if I remember correctly. What other people said they would like to see is some kind of an event-driven parser, with the events being transmitted to a sub-class or a different class or callbacks. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Test::Harness wrangling
On Jun 29, 2006, at 5:21 AM, Randy W. Sims wrote: Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on Test::Harness. Finalize Test::Harness::Straps. That is THE reason we're doing this. Everything else is gravy. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Test::Harness wrangling
- Original Message From: Michael Peters [EMAIL PROTECTED] Not a bug, but a feature request. Abstract out the TAP parsing into a separate module so that it can be done by more than just Test::Harness::* modules. I started that, but I hit three snags. 1. It would be very useful to disambiguate diag() output. 2. No one commented on my sample grammar (including the glaring bug). 3. I moved to Europe, thus throwing my life into chaos. If enough folks are really interested, I can see about scraping up some tuits, but I also have two conference presentations to write. Cheers, Ovid
Re: Test::Harness wrangling
If it's not too late, I would really love to see the TAP output disambiguate between diag() output and test failure output. I think it was Adrian who suggested something as simple as: not ok 52 - forced failure # Failed test 'forced failure' # in t/db_version.t at line 225. # got: '3' # expected: '4' # this is diag output That would be easy to parse, should be trivial to implement and, I suspect, be backwards compatible. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/ - Original Message From: Andy Lester [EMAIL PROTECTED] To: perl-qa@perl.org Sent: Thursday, June 29, 2006 5:13:02 AM Subject: Test::Harness wrangling Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on Test::Harness. Any bugs that we especially need to work on? xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Test::Harness wrangling
- Original Message
From: Luke Closs [EMAIL PROTECTED]
Maybe slightly unrelated, but have you guys considered adding some
extra (optional) meta info to the TAP spec? For instance at $work,
we group our individual assertions into higher level tests like this:
# TITLE: Some test case
ok 1
ok 2 - awesome
not ok 3
If you find yourself doing that a lot, I strongly recommend checking out
Test::Class. Then, grouping tests is as simple as including them in a single
method:
sub some_test_case : Test(3) {
my $test = shift; # same as $self, actually
ok some_func();
ok another_func(), 'awesome';
is $answer, 42;
}
It's also easier to organize tests and you can inherit tests, too (that's very
useful when you're changing only a small bit of behavior in a subclass but you
need to ensure that the rest of the behavior is unchanged).
Cheers,
Ovid
Re: Test::Harness wrangling
On Wed, Jun 28, 2006 at 11:13:02PM -0500, Andy Lester wrote: Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on Test::Harness. Any bugs that we especially need to work on? They're not so much bugs as structural annoyances that it would be useful to relax to make subclassing Test::Harness more useful. (Well, most accurately, to allow me to write a parallel test runner easily) I hacked Test::Harness and Test::Harness::Straps around to get parallel tests running (version 1), but I made no effort to keep the conventional behaviour working cleanly, hence I'm not sure if sending you that code would be useful. However, based on that, things that it would be nice to refactor out (from memory): The code to do the printing of the test names, the ...s and the numbers could be refactored out into a proper helper class, to allow derivatives more flexibility in what the chose to display. This class would suck in the subroutines associated with strap_callback as methods. In turn, it would stop the evil storing of callback state in the main T::H object. In turn, the globals $ML $Last_ML_Print can be eliminated and stored as state in this. Nicholas Clark
Re: Test::Harness wrangling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ovid wrote:
sub some_test_case : Test(3) { my $test = shift; # same as $self,
actually ok some_func(); ok another_func(), 'awesome'; is $answer,
42; }
Also for those of us who are fed up with counting tests manually:
sub some_test_case : Tests {
# Same as above...
}
Or if you don't feel like going OO with your tests, TIMTOWTDI thanks
to Test::Group:
test testing something = sub {
ok some_func();
ok another_func(), 'awesome';
is $answer, 42;
};
Produces
1..1
ok 1 # testing something
It's also easier to organize tests and you can inherit tests, too
Well, Test::Class undoubtedly is better for some things :-)
- --
Dominique QUATRAVAUX Ingénieur senior
01 44 42 00 08 IDEALX
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEo96rMJAKAU3mjcsRAixjAJ9G9Mb9tWvdue2suiGN6UX8ZsFHTwCgl094
QFuzjjbcZt4a1zcixfHx6sQ=
=IK2E
-END PGP SIGNATURE-
Re: Test::Harness wrangling
On Jun 28, 2006, at 21:13, Andy Lester wrote: Any bugs that we especially need to work on? This might be Test::Builder, but I've seen many times on my Mac where STDERR and STDOUT output is out of sync. For example, info about why a test failed can be miles from the line where the no ok appears. Best, David
Re: Test::Harness wrangling
David Wheeler wrote: On Jun 28, 2006, at 21:13, Andy Lester wrote: Any bugs that we especially need to work on? This might be Test::Builder, but I've seen many times on my Mac where STDERR and STDOUT output is out of sync. For example, info about why a test failed can be miles from the line where the no ok appears. This is a general problem with the way some of the testing modules work. They output their diagnostic messages as comments to STDERR. They should send them instead to STDOUT so that it can be synced. TAP does support comments, so I'm not sure why those modules do that. This doesn't resolve the problem of non-test modules emitting things to STDERR that could be useful when tracking down bugs, but what they might print is not TAP, so can't really be associated with particular tests. -- Michael Peters Developer Plus Three, LP
Update from YAPC::NA
I noticed a lot of people weighed in with non-bug posts to Andy's bug fix request. I just wanted to note that Wednesday we had a PITA/Test::Builder/Testing BOF at which a bunch of people had an hour long talk about the structure of Test::et-al TAP and various other topics. I think we addressed a number of the things people just mentioned. Schwern has collected up the ideas, and I imagine will have something to say later on the various ideas. As for bugs today, frankly I'm only looking at things like make sure Straps passes all tests when a transparent subclass is substituted so I've got a chance to extract the TAP content for the PITA image managers. Adam K
Re: Test::Harness wrangling
On Jun 29, 2006, at 07:26, Michael Peters wrote: This is a general problem with the way some of the testing modules work. Only because they all use Test::Builder's output methods. This doesn't resolve the problem of non-test modules emitting things to STDERR that could be useful when tracking down bugs, but what they might print is not TAP, so can't really be associated with particular tests. I use Test::More::diag() (or main::diag()) for that. Best, David
Re: Update from YAPC::NA
Hi Adam, I definitely realize that some of the feature requests do not seem like bugs, but if some are easy to implement then I would think they should be worthy of consideration. David Wheeler's complaint about unsynchronized test output is definitely a bug and it's one I've been bitten by many times. However, I would humbly suggest that things like disambiguating diag() output are so trivial and so potentially useful that it might be worth it. If they turn out to not be trivial, then no worries. Mind you, I've never considered sending a patch as I don't recall hearing any feedback as to whether or not such a feature would be incorporated. And while we're at it, another non-bug but definitely useful feature out be for TAP output to have a version number, but that's another story ... Sorry for the line noise. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/ - Original Message From: Adam Kennedy [EMAIL PROTECTED] To: perl-qa@perl.org Sent: Thursday, June 29, 2006 3:56:24 PM Subject: Update from YAPC::NA I noticed a lot of people weighed in with non-bug posts to Andy's bug fix request. I just wanted to note that Wednesday we had a PITA/Test::Builder/Testing BOF at which a bunch of people had an hour long talk about the structure of Test::et-al TAP and various other topics. I think we addressed a number of the things people just mentioned. Schwern has collected up the ideas, and I imagine will have something to say later on the various ideas. As for bugs today, frankly I'm only looking at things like make sure Straps passes all tests when a transparent subclass is substituted so I've got a chance to extract the TAP content for the PITA image managers. Adam K
Re: Test::Harness wrangling
On Thursday 29 June 2006 07:26, Michael Peters wrote: This is a general problem with the way some of the testing modules work. They output their diagnostic messages as comments to STDERR. They should send them instead to STDOUT so that it can be synced. TAP does support comments, so I'm not sure why those modules do that. T::H::S can collect diagnostic information, but it doesn't read STDERR by default. I wonder if changing T::B to have two separate outputs (debugging for per-test information which goes to STDOUT and diagnostics stay the same) would make this easier. It's a change, but is it worth it? -- c
[perl #39663] [TODO] perl coding standards
# New Ticket Created by Will Coleda # Please include the string: [perl #39663] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39663 Need to: 1) Decide on perl coding standards (stealing from PBP) 2) implement a .perlcriticrc file that enforces the rules we decide on. 3) add a test (probably not run by default) that prints out all the files that fail to conform. (Using Perl::Critic) Regards. -- Will Coke Coleda [EMAIL PROTECTED]
Re: Pm's YAPC::NA talk online
On Wed, Jun 28, 2006 at 08:12:42AM -0500, Jonathan Scott Duff wrote:
On Wed, Jun 28, 2006 at 04:26:45AM -0500, João Cruz Morais wrote:
- Can I use PGE skipping TGE?
I don't see why not. If you look at the bottom of grammar_rules.pg,
you'll see this:
token syntax_error { ?PGE::Util::die: Syntax error }
where PGE::Util::die is a PIR subroutine. IIUC, everywhere you want
some action to be performed (like code generation for instance) you
could put a PIR subroutine in the grammar just as above and, of
course, write the subroutine to do the action.
It's also worth remembering that one can call executable code
directly from a rule.
token print :lang('PIR') {
expression
{{ $P0 = match['expression']
say $P0
}}
}
- PAST seems just fine as a concept but isn't it useless if I can target
directly to POST with minor fuss?
If one can target POST (or even PIR) directly with minor fuss, then
a separate PAST step might not make much sense. But even with
a relatively simple language (like APL), it's useful to have the
tree-based representation of the program's semantics to be able to
manipulate (e.g., optimizations) rather than trying to work directly
from the parse tree.
Good luck for today's presentation :)
Yeah, good luck Pm :)
Thanks! For those who are interested, the slides from the later
talks are now online.
Perl 6 Compiler Status and the Parrot Compiler Toolkit
http://www.pmichaud.com/2006/pres/yapc-perl6/start.html
Parsers, Perl 6 Rules, and the Parrot Grammar Engine
http://www.pmichaud.com/2006/pres/yapc-parsers/start.html
Parrot Target Practice, Will Coleda
http://www.pmichaud.com/2006/pres/yapc-apl/start.html
Pm
[perl #39050] Build failure in compilers/pge/pgc.pir
The build process for the current (Tue May 2 07:15:06 2006 UTC) parrot snapshot dies when trying to run compilers/pge/pgc.pir: Is this still the case with later versions of Parrot -- i.e., can I close this ticket? Pm
Re: [perl #39050] Build failure in compilers/pge/pgc.pir
On Thu, 29 Jun 2006, Patrick R. Michaud via RT wrote: The build process for the current (Tue May 2 07:15:06 2006 UTC) parrot snapshot dies when trying to run compilers/pge/pgc.pir: Is this still the case with later versions of Parrot -- i.e., can I close this ticket? The last time I looked, on May 30, the problem was still there. Beyond that, I wouldn't know. -- Andy Dougherty [EMAIL PROTECTED]
features of and declaring Mapping|Set|Hash values|variables
Lately I've been wanting to cross-apply features of the Set type to
the Mapping type, as well as of the Hash type to both of those, as I
see all of these as being very similar to each other conceptually and
in some cases interchangeable.
1. Looking at the language in Synopsis 6 for data types, I see:
Set Unordered Seqs that allow no duplicates
JunctionSets with additional behaviours
PairSeq of two elements that serves as an one-element Mapping
Mapping Pairs with no duplicate keys
I would like to know if Mapping.does(Set) and whether I could use the
full range of Set operators on them, as I would like to do?
My impression is that it be reasonable to define a generic Mapping as
being a Set whose elements are all constrained to be Pairs, and
further that all keys of those pairs are distinct; eg:
subset Mapping of Set where {
all(.members).does(Pair) and +all(.members.map:{.key}) == +all(.members)
};
If this is true, then I suggest rewording the above line in Synopsis
6 to better clarify the situation, like this:
Mapping Set of Pairs that allow no duplicate Pair keys
It would be very useful to employ Set operations like subset() or
union() or difference() etc on Mappings, that return Mappings. With
such binary operators, each Mapping element has to match entirely as
a whole Pair, having both the same key and same value. In the case
of union(), if any source Pairs have the same keys but different
values, the union() would fail due to the unique key constraint, with
similar force to dividing by zero in a non-NaN setting.
2. Similarly, I would like to know if Hash.does(Mapping) and so that
we can therefore use all the Set and Mapping operators on Hashes, but
that their output is Hashes. Likewise very useful.
3. I missed the syntax for declaring anonymous Set or Mapping in the
Synopsis. Has it been defined yet?
Something that is distinct from:
[1,2] # Array
(1,2) # Seq
{1=2,3=4} # Hash
(1=2) # Pair in positional context
1=2 # Pair in named context
all(1,2,3) # Junction
Eg, do we need to use keywords:
set(1,2,3)
mapping(1=2,3=4)
Or can this be accomplished without such keywords?
I am assuming we don't have to invoke some new() because these are
built-in basic types.
4. Since they are already known to be unique, is it possible to get
an actual Set returned when invoking something akin to .keys or
.pairs or a Mapping or Hash? Or do we need to always construct such
ourself by wrapping the call with a set() or all(), in order to use
set operations on them? Would the latter case be inefficient or
verbose?
5. I'm wondering about syntax for using Sets like Junctions. Eg, if
I want to see if one set is a proper subset of another, can I say
this:
all($s1) === any($s2)
Or do I have to rewrap their members into explicit Junctions first like this:
all($s1.members) === any($s2.members)
I am ignoring for the moment that Set probably declares named
operators that let me do this:
$s2.subset($s1)
I don't want to have to use the second syntax if I don't have to,
since I like consistency with Junction syntax.
The same questions apply to using Mappings and Hashes as Sets.
6. From on my readings of Synopsis 6,9,12, it looks like you can
declare a Hash whose keys are restricted to non-empty strings like
this:
subset FooName of Str where { $^n ne '' };
subset FooHash of Hash{FooName} of Bar;
or
subset FooHash of Hash{Str where { $^n ne '' }} of Bar;
Then if you declare a variable or routine parameter of type FooHash,
someone can assign/pass only a Hash value to it whose keys are all
non-empty strings.
So is that a reasonable interpretation?
7. If so, then can I use the same syntax with a Mapping, which looks
like a Hash but that it is immutable; eg:
subset FooMap of Mapping{FooName} of Bar;
Then if you declare a variable or routine parameter of type FooMap,
someone can assign/pass only a Mapping value to it whose keys are all
non-empty strings.
8. Similar question but with a Set:
subset FooSet of Set{FooName};
Will this work to make a Set that can only have non-empty strings as members?
9. If you declare a parameter of a type that does Foo, and you pass
an argument that is a different type that does Foo, but neither of
them is of type Foo, will the compiler accept the binding (though it
may fail at runtime)?
Thanks. -- Darren Duncan
Re: features of and declaring Mapping|Set|Hash values|variables
Darren Duncan wrote:
1. Looking at the language in Synopsis 6 for data types, I see:
Set Unordered Seqs that allow no duplicates
JunctionSets with additional behaviours
PairSeq of two elements that serves as an one-element Mapping
Mapping Pairs with no duplicate keys
I would like to know if Mapping.does(Set) and whether I could use the
full range of Set operators on them, as I would like to do?
My impression is that it be reasonable to define a generic Mapping as
being a Set whose elements are all constrained to be Pairs, and
further that all keys of those pairs are distinct; eg:
subset Mapping of Set where {
all(.members).does(Pair) and +all(.members.map:{.key}) == +all(.members)
};
Hmm. I still think a more generic Collection makes this more correct.
subset Set of Collection where {
all(.members) =:= one(.members);
}
subset Mapping of Collection where {
all(.members).does(Pair) and
all(.members).key =:= one(.members).key;
}
ie, being a Set is introducing a constraint, which is then duplicated in
the Mapping type. Now, you could argue that the Set constraint is
shadowed by the Mapping constraint and the constraints analysis system
could prove it does not need to be applied, but that's quite a high
level thing to expect the compiler to do at this point, I think.
However the above definitions, in my opinion, miss the potential of
parametric roles.
If this is true, then I suggest rewording the above line in Synopsis
6 to better clarify the situation, like this:
Mapping Set of Pairs that allow no duplicate Pair keys
It would be very useful to employ Set operations like subset() or
union() or difference() etc on Mappings, that return Mappings.
2. Similarly, I would like to know if Hash.does(Mapping) and so that
we can therefore use all the Set and Mapping operators on Hashes, but
that their output is Hashes. Likewise very useful.
How about;
Mapping Collection of Pairs that allow no duplicate Pair keys.
If Collection is parametric it must be a role, which means that we
can't directly subset it; we use role composition instead (I'm assuming
that we can use where{} during role composition).
role Set of Collection[Item] where { all(.members) =:= one(.members) };
# one of these
role Mapping of Collection[Pair] where {
all(.members).key =:= one(.members).key
};
# what is a pair, anyway?
role Pair of Seq[Item,Item] {
method key of Item { .item(0) }
method value of Item { .item(1) }
};
role HEK of Seq[Str, Item] does Pair;
role Hash of Collection[HEK] does Mapping;
role ArrayItem of Seq[Int, Item] {
method index of Int { .item(0) }
method value of Item { .item(1) }
};
role Array of Collection[ArrayItem] where {
all(.members).index == one(.members).index;
} {
method post_circumfix:[ ](Int $index) of Item {
my $seq = first { .index == $index } .members;
$seq ?? $seq.value :: undef;
}
}
There are some problems with the above, notably Pair could be
parametric, and the Array post_circumfix method should be an lvalue return.
I'm terribly sorry I haven't dedicated more time to developing this into
a working prototype module for Perl 5. RSN I hope.
3. I missed the syntax for declaring anonymous Set or Mapping in the
Synopsis. Has it been defined yet?
Something that is distinct from:
[1,2] # Array
(1,2) # Seq
{1=2,3=4} # Hash
(1=2) # Pair in positional context
1=2 # Pair in named context
all(1,2,3) # Junction
Eg, do we need to use keywords:
set(1,2,3)
mapping(1=2,3=4)
Or can this be accomplished without such keywords?
I am assuming we don't have to invoke some new() because these are
built-in basic types.
I don't see a problem with .new() for these types, which some might
consider arcane.
set() doesn't work for the Perl 5 prototypes, too many modules want to
use $object-set().
Users who want a shorthand can use a module that lets them write ⟦ ⟧ etc
(say).
4. Since they are already known to be unique, is it possible to get
an actual Set returned when invoking something akin to .keys or
.pairs or a Mapping or Hash? Or do we need to always construct such
ourself by wrapping the call with a set() or all(), in order to use
set operations on them? Would the latter case be inefficient or
verbose?
Interesting idea. I guess that there are many places where a list or
array type is specified where it should be a set.
5. I'm wondering about syntax for using Sets like Junctions. Eg, if
I want to see if one set is a proper subset of another, can I say
this:
all($s1) === any($s2)
Or do I have to rewrap their members into explicit Junctions first like this:
all($s1.members) === any($s2.members)
I am ignoring for the moment that Set probably declares named
operators that let me do this:
$s2.subset($s1)
I don't want to have to use the second syntax if I don't have to,
since I like consistency with Junction syntax.
[svn:perl6-synopsis] r9724 - doc/trunk/design/syn
Author: audreyt
Date: Thu Jun 29 19:34:45 2006
New Revision: 9724
Modified:
doc/trunk/design/syn/S02.pod
Log:
* S02: kolibrie++ noticed that a heredoc without a semicolon is confusing,
so we reasserted the Perl5 semantics by a TimToady++ ruling.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podThu Jun 29 19:34:45 2006
@@ -1811,15 +1811,18 @@
Heredocs are no longer written with C , but with an adverb on
any other quote construct:
-print qq:to/END/
+print qq:to/END/;
Give $amount to the man behind curtain number $curtain.
END
-Other adverbs are also allowed:
+Other adverbs are also allowed, as are multiple heredocs within the same
+expression:
-print q:c:to/END/
+print q:c:to/END/, q:to/END/;
Give $100 to the man behind curtain number {$curtain}.
END
+Here is a $non-interpolated string
+END
=item *
IMCC Register Allocation Algorithm
Hi Everyone, Currently IMCC uses a Graph Coloring based Register allocation algorithm. The implementation is a trimmed down version of Brigg's Allocator. I came across this research paper that talks about the new register allocation algorithm Linear Scan Allocationfor dynamically compiled languages. Parrot perfectly fits the mold of dynamically compiled language. The Linear Scan Allocator is faster at register allocation process and seems to have the same execution time for the code. For more information please refer to the research paper from IBM on Liner Scan Allocation http://www.research.ibm.com/jalapeno/papers/toplas99.pdf Let me know what your thoughts are and would it be worth implementing this algorithm to see how it performs compared to graph coloring algorithm. Please share your thoughts accordingly -- Thanks, Vishal
Re: IMCC Register Allocation Algorithm
On Thursday 29 June 2006 20:20, Vishal Soni wrote: Let me know what your thoughts are and would it be worth implementing this algorithm to see how it performs compared to graph coloring algorithm. Please share your thoughts accordingly It'd be very useful not only to have two implementations to compare with a real benchmark on actual programs, but to do incidental IMCC cleanups while implementing the other system. (Pluggable allocators is probably too much work, but minor refactorings and documentations are always nice, if nothing else.) -- c
