Call For Pumpking: Do you want a Ponie?
Two and a half years ago, Fotango announced their sponsorship of the Perl 6 effort, in the form of the Ponie project to port the Perl 5 runtime to the Parrot Virtual Machine. For the past year, Nicholas Clark has worked as the pumpking for Ponie as part of his work for Fotango. He's recently moved on from Fotango and it's time for Ponie to do so as well. We're currently interviewing for a new pumpking to take over his role. The Ponie pumpking needs to manage the route we take to get the Ponie source code from where it is now to its eventual goal: a Perl 5 runtime fully integrated with the Parrot virtual machine. You won't start from nothing. Nick and Artur Bergman before him have developed a plan to get us to the glorious future and have made a significant dent in that plan, but there's still a huge amount to do. You'll need to be able to work with the existing plan and expand and revise it as necessary, based on feedback and discoveries made while working through the current tasks. Ponie is an open source project. While you'll likely be doing a lot of the heavy lifting, you also need to be able to nurture the community and implementation. Contributors will be submitting patches. You'll need to work with them to refine their patches and recruit some of them as core committers. This is primarily a C hacking role rather than a Perl hacking role. (That is, you'll be coding Perl, not coding /in/ Perl.) You absolutely need a good working knowledge of C and would be well-served to have some experience managing large projects written in C. And yes, an intimate knowledge of Perl's internals would definitely come in handy. There's one thing about Ponie that might really appeal to you if you have a pretty good handle on Perl 5's internals. Ponie is the perfect opportunity to clean up and refactor the guts you hate most. It's a huge refactoring project and you'll have more than a little freedom to make things faster, cleaner, saner, more maintainable and generally _better_. If you're interested in being the next Ponie pumpking, please submit a brief bio to [EMAIL PROTECTED] We won't consider applications posted publicly. Over the coming weeks, Nicholas Clark and I will work to pick his successor. Nick and I look forward to hearing from you. Jesse --
Re: Some thoughts on threading
On Mon, 12 Dec 2005 12:18:47 +1300, Sam Vilain wrote:
On Thu, 2005-12-08 at 17:16 +0100, Ron Blaschke wrote:
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software.
[1] He starts with The biggest sea change in software development since
the OO revolution is knocking at the door, and its name is Concurrency.
Perhaps have a read of:
http://svn.openfoundry.org/pugs/docs/AES/S17draft.pod
Interesting read, thanks.
Just some braindump. How about async calls and future.
sub f is async returns future {
# your favorite expensive operations here
return $something;
}
my $x = f();
# some more expensive operations here
# this part executes concurrently
# with f() ...
# ... until the future is read for
# the first time; this will block until
# the value is available
say($x);
Ron
Ron
relational data models and Perl 6
All, P.S. What follows is rough and will be smoothed out or reworked. I propose, perhaps redundantly, that Perl 6 include a complete set of native language constructs for a relational data model, akin to that introduced in E. F. Codd's classic paper, A Relational Model of Data for Large Shared Data Banks (a copy of which is at http://www.acm.org/classics/nov95/toc.html ), and also discussed at length in such books as C. J. Date's Database in Depth (O'Reilly, 2005). Codd's paper itself (see 1.5) says that the necessary pieces are good candidates for a sub-language of any typical programming language. The actual relational data model (which is not the same as SQL per se) is expressable in terms of mathematics, such as sets and predicate calculus, and therefore I believe that Perl 6 already has most of what is needed in the language already. Essentially it comes down to better handling of data sets. It is very possible, then that all which may be necessary is an extension of the standard data types, or operators, or builtin functions, and/or utilization of the Perl 6 object model. What I would like, for example, are standard data types which are akin to Relations/RelVars/etc (tables/rowsets), Tuples (rows), Attributes (fields), Sets (enums), Domains (data types) and such. Largely these already map to existing Perl 6 entities: * a Domain is like a class that defines a set of possible values, and each value can be multi-part; equal to a perl Class * an Attribute stores a value which is a perl Object * a Tuple is an associative array having one or more Attributes, and each Attribute has a name or ordinal position and it is typed according to a Domain; this is like a restricted Hash in a way, where each key has a specific type * a Relation is an unordered set of Tuples, where every Tuple has the same definition, as if the Relation were akin to a specific Perl class and every Tuple in it were akin to a Perl object of that class Fairly standard so far. Specifically what I would like to see added to Perl, if that doesn't already exist, is a set of operators that work on Relations, like set operations, such as these (these bulleted definitions from Database in Depth, 1.3.3, some context excluded): * Restrict - Returns a relation containing all tuples from a specified relation that satisfy a specified condition. For example, we might restrict relation EMP to just the tuples where the DNO value is D2. * Project - Returns a relation containing all (sub)tuples that remain in a specified relation after specified attributes have been removed. For example, we might project relation EMP on just the ENO and SALARY attributes. * Product - Returns a relation containing all possible tuples that are a combination of two tuples, one from each of two specified relations. Product is also known variously as cartesian product, cross product, cross join, and cartesian join (in fact, itis just a special case of join, as we'll see in Chapter 5). * Intersect - Returns a relation containing all tuples that appear in both of two specified relations. (Actually, intersect also is a special case of join.) * Union - Returns a relation containing all tuples that appear in either or both of two specified relations. * Difference - Returns a relation containing all tuples that appear in the first and not the second of two specified relations. * Join - Returns a relation containing all possible tuples that are a combination of two tuples, one from each of two specified relations, such that the two tuples contributing to any given result tuple have a common value for the common attributes of the two relations (and that common value appears just once, not twice, in that result tuple). NOTE, This kind of join was originally called the natural join. Since natural join is far and away the most important kind, however, it's become standard practice to take the unqualified term join to mean the natural join specifically, and I'll follow that practice in this book. * Divide - Takes two relations, one binary and one unary, and returns a relation consisting of all values of one attribute of the binary relation that match (in the other attribute) all values in the unary relation. Now, all that I'm saying, could be implemented as a Perl 6 module, and if necessary I can do this for illustrative purposes, but I believe that this is essentially simple and something analagous should be included in the core language for similar reasons that junctions and PDL are. I also want to make clear that this functionality is entirely about better support for data processing with Perl native variables, and has nothing to do with external data repositores such as SQL databases. Though I anticipate that one could extend or override built-ins so that they interact with remote databases instead of internal variables, such as with the concept of sub-classing or role
Re: relational data models and Perl 6
On 12/15/05, Darren Duncan [EMAIL PROTECTED] wrote:
I propose, perhaps redundantly, that Perl 6 include a complete set of
native
Okay, I'm with you here. Just please stop saying native and core.
Everyone.
rant
Remember, syntax in Perl 6 can be stuffed in a library like anything
else. You don't get much out of making it truly core (that is, in
the language without any use statements) besides the fact that you tie
yourself to all the idiosyncrasies of a single implementation instead
of allowing multiple.
Let's talk about what the module would look like, and then in a
different discussion talk about which modules are used by default.
/rant
language constructs for a relational data model, akin to that
introduced in E. F. Codd's classic paper, A Relational Model of Data
for Large Shared Data Banks (a copy of which is at
http://www.acm.org/classics/nov95/toc.html ), and also discussed at
length in such books as C. J. Date's Database in Depth (O'Reilly,
2005). Codd's paper itself (see 1.5) says that the necessary pieces
are good candidates for a sub-language of any typical programming
language.
I would like to hear from Ovid and Dave Rolsky on this issue too, as
they seem to have been researching pure relational models.
Essentially it comes down to better handling of data sets.
Cool. I've recently been taken by list comprehensions, and I keep
seeing set comprehensions in my math classes. Maybe we can steal
some similar notation.
What I would like, for example, are standard data types which are
akin to Relations/RelVars/etc (tables/rowsets), Tuples (rows),
Attributes (fields), Sets (enums), Domains (data types) and such.
Largely these already map to existing Perl 6 entities:
* a Domain is like a class that defines a set of possible values,
and each value can be multi-part; equal to a perl Class
* an Attribute stores a value which is a perl Object
* a Tuple is an associative array having one or more Attributes, and
each Attribute has a name or ordinal position and it is typed
according to a Domain;
this is like a restricted Hash in a way, where each key has a specific type
Hmm. I would say it's a hash not so much. For instance, the
difference between an array and a tuple in many languages is that an
array is homogeneously-typed--that's what allows you to access it
using runtime values (integers). Tuples are heterogeneously-typed, so
you can't say
my $idx = get_input();
say $tuple[$idx];
(Pretend that Perl 6 is some other language :-), because the compiler
can't know what type it's going to say.
In the same way, I see a hash as homogeneously-typed, because you can
index it by strings. What you're referring to as a tuple here would
be called a record or a struct in most languages.
* a Relation is an unordered set of Tuples, where every Tuple has
the same definition, as if the Relation were akin to a specific Perl
class and every Tuple in it were akin to a Perl object of that class
When you say unordered set (redundantly, of course), can this set be
infinite? That is, can I consider this relation (using made-up set
comprehension notation):
{ ($x,$y) where $x $y (in) Int, $x = $y }
And do stuff with it?
Specifically what I would like to see added to Perl, if that doesn't
already exist, is a set of operators that work on Relations, like set
operations, such as these (these bulleted definitions from Database
in Depth, 1.3.3, some context excluded):
* Restrict - Returns a relation containing all tuples from a
specified relation that satisfy a specified condition. For example,
we might restrict relation EMP to just the tuples where the DNO value
is D2.
Well, if we consider a relation to be a set, then we can use the set operations:
my $newrel = $emp.grep: { .DNO === 'D2' };
I don't know what EMP, DNO, and D2 are...
* Project - Returns a relation containing all (sub)tuples that
remain in a specified relation after specified attributes have been
removed. For example, we might project relation EMP on just the ENO
and SALARY attributes.
Hmm... Well, if we pretend that records and hashes are the same thing
for the moment, then:
my $newrel = $emp.map: { .:ENO SALARY };
(See the new S06 for a description of the .: syntax)
* Union - Returns a relation containing all tuples that appear in
either or both of two specified relations.
Already have it:
$rel1 (+) $rel2
* Difference - Returns a relation containing all tuples that appear
in the first and not the second of two specified relations.
Already have it:
$rel1 (-) $rel2
* Join - Returns a relation containing all possible tuples that are
a combination of two tuples, one from each of two specified
relations, such that the two tuples contributing to any given result
tuple have a common value for the common attributes of the two
relations (and that common value appears just once, not twice, in
that result tuple). NOTE, This kind of join was
Fully-qualified symbols and exportation
What should this mean?
package Foo;
sub Bar::baz is export { ... }
The problem is in how callers request this export.
use Foo baz;
Looks weird, as this demonstrates:
package Foo;
sub baz is export { I am Foo::baz }
sub Bar::baz is export { I am Bar::baz }
Clearly, if this is allowed at all, the use line should import Foo::baz.
But this looks wrong:
use Foo Bar::baz
In fact the only way this makes sense to me at all is if Bar::baz had
already been exported by Bar, and now Foo wants to change the meaning of
that sub. The is export trait is just for formal signature matching /
documentation purposes then. What is the scope of this override?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Fully-qualified symbols and exportation
On 12/15/05, Gaal Yahas [EMAIL PROTECTED] wrote:
What should this mean?
package Foo;
sub Bar::baz is export { ... }
The problem is in how callers request this export.
use Foo baz;
Hmm. My gut reaction is that that is the correct way to request that export.
Looks weird, as this demonstrates:
package Foo;
sub baz is export { I am Foo::baz }
sub Bar::baz is export { I am Bar::baz }
And that is certainly not allowed. Let's think about why.
It seems that there are two abstractions that are getting muddled into
one here, and that's what's causing the confusion. There's a package,
the thing that you put names in, and then there's the thing that you
use.
Perhaps that latter thing is called a module, and a module's job is to
collect exports and export them. Saying module Foo opens up
package Foo as well as creating a scope for is exports to register
themselves.
module Foo;
package *Bar;
sub baz() is export {...} # defines Bar::baz() that is exported
when you use Foo
That seems like it could get a little bit tricky. Maybe module and
package are really competing for the same scope, so that in order to
get the behavior above:
module Foo {
package *Bar;
sub baz() is export {...}
}
And the first example would die with baz() doesn't have anywhere to
be exported.
Hmm. Details aside, I think that's the right approach. The thing
that gets used (or IMPORTed) it different from a package, and it is
the thing that collects exports. It collects them by basename only,
so that:
module Foo {
sub *Foo::baz() is export {...}
sub *Bar::baz() is export {...}
}
Is a name conflict in the exporter.
Luke
