Pheme, Custom Classes, and Multi-Dispatch
Perhaps I don't understand how :multi works (and I would love to see more documentation and will even write tests, as I don't think the existing ones cover all of the cases). I added a custom Cons class to Pheme, as that's what a Lisp/Scheme needs. This means that I also need some more logic for is_deeply() to compare two Cons objects appropriately. The attached patch is my first attempt. It doesn't work and I'm not sure why. I don't know if installing is() from Test::More (it's a multi sub) overrides the multi is() in Pheme::Test. I don't know if dispatch even *gets* to my custom is() either. I don't even know if what I'm trying to do should be possible, at least the way I'm doing it. I'm stumped and I appreciate any advice, especially from someone who knows how multi dispatch ought to work in Parrot and someone who knows how the current system does work. -- c === lib/PhemeSymbols.pir == --- lib/PhemeSymbols.pir (revision 16710) +++ lib/PhemeSymbols.pir (local) @@ -15,14 +15,77 @@ .return() .end +.namespace [ 'Pheme::Cons' ] + +.sub _initialize :load + .local pmc cons_class + newclass cons_class, 'Pheme::Cons' + + addattribute cons_class, 'head' + addattribute cons_class, 'tail' +.end + +.sub 'head' :method + .param pmc new_head :optional + .param int have_head :opt_flag + + unless have_head goto return_head + setattribute self, 'head', new_head + .return( new_head ) + + return_head: + .local pmc head + head = getattribute self, 'head' + .return( head ) +.end + +.sub __get_integer :method + .local pmc elem + elem = self.'head'() + + .local int elem_defined + elem_defined = defined elem + + if elem_defined goto count_tail + .return( 0 ) + + count_tail: + .local int count + count = 0 + elem = self + + loop_start: + inc count + elem = elem.'tail'() + elem_defined = defined elem + if elem_defined goto loop_start + + loop_end: + .return( count ) +.end + +.sub 'tail' :method + .param pmc new_tail :optional + .param int have_tail :opt_flag + + unless have_tail goto return_tail + setattribute self, 'tail', new_tail + .return( new_tail ) + + return_tail: + .local pmc tail + tail = getattribute self, 'tail' + .return( tail ) +.end + .namespace [ 'Pheme' ] -.sub __resolve_at_runtime :multi( ResizablePMCArray ) - .param pmc args - .param pmc more_args :slurpy +.sub __resolve_at_runtime :multi( Pheme::Cons ) + .param pmc args :slurpy - unshift more_args, args - .return( more_args ) + .local pmc result + result = __list_to_cons( args :flat ) + .return( result ) .end .sub __resolve_at_runtime :multi( string ) @@ -40,48 +103,50 @@ .return( result ) return_list: - unshift args, symbol_name - .return( args ) + + result = __list_to_cons( symbol_name, args :flat ) + .return( result ) .end -.sub car - .param pmc list +.sub __list_to_cons + .param pmc args :slurpy - .local int count - count = list + .local int cons_type + cons_type = find_type 'Pheme::Cons' - if count 0 goto really_car - .return( list ) + .local pmc result + result = new cons_type - really_car: - .local pmc first_item - first_item = list[0] + .local int args_count + .local pmc arg - .return( first_item ) + loop_start: + args_count = args + unless args_count goto loop_end + arg= pop args + result = cons( arg, result ) + goto loop_start + + loop_end: + .return( result ) .end -.sub cdr - .param pmc list +.sub car + .param pmc cons - .local pmc iter - iter = new .Iterator, list - iter = 0 + .local pmc head + head = cons.'head'() - .local pmc result - result = new .ResizablePMCArray + .return( head ) +.end - # skip the first element - .local pmc elem - elem = shift iter +.sub cdr + .param pmc cons - iter_loop: - unless iter goto iter_end - elem = shift iter - push result, elem - goto iter_loop + .local pmc tail + tail = cons.'tail'() - iter_end: - .return( result ) + .return( tail ) .end .sub include_file @@ -98,9 +163,16 @@ .param pmc l .param pmc r - unshift r, l + .local int cons_type + cons_type = find_type 'Pheme::Cons' - .return( r ) + .local pmc result + result = new cons_type + + result.'head'( l ) + result.'tail'( r ) + + .return( result ) .end .sub 'write' :multi() @@ -130,6 +202,11 @@ .sub __make_empty_cons .local pmc result - result = new .ResizablePMCArray + + .local int cons_type + cons_type = find_type 'Pheme::Cons' + + .local pmc result + result = new cons_type .return( result ) .end === lib/PhemeTest.pir == --- lib/PhemeTest.pir (revision 16710) +++ lib/PhemeTest.pir (local) @@ -13,78 +13,20 @@ diag = find_global 'Test::More', 'diag' is_deeply = find_global 'Test::More', 'is_deeply' - store_global 'Pheme', 'plan', plan - store_global 'Pheme', 'is', is - store_global 'Pheme', 'ok', ok - store_global 'Pheme', 'diag', diag + store_global 'Pheme', 'plan', plan + store_global
Re: Where can I find a Perl 6 langauge reference?
Thomas Wittek [EMAIL PROTECTED] writes: Where is the best place to take a look at, when I want to start experimenting with Perl 6 and pugs? As your email address looks german, maybe my (german) notes about compiling my first Pugs is helpful to you: http://dresden-pm.org/cgi-bin/twiki/view/PM/PugsFirstBlood GreetinX Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Re: Where can I find a Perl 6 langauge reference?
* Steffen Schwigon [EMAIL PROTECTED] [2006-05-19 09:10]: As your email address looks german, Thomas is a fellow cologne.pm’er. :-) http://dresden-pm.org/cgi-bin/twiki/view/PM/PugsFirstBlood Nice work. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Where can I find a Perl 6 langauge reference?
Is there a perl6-user-doc wiki? It might be a great way to write documentation. Free collaborative documentation for a free collaborative language - what could be better? Let alone Wikipedia - Wikis can be even greater than you think. For example, check out this site: http://wiki.osdc.org.il/index.php/Larry_Wall_-_Present_Continuous%2C_Future_Perfect It is a transcript of a talk given by Larry at a conference. All of transcription work was done by volunteers. On 5/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * Steffen Schwigon [EMAIL PROTECTED] [2006-05-19 09:10]: As your email address looks german, Thomas is a fellow cologne.pm'er. :-) http://dresden-pm.org/cgi-bin/twiki/view/PM/PugsFirstBlood Nice work. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ -- Amir Elisha Aharoni, http://aharoni.blogspot.com/ We're living in pieces, I want to live in peace. - Thurston Moore __ Please avoid sending me Word or PowerPoint attachments http://www.gnu.org/philosophy/no-word-attachments.html
Re: [ARCH] Classes moving into namespaces; parrot reserved namespace
On May 16, 2006, at 19:32, Chip Salzenberg wrote: There's is a problem with the naming of classes and their associated namespaces that must be addressed. The first question is: why is the namespace associated, or - in other words - why does a class Chas a namespace instead of Cisa namespace. The latter is AFAIK true for Perl6. See below[1] for more. Creating Parrot classes currently requires _typed_ namespaces, that is, namespaces where more than one object can have the same fully-qualified name. Parrot's default namespace allows that there be both a namespace and another object (often a class) with the same name. Namespace typing is a fine feature for any given HLL to use, but a basic function of Parrot like class creation must not depend on it. Why? It's implemented and is working. There's also a more subtle flaw: a violation of the principle of least repetition. Given a class (let's say it's a Perl 6 class) named foo::bar, two distinct Parrot entities, both named foo;bar, must be created to implement it: the class object, and its method namespace. This is weak design. For example, it makes removing (or renaming) a class into a multi-step operation. This would simple be solved with the class Cisa namespace. So here are the changes I'm planning to PDD today: (1) By default, the implementation objects of a class foo;bar will consist of: a namespace named foo;bar a class object named foo;bar;__parrot_class This isn't quite correct. The first line is actually: a namespace named $HLL;foo;bar which leads to another can of worms[2], IMHO. I don't like the __parrot_class magic. A flag bit (PObj_is_class_FLAG) set in the namespace PMC could achieve the same. But it's still requiring the construction of 2 objects. [2] The implicit $HLL in all namespace operations seems to complicate all tasks that cross namespace boundaries, e.g. the whole compiler tool chain or parrot libs. I'd really prefer an explicit toplevel namespace, which is under the control of the code generation. ==[ Entering alternative universe ]=== An alternativeq design has the _classes_ being the visible objects, with namespaces being externally anonymous and only visible by indirecting through the classes that use them. This alternative is, of course, entirely feasible, but it has downsides. This looks like the Cisa approach. First, some namespaces would become more equal than others: class namespaces, vs. namespaces unrelated to classes, would require a new technique for lookup, or else some convention that classes would provide a namespace interface; neither of these options appeals, especially since the base namespace interface is 'hash', and I doubt that classes responding to the hash interface meets anybody's idea of elegant. [1] The interface problem. A namespace needs a distinct interface - one that isn't used by any class like 'Hash'. Or IOW - given the strong relationship between namespaces and classes - the namespace interface is a part of the class interface, which we actually already have (in some parts): VTABLE methods: find_method, add_method, remove_method set_attr_str, get_attr_str opcodes: addattribute, removeattribute The latter 2 should probably be virtualized via the interface too. The 'remove'-thingies are all unimplemented. Now given that an attribute is just the general case[3], it would correspond to the untyped namespace interface. The '*_method' interface deals with subs in a namespace, which is one part of the typed interface. [3] e.g. for Python: m = o.f # get_attribute, returning a 'bound' method # a limited currying operation There is of course sill the chicken and egg problem of namespaces, when we want to sublass a namespace, which might need some vtable invocation directly via the namespace vtable as opposed to find_method. This all is also strongly related to interfaces, which we actually don't have yet. A vtable is implementing all internally used interfaces for all PMCs and classes. A vtable, split into distinct interface slots, could be much more flexible, as each PMC could define it's own (and only the needed) interface functions. E.g. obj-vtable-scalar_if-abs() # scalar interface slots -neg() ... ns -vtable-ns_if-find_sub() # namespace interface slots ... This would allow to customize methods per interface or per PMC/class (when that's the only one with that specific interface). leo
Re: :immediate behaviour
On Thu, May 18, 2006 at 01:01:13PM +0200, Klaas-Jan Stol wrote: hi, if I understand correctly, the :immediate pragma makes the sub which has this pragma run immediately after parsing (well, at least before running the program) Suppose I have this code: .sub loadstuff :immediate # load stuff .end .sub main dostuff( ) end .end Then, running this code will start running the loadstuff( ) again (because main doesn't have the :main pragma, and loadstuff() is at the top of the file). My concern is, is this the desired effect? Shouldn't the :immediate subs only be run once? So, in effect shouldn't they be skipped (if they're at the top of the file, where execution starts when :main is missing) when running the program? I'm a fan of explicitness and orthogonality -- I don't see that :immediate should silently imply and don't use this sub as :main. If a sub other than the first one listed is main, mark it as :main and be done with it. Pm
Windows Binaries for Pugs
Hi All, I just wanted to let you know that there are some Windows binaries of Pugs avaliable from Jonathan Worthington (http://www.jwcs.net/~jonathan/perl6/). They seem to be a bit out of date (last update was at Monday, 10-Apr-2006 05:29:30 CDT) but should get you started. Regards, Chris
Re: Windows Binaries for Pugs
At this stage, are binaries even worth it? Judging from my lurking on #perl6, things are moving so fast that anything but a regular nightly-built binary would be too out of date. Seems like svn is the way to go. -James At 11:58 AM -0400 5/19/06, Chris Yocum wrote: Hi All, I just wanted to let you know that there are some Windows binaries of Pugs avaliable from Jonathan Worthington (http://www.jwcs.net/~jonathan/perl6/http://www.jwcs.net/~jonathan/perl6/). They seem to be a bit out of date (last update was at Monday, 10-Apr-2006 05:29:30 CDT) but should get you started. Regards, Chris -- -- James Peregrino - http://people.dce.harvard.edu/~peregrin/business-card.html
Re: Windows Binaries for Pugs
True. Although, I would say that for those who only want to tinker with the language, this might be the most convenient way to do so. I have already started to work with it and I am liking what I am seeing. On 5/19/06, James Peregrino [EMAIL PROTECTED] wrote: At this stage, are binaries even worth it? Judging from my lurking on #perl6, things are moving so fast that anything but a regular nightly-built binary would be too out of date. Seems like svn is the way to go. -James At 11:58 AM -0400 5/19/06, Chris Yocum wrote: Hi All, I just wanted to let you know that there are some Windows binaries of Pugs avaliable from Jonathan Worthington (http://www.jwcs.net/~jonathan/perl6/http://www.jwcs.net/~jonathan/perl6/). They seem to be a bit out of date (last update was at Monday, 10-Apr-2006 05:29:30 CDT) but should get you started. Regards, Chris -- -- James Peregrino - http://people.dce.harvard.edu/~peregrin/business-card.html
Re: Where can I find a Perl 6 langauge reference?
On Thu, May 18, 2006 at 03:29:38PM -0700, David Romano wrote: On 5/18/06, Michael Mathews [EMAIL PROTECTED] wrote: Like Thomas, I'm interested in having a go, in my case I'd like to install something I can play with. The link is appreciated but what I was hoping for was a simple set of instructions for just installing Perl6 (maybe I missed it--sorry) . Does such a thing exist? What OS are you using? I'm using OS X. I installed subversion, installed Haskell and the other necessary libraries for Haskell to build pugs, checked out the latest from the SVN repository (I think it's http://svn.openfoundry.org/pugs/), and built it. There's an INSTALL file in the root directory that explains things more. Is there such a thing as an idiots' guide to getting Pugs working on OS X? Cos every time I try, some missing library or whatever trips me up. -- David Cantrell | A machine for turning tea into grumpiness Planckton: n, the smallest possible living thing
[svn:perl6-synopsis] r9302 - doc/trunk/design/syn
Author: larry
Date: Fri May 19 11:13:09 2006
New Revision: 9302
Modified:
doc/trunk/design/syn/S03.pod
Log:
Refined hyperops a bit.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podFri May 19 11:13:09 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 8 Mar 2004
- Last Modified: 18 May 2006
+ Last Modified: 19 May 2006
Number: 3
- Version: 34
+ Version: 35
=head1 Changes to existing operators
@@ -326,7 +326,7 @@
(1,1,2,3,5) »+« (1,2,3,5,8); # (2,3,5,8,13)
-If one argument is insufficiently dimensioned, Perl upgrades it:
+If either argument is insufficiently dimensioned, Perl upgrades it:
(3,8,2,9,3,8) - 1; # (2,7,1,8,2,7)
@@ -354,11 +354,26 @@
[[1, 2], 3] »+« [4, [5, 6]] #[[1,2] »+« 4, 3 »+« [5, 6]]
# == [[5, 6], [8, 9]]
-You are not allowed to define your own hyper operators, because they are
-supposed to have consistent semantics derivable entirely from the modified
-scalar operator. If you're looking for a mathematical vector product, this
-isn't where you'll find it. A hyperoperator is one of the ways that you
-can promise to the optimizer that your code is parallelizable.
+More generally, hyper operators work recursively for any object
+matching the CEach role even if the object itself doesn't support
+the operator in question:
+
+Bag(3,8,[2,Seq(9,3]],8) - 1; # Bag(2,7,[1,Seq(8,2)],7)
+Bag(3,8,[2,Seq(9,3)],8) - (1,1,1,1); # Bag(2,7,[1,Seq(8,2)],7)
+Bag(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Bag(2,7,[2,Seq(9,3)],7)
+
+In particular, tree node types with CEach semantics enable visitation:
+
+$tree.».foo; # short for $tree.each: { .foo }
+
+You are not allowed to define your own hyper operators, because they
+are supposed to have consistent semantics derivable entirely from
+the modified scalar operator. If you're looking for a mathematical
+vector product, this isn't where you'll find it. A hyperoperator
+is one of the ways that you can promise to the optimizer that your
+code is parallelizable. (The tree visitation above is allowed to
+have side effects, but it is erroneous for the meaning of those side
+effects to depend on the order of visitation.)
=head1 Reduction operators
[svn:perl6-synopsis] r9303 - doc/trunk/design/syn
Author: larry
Date: Fri May 19 11:45:34 2006
New Revision: 9303
Modified:
doc/trunk/design/syn/S03.pod
Log:
Typo from aufrank++.
Feeble attempt to make .foo optional on nodes that only contain children.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podFri May 19 11:45:34 2006
@@ -360,11 +360,11 @@
Bag(3,8,[2,Seq(9,3]],8) - 1; # Bag(2,7,[1,Seq(8,2)],7)
Bag(3,8,[2,Seq(9,3)],8) - (1,1,1,1); # Bag(2,7,[1,Seq(8,2)],7)
-Bag(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Bag(2,7,[2,Seq(9,3)],7)
+Bag(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Bag(2,7,[0,Seq(7,1)],7)
In particular, tree node types with CEach semantics enable visitation:
-$tree.».foo; # short for $tree.each: { .foo }
+$tree.».foo; # short for $tree.each: { .?foo; .».foo }
You are not allowed to define your own hyper operators, because they
are supposed to have consistent semantics derivable entirely from
Re: Windows Binaries for Pugs
On Fri, May 19, 2006 at 01:24:57PM -0400, James Peregrino wrote: At this stage, are binaries even worth it? Judging from my lurking on #perl6, things are moving so fast that anything but a regular nightly-built binary would be too out of date. Seems like svn is the way to go. Binaries are definitely worth it to give people something to play with (especially on difficult platforms like Windows). It doesn't have to be the latest and greatest, it just has to implement a large-enough feature set. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Hyperop question
$Larry has just updated the pod:
doc/trunk/design/syn/S03.pod
=head1 Changes to existing operators
-If one argument is insufficiently dimensioned, Perl upgrades it:
+If either argument is insufficiently dimensioned, Perl upgrades it:
(3,8,2,9,3,8) - 1; # (2,7,1,8,2,7)
@@ -354,11 +354,26 @@
[[1, 2], 3] »+« [4, [5, 6]] #[[1,2] »+« 4, 3 »+« [5, 6]]
# == [[5, 6], [8, 9]]
+More generally, hyper operators work recursively for any object
+matching the CEach role even if the object itself doesn't support
+the operator in question:
+
+Bag(3,8,[2,Seq(9,3]],8) - 1; # Bag(2,7,[1,Seq(8,2)],7)
+Bag(3,8,[2,Seq(9,3)],8) - (1,1,1,1); # Bag(2,7,[1,Seq(8,2)],7)
+Bag(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Bag(2,7,[2,Seq(9,3)],7)
That last one puzzles me - by this info:
-If one argument is insufficiently dimensioned, Perl upgrades it:
+If either argument is insufficiently dimensioned, Perl upgrades it:
(3,8,2,9,3,8) - 1; # (2,7,1,8,2,7)
shouldn't it be (not knowing what to do w/ Bag or Seq):
Bag(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Bag(2,7,[0,Seq(8,3)],7)
or:
Bag(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Bag(2,7,[0,Seq(7,2)],7)
(the '2' being 'upgraded to [2,2] or [2,2,2] or [2, Seq(2,2)])
+
+In particular, tree node types with CEach semantics enable visitation:
+
+$tree.».foo;# short for $tree.each: {
.foo }
+
+You are not allowed to define your own hyper operators, because they
+are supposed to have consistent semantics derivable entirely from
+the modified scalar operator. If you're looking for a mathematical
+vector product, this isn't where you'll find it. A hyperoperator
+is one of the ways that you can promise to the optimizer that your
+code is parallelizable. (The tree visitation above is allowed to
+have side effects, but it is erroneous for the meaning of those side
+effects to depend on the order of visitation.)
a
Andy Bach, Sys. Mangler
Internet: [EMAIL PROTECTED]
VOICE: (608) 261-5738 FAX 264-5932
Truth is eternal, knowledge is changeable.
It is disastrous to confuse them.
-- Madeleine L'Engle
Re: Hyperop question
Never mind: New Revision: 9303 Modified: doc/trunk/design/syn/S03.pod Log: Typo from aufrank++. Feeble attempt to make .foo optional on nodes that only contain children. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod (original) +++ doc/trunk/design/syn/S03.pod Fri May 19 11:45:34 2006 @@ -360,11 +360,11 @@ Bag(3,8,[2,Seq(9,3]],8) - 1; # Bag(2,7,[1,Seq(8,2)],7) Bag(3,8,[2,Seq(9,3)],8) - (1,1,1,1); # Bag(2,7,[1,Seq(8,2)],7) -Bag(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Bag(2,7,[2,Seq(9,3)],7) +Bag(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Bag(2,7,[0,Seq(7,1)],7) well, at least I guessed right ;- a Andy Bach, Sys. Mangler Internet: [EMAIL PROTECTED] VOICE: (608) 261-5738 FAX 264-5932 Truth is eternal, knowledge is changeable. It is disastrous to confuse them. -- Madeleine L'Engle
Re: packages vs. classes
On Thu, May 18, 2006 at 03:17:36PM -0700, Chip Salzenberg wrote:
: What's the relationship in perl6 between namespaces and classes?
Hmm, well, that's hard to put one's finger on, but to the first
approximation namespaces are for declarational names, while classes
can really only name things operationally. So packages, modules,
classes, roles, subsets, enums, etc. all pretend they are packages
for purposes of naming from a global root. Any extra semantics are
defined by the objects that support each type of declarator. But
as container objects they all support the Package role, or some such.
The situation is analogous to the filesystem. We have a /proc
filesystem nowadays because it's convenient to name certain
abstractions in the OS as if they were ordinary files despite most
of the actual magic being defined elsewhere. It would be possible
to access classes et al. only via the mechanisms supplied by the
metaobject protocols, but that would be kind of like the bad old
days when ps(1) had to rummage around in /dev/kmem to figure out what
to say.
: For example, given:
:
: package Foo { sub bar {...} }
: class Corge { method grault {...} }
:
: Is the full name of foo Foo::foo?
Yes, assuming that Foo is a top-level package name, and that you meant bar.
: What's the full name of grault?
Just as if the class were a package:
Corge::grault
Though nowadays for clarity we often write these as
Foo::bar
Corge::grault
instead.
: Is there a common role that Foo and Corge both do?
As bare names they can be taken in context to mean either the package
or the type. When necessary we can disambiguate these:
Foo.^{$x} call .{$x} on the type metaobject
Foo::{$x} call .{$x} on the package object
Contextually, though, a bare package name is generally taken to be a pun on
the type unless followed by ::. So
my Corge $foo;
is not really saying much about the Corge package except that there has
to be one, and to the extent that the Corge type supports certain methods
at declaration time, those names appear to be in the Corge package.
It's quite possible that the Corge type has metamethods that let us
get at unnameable behavior, but that would generally be construed as
violating encapsulation--hopefully for a good reason--but the public
interface of a type should generally be presented declarationally
via packages and the objects they contain.
A consequence of all this is that when you use any type declarator:
module M ...
class C ...
role R ...
subset S ...
enum E ...
the name is referring to both the package and the type simultaneously,
and the type is allowed to present whatever public interface it likes,
generally via the package. It also presents an internal declarational
interface to the innards of the declarator, so that metamethods like
has and does and is are given meaning in your class declaration.
The type also presumably controls which traits make sense on various
declarations.
Interestingly, even the tag groups of module exports are done with
the package interface currently. The is export (:DEFAULT) trait
merely pokes the current name down into the ::DEFAULT subpackage of
the module, and it hopefully can become very efficient to import a
prepackaged set of symbols as a lump.
If this isn't answering what you were asking, please ask s'more,
and I'll try to reply when I'm not busy having a grandbaby.
Larry
Re: packages vs. classes
'Course, I left out everything about prototype objects there... The name Foo also (in context) represents an uninitialized object of the class in question. Any object, initialized or not, can get at its type handlers by saying Foo.meta $foo.meta and, in fact, the Foo.^bar syntax is just short for Foo.meta.bar. The Foo object maybe therefore be used to reason about objects of a class, but the Foo object itself is not the class. Foo.meta is the real class object. Foo itself is just a Foo that hasn't been defined yet. Foo.isa(Class) is false, because there's no Class type in Perl 6 as far as Perl 6 is concerned. The type of metaobject Foo.meta might be called Class if that's what the metaobject protocol decides it should be, but Perl the Language doesn't care. If so, then Foo.meta.isa(Class) would be true. But Foo.isa(Class) is still false. The purpose of all this is to support prototype-based programming as well as class-based programming. Assuming either one or the other (in the absence of appropriate declaration) is a kind of encapsulation violation of the .meta interface. Larry
hyp-op examples of a Bag type in S03
I know they were just introduced, but I have a question about the conceptual validity of the following statements in S03, which appear in the newly edited hyper-operators section: Bag(3,8,[2,Seq(9,3]],8) - 1; # Bag(2,7,[1,Seq(8,2)],7) Bag(3,8,[2,Seq(9,3)],8) - (1,1,1,1); # Bag(2,7,[1,Seq(8,2)],7) Bag(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Bag(2,7,[0,Seq(7,1)],7) First of all, my concept of a Bag is that it is like a Set, in that it is an *un-ordered* collection of things, but unlike a Set, each distinct element can appear more than once in a Bag (eg, the '8'). Correct me if you think differently about that. Now, say you phrased the lines above slightly differently, like this: $bag1 = Bag(3,8,[2,Seq(9,3]],8); $bag2 = Bag(3,8,[2,Seq(9,3)],8); $bag3 = Bag(3,8,[2,Seq(9,3)],8); $bag1 - 1; # Bag(2,7,[1,Seq(8,2)],7) $bag2 - (1,1,1,1); # probably the same $bag3 - (1,1,2,1); # ? Now, the $bag1 example is unambiguous; all Bag members are having 1 added to them. But $bag3 does not seem predictable to me. Since a Bag is unordered, how do we know, with the $bag3 example, which elements are having a 2 added to them and which elements are having a 1? The only way that $bag3 could be predictable is if a Bag is ordered. But in that case, how is a Bag different than a Seq? Now, I realize that technically the source code in the actual S03 does display the members of each Bag in a sequence (the sequence they appear in the code itself), but what would that example compile to (would that seq info be lost), and what information would the compiled code carry to associate the values on the left and right hand sides of the hyper-operator? So I would appreciate if the S03 examples could be explained as to why they would work, or alternately please replace 'Bag' with 'Seq'. Thank you. -- Darren Duncan
Re: hyp-op examples of a Bag type in S03
Er, I meant to say subtracted where I said added. -- Darren Duncan
Re: packages vs. classes
On Fri, May 19, 2006 at 12:35:11PM -0700, Larry Wall wrote:
If this isn't answering what you were asking, please ask s'more,
and I'll try to reply when I'm not busy having a grandbaby.
adCONGRATULATIONSvance :-)
Packages, modules, classes, roles, subsets, enums, etc. all pretend they
are packages for purposes of naming from a global root. Any extra
semantics are defined by the objects that support each type of declarator.
But as container objects they all support the Package role, or some such.
The above paragraph is about half of what I was asking. It contains a bit
of bad news: it imples that Parrot can't assume that each HLL only has one
namespace-ish class. But I think that particular guilletine blade was
already on its way down.
The other half:
Your distinction between the type object and the class object is more than a
little disturbing to the current design issues I'm facing. You write:
Foo.^{$x} call .{$x} on the type metaobject
Foo::{$x} call .{$x} on the package object
Two and a half questions and a proposal on that.
Q1: How do you disambiguate type from package in the Perl 6 namespace?
Given a class Foo::Bar, is Foo::Bar:: the package and Foo::Bar the
type? Or what?
Q1.5: If I asked why the circumflex is in there, would I regret it?
Q2: What is the object reference relationship among Foo::, Foo::Bar the
type, and Foo::Bar:: ? (Where are the object reference arrows?)
Proposal:
In Parrotland, it seems at the moment that Parrot type objects might be best
implemented as specializations of Parrot namespace objects. Consider:
Defining a new class creates exactly one named object.
Aliasing (e.g. importing) a class requires exactly one namespace operation.
Removing a class requires deleting exactly one namespace entry.
There is no confusion as to which object is the class object.
There is no confusion as to what should be looked up where.
As something of a probing attack -- to provoke informative rebuttal -- I'd
like to propose that type objects should do Package. What say?
--
Chip Salzenberg [EMAIL PROTECTED]
Re: packages vs. classes
On Fri, May 19, 2006 at 12:53:29PM -0700, Larry Wall wrote: and, in fact, the Foo.^bar syntax is just short for Foo.meta.bar. So, you anticipated my half-question. The type of metaobject Foo.meta might be called Class if that's what the metaobject protocol decides it should be, but Perl the Language doesn't care. If so, then Foo.meta.isa(Class) would be true. But Foo.isa(Class) is still false. OK, in my previous message, you should apparently read metaobject for type object. But I think the questions still apply, as does the proposal that all _metaobjects_ that currently are correlated with packages should instead just _do_ Package. -- Chip Salzenberg [EMAIL PROTECTED]
Re: packages vs. classes
On Fri, May 19, 2006 at 02:51:55PM -0700, Chip Salzenberg wrote: On Fri, May 19, 2006 at 12:53:29PM -0700, Larry Wall wrote: The type of metaobject Foo.meta might be called Class if that's what the metaobject protocol decides it should be, but Perl the Language doesn't care. If so, then Foo.meta.isa(Class) would be true. But Foo.isa(Class) is still false. OK, in my previous message, you should apparently read metaobject for type object. But I think the questions still apply, as does the proposal that all _metaobjects_ that currently are correlated with packages should instead just _do_ Package. And again I must correct myself, the above doesn't make sense. Based on what I'm seeing, the Perl 6 type object is the thing that claims the primary name associated with a class. Foo::Bar is the type object. The metaobject seems to be anonymous. And the package seems to be fairly questionable... given how generic you want to be, the Perl 6 implmentation probably can't assume that there is exactly one package associated with a given type object, either directly or indirectly. -- Chip Salzenberg [EMAIL PROTECTED]
[svn:perl6-synopsis] r9304 - doc/trunk/design/syn
Author: larry
Date: Fri May 19 16:29:33 2006
New Revision: 9304
Modified:
doc/trunk/design/syn/S03.pod
Log:
dduncan++ points out that bags are unordered, which actually forces asymmetry.
Clarified difference between ».foo and ».?foo
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podFri May 19 16:29:33 2006
@@ -330,7 +330,13 @@
(3,8,2,9,3,8) - 1; # (2,7,1,8,2,7)
-When using a unary operator, only put it on the side of the single operand:
+In fact, this is the Ionly form that will work for an unordered type
+such as a Bag:
+
+ Bag(3,8,2,9,3,8) - 1; # Bag(2,7,1,8,2,7) ~~ Bag(1,2,2,7,7,8)
+
+When using a unary operator, only put the hyper on the side of the
+single operand:
@negatives = -« @positives;
@@ -358,13 +364,18 @@
matching the CEach role even if the object itself doesn't support
the operator in question:
-Bag(3,8,[2,Seq(9,3]],8) - 1; # Bag(2,7,[1,Seq(8,2)],7)
-Bag(3,8,[2,Seq(9,3)],8) - (1,1,1,1); # Bag(2,7,[1,Seq(8,2)],7)
-Bag(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Bag(2,7,[0,Seq(7,1)],7)
+Bag(3,8,[2,Seq(9,3)],8) - 1; # Bag(2,7,[1,Seq(8,2)],7)
+Seq(3,8,[2,Seq(9,3)],8) - (1,1,2,1); # Seq(2,7,[0,Seq(7,1)],7)
In particular, tree node types with CEach semantics enable visitation:
-$tree.».foo; # short for $tree.each: { .?foo; .».foo }
+$tree.».foo; # short for $tree.foo, $tree.each: { .».foo }
+
+If not all nodes support the operation, you need a form of it that
+specifies the call is optional:
+
+$tree.».?foo; # short for $tree.?foo, $tree.each: { .».?foo }
+$tree.».*foo; # short for $tree.*foo, $tree.each: { .».*foo }
You are not allowed to define your own hyper operators, because they
are supposed to have consistent semantics derivable entirely from
@@ -373,7 +384,9 @@
is one of the ways that you can promise to the optimizer that your
code is parallelizable. (The tree visitation above is allowed to
have side effects, but it is erroneous for the meaning of those side
-effects to depend on the order of visitation.)
+effects to depend on the order of visitation. [Conjecture: we could
+allow dependencies that assume top-down visitation and only leaves
+sibling calls unordered.])
=head1 Reduction operators
Re: Windows Binaries for Pugs
I think nightly builds are great, especially considering that most people don't have a Haskell environment set up. Keep the builds coming! Especially ones with parrot and perl5 integration :-) (Yes, I'm lazy) Rutger On Fri, 19 May 2006 12:33:56 -0500 [EMAIL PROTECTED] wrote: On Fri, May 19, 2006 at 01:24:57PM -0400, James Peregrino wrote: At this stage, are binaries even worth it? Judging from my lurking on #perl6, things are moving so fast that anything but a regular nightly-built binary would be too out of date. Seems like svn is the way to go. Binaries are definitely worth it to give people something to play with (especially on difficult platforms like Windows). It doesn't have to be the latest and greatest, it just has to implement a large-enough feature set. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: packages vs. classes
On Fri, May 19, 2006 at 03:25:43PM -0700, Chip Salzenberg wrote: : Based on what I'm seeing, the Perl 6 type object is the thing that claims : the primary name associated with a class. Foo::Bar is the type object. : The metaobject seems to be anonymous. And the package seems to be fairly : questionable... given how generic you want to be, the Perl 6 implmentation : probably can't assume that there is exactly one package associated with a : given type object, either directly or indirectly. I think the only constraint on it is that Foo::Bar.meta can't point to two different objects. But .meta isn't a real method--it's more like a notation representing the blessing, in P5 terms. Certainly different packages could share the same .meta object if the particular kind of metaobject it points to chooses to store all the state in the package rather than the metaobject. In that sense the package is just a handy place to put publicly named class state. Going the other way, $object.meta makes no guarantees that the metaobject it points to has any name. Could be completely anonymous, or an eigenclass, or whatever. Presumably metaobjects that are associated with a package can tell you that name somehow, perhaps even by stringification. But which operations can succeed through .meta will depend on what .meta.isa, as it were. In this, Perl is so OO that it even encapsulates the OO, so Perl is agnostic even about the extent to which Perl is an OO language. In Perl 6, all objects are blessed equally, but some objects are blessed more equally than others... So what's in a name? One could say that .meta is functioning more like a name sigil than like a method, and the Real Name of the metaobject is Foo::^Bar or some such, if it needs a name. Then maybe Foo::Bar is just a strange hash. Or maybe it has its own sigil. But from the viewpoint of Dorothy the programmer, it's the package that presents the public interface Oz::Wizard, and it's the metaobject that's trying to hide behind the metacurtain. And as in the original, sometimes the official story needs a bit of tweaking. But for now the Package of Oz is great and glorious, and doubtless you should be quaking in fear. :) All that and several bucks'll get you a Starbucks... Larry
