Re: txt vs OO [was: Re: Proposal to make class method non-inheritable]
On Tue, 25 Oct 2005, Larry Wall wrote: But we're trying to design the OO features (indeed, all of Perl 6) such that you can usefully cargo cult those aspects that are of immediate interest without being forced to learn the whole thing. It's not the number one design goal, but it's right up there. So you're talking about a positive, tame form of cargo cult, giving the latter a good name... Michele -- you need a brain hack. or a brain of any sort. try a nematode first. the small incremental improvement won't be such a shock. then you can graduate to segmented worm brains. - Uri Guttman in clpmisc, Array Sort Using Regex Matching Fails
[perl #36642] [TODO] PGE Data::Dump'ing
[coke - Sat Jul 23 14:25:11 2005]: PGE's match objects should be compatible with Data::Dumper. (probably a simple rename of the dump sub will resolve this.) Done (r9573). The old dump format is still available as before (since PGE's tests currently rely on it), but I added a C__dump method that is compatible with Data::Dumper. As part of this change I also moved the dump code out of the PGE.pbc file itself and made it part of PGE/Dumper.pir . Thanks, Pm
[perl #37537] [BUG] coroutine segfaults
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #37537] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37537 --- osname= linux osvers= 2.4.21-27.0.2.elsmp arch= i386-linux-thread-multi cc= gcc 4.0.0 20050516 (Red Hat 4.0.0-6) --- Flags: category=core severity=high ack=no --- I'm running into a problem with segfaults in PGE; I think I have it narrowed down to a problem with coroutines somewhere, or perhaps it's in the GC code. The attached test program exhibits the bug; it simply creates a coroutine and calls it repeatedly in an infinite loop. On the 229th iteration or thereabouts, I get a segfault (changing the code causes the actual number of iterations to vary). The attached typescript file shows the output and the resulting segfault. This is from a fresh build of r9571. Changing the coroutine to a subroutine doesn't end up in a segfault (at least not as far as I let it run). Any help or suggestions appreciated! Pm --- Summary of my parrot 0.3.0 (r9570) configuration: configdate='Tue Oct 25 17:43:50 2005' Platform: osname=linux, archname=i386-linux-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC', load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATHSHELL .sub main :main $P0 = find_global PGE::Rule, inner loop: $P1 = $P0(abc) print $P1 print \n goto loop .end .namespace [ PGE::Rule ] .sub inner .param pmc mob .local pmc corou corou = find_global PGE::Rule, _inner_coroutine corou = clone corou corou(mob) .return (mob) .end .sub _inner_coroutine .param pmc mob .yield () fail_forever: .yield () goto fail_forever .end Script started on Tue 25 Oct 2005 06:07:12 PM CDT [EMAIL PROTECTED] trunk]$ ./parrot sf6.pir abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc *** glibc detected *** ./parrot: free(): invalid next size (fast): 0x09fffea0 *** === Backtrace: = /lib/libc.so.6[0x38e124] /lib/libc.so.6(__libc_free+0x77)[0x38e65f] ./parrot(mem_sys_free+0x11)[0x8085ad1] ./parrot(Parrot_Sub_destroy+0x2d)[0x81f174d] ./parrot(Parrot_dod_sweep+0x140)[0x80d0a20] ./parrot[0x80d0f5a] ./parrot(Parrot_forall_header_pools+0x63)[0x80cfcf3] ./parrot(Parrot_dod_ms_run+0xc2)[0x80d1062] ./parrot(Parrot_do_dod_run+0x1b)[0x80d110b] ./parrot[0x80cee66] ./parrot[0x80ceef1] ./parrot[0x80cf358] ./parrot(new_string_header+0x3b)[0x80cf8cb] ./parrot(string_make_empty+0x13)[0x808d033] ./parrot(Parrot_String_init+0x15)[0x81fb825] ./parrot(pmc_new+0x2e)[0x8090aee] ./parrot[0x81650a4] ./parrot(Parrot_convert_arg+0x1ac)[0x816544c] ./parrot(parrot_pass_args+0x15a)[0x816596a] ./parrot(Parrot_Sub_invoke+0x1a9)[0x81f1b19] ./parrot(Parrot_invokecc_p+0x63)[0x80e8bc3] ./parrot(runops_slow_core+0x96)[0x8167596] ./parrot(runops_int+0x152)[0x8163c02] ./parrot(runops+0xcf)[0x816644f] ./parrot[0x810] ./parrot(Parrot_runops_fromc_args+0x2a)[0x816674a] ./parrot(Parrot_runcode+0x221)[0x80c9da1] ./parrot(Parrot_runcode+0x4d)[0x80c9bcd] ./parrot(main+0x862)[0x8084492] /lib/libc.so.6(__libc_start_main+0xdf)[0x33fd5f] ./parrot[0x8083001] === Memory map: 0016f000-0017 r-xp 0016f000 00:00 0 002c8000-002cd000 r-xp 08:01 136423 /lib/libcrypt-2.3.5.so 002cd000-002ce000 r-xp 4000 08:01 136423
Compiling parrot with c++
Guy, As a follow-up to a discussion a few days ago about binding parrot to C++ functions, is making it possible to compile parrot with a C++ compiler a 'Bad Thing'? If anything, it should strengthen the code base. I had a dabble a few weeks ago to see how big a job it would be, and quickly came across a KR function prototype bletch in auto/alignptrs/test_c.in. Although it's too soon to say, the main tasks would be: * avoid C++ keywords (e.g. namespace/class) * add explicit casting * be more careful with typing * add appropriate extern Cs If I see positive feedback, I'll suggest that we create a branch for an ongoing project from which improvements can be cherry-picked. If it's pointless due to showstoppers (e.g. like inline assembler not being supported) then I'll sweep the idea under the carpet. (And if I get mixed reaction, I'll just submit some small patches to fix a few things that I found) Cheers, Nick
[perl #31147] [TODO] metadata in bytecode
This was a very old TODO from the TODO file: Is this now covered with the recent changes? [coke - Sun Aug 15 13:27:07 2004]: Bytecode Metadata (source line number info, symbol table)
Re: txt vs OO [was: Re: Proposal to make class method non-inheritable]
On Wed, Oct 26, 2005 at 09:36:48AM +0200, Michele Dondi wrote: : On Tue, 25 Oct 2005, Larry Wall wrote: : : But we're trying to design the OO features (indeed, all of Perl 6) : such that you can usefully cargo cult those aspects that are of : immediate interest without being forced to learn the whole thing. : It's not the number one design goal, but it's right up there. : : So you're talking about a positive, tame form of cargo cult, giving the : latter a good name... Yes, I hack on more languages than just Perl. :-) I use the term cargo cult for lack of a better term, and when I do so I tend to use it as a verb rather than a noun. By cargo culting I mean the process by which most of us learn to use new technology. We appropriate inappropriately; we have to start using a thing wrongly before we can start using it rightly. When we're very young, we learn by picking up objects and stuffing them into our mouths. That's not the appropriate way for an adult to treat most objects, but it's the right way for a toddler to treat an object, and it's the parents' responsibility to child-proof the room so the child doesn't chew on power cords and such. So another way to say what I said is that we're trying to make Perl 6 relatively safe for people who are just starting to use bits of it inappropriately in order to learn it. The term cargo cult also has some religious connotations, and to a small extent I mean those too. The religious wars fought in computer communities often arise among those with the least understanding of the deep issues. People much more easily fall into tribal behavior than into philosophical behavior. A deep understanding of bikesheds is that they're meant to hold bicycles, and it doesn't really matter what color they are. But when you first discover a bikeshed, you might mistake it for a tribal monument of some sort. It's obviously more important than the bicycle; after all, it's bigger. And we might attract more new husbands or wives from other tribes if we paint it attractively. So we spend a lot of time painting the outside while the bicycle is inside rusting. And the bicycle is what's important, because we should be reaching out to other tribes, not waiting for them to come to us. Well, hey, my metaphor is probably painted the wrong color. But maybe it's only by using analogies inappropriately that we can begin to understand how to use them appropriately. Larry
Re: txt vs OO [was: Re: Proposal to make class method non-inheritable]
--- Larry Wall wrote:
On Tue, Oct 25, 2005 at 05:24:52PM +0200, Michele Dondi wrote:
: But maybe that's just me. Whatever, I guess that the {casual,average}
: programmer may be scared by its richness and complexity.
But we're trying to design the OO features (indeed, all of Perl 6)
such that you can usefully cargo cult those aspects that are of
immediate interest without being forced to learn the whole thing.
It's not the number one design goal, but it's right up there.
Interesting. I just finished reading Stroustrup's thoughts on evolution
and language design at:
http://www.research.att.com/~bs/rules.pdf
and noticed he is similarly concerned about making his language easier
for the casual/novice programmer:
If you are a physicist needing to do a few calculations a week,
an expert in some business processes involving software, or a
student learning to program, you want to learn only as many
language facilities as you need to get your job done.
He also argues in favour of general features over specialized ones:
C++0x will not be a Windows language or a Web Language ...
which reminded me of people characterizing Perl as a text processing
language or a CGI language.
Just as Perl 5 evolved Perl 4 from a scripting/text processing language
to a general purpose one (with CPAN modules filling many specialized
niches), Perl 6 seems to be evolving still further down that path,
being applicable to more and varied domains than Perl 5 was.
/-\
Send instant messages to your online friends http://au.messenger.yahoo.com
Re: Compiling parrot with c++
Nick~ On 10/26/05, Nick Glencross [EMAIL PROTECTED] wrote: Guy, As a follow-up to a discussion a few days ago about binding parrot to C++ functions, is making it possible to compile parrot with a C++ compiler a 'Bad Thing'? I like the idea, but I tend to like C++ more than reason would dictate. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
+$arg changed to :$arg
I should point out that one of the major changes in the most recent
S6 is that named arguments are now marked by : rather than +, with
:foo($bar) being the way to declare parameter $bar but give it the
external name of foo. A + is now reserved to mark mandatory
parameters, though it's redundant on positionals. A mandatory
named parameter is now marked +:$nonoptionaloption.
But the colon sigil might be more general than that. In rvalue context
the prefix it could be a modifier on the following term, causing
it to return a pair or pairs when it would return a scalar item.
The generated name is derived from the immediately surrounding
container, where that might be the variable name, the hash key,
or the array index. An unsubscripted container counts as a scalar.
So we'd get:
TermShort for
:$foo :foo($foo)
:@baz :baz(@baz) (not @bar.pairs)
:%bar :bar(%bar) (not @baz.pairs)
:%hasha :a(%hasha)
:%hash{$k} $k = %hash{$k}
:@array[42] 42 = @array[1]
Again, as with :foo, we're banking on the initial double-dot as
a mnemonic indicating that the following thing should be in pair
context. I wouldn't bother proposing this except that it maps nicely
onto the parameter syntax for named args, and it also eliminates some
amount of redundancy.
The last three forms are more arguable than the first three, especially
since they probably aren't valid formal parameters. We kind of need
a subscript modifier instead:
%hash:a :a(%hasha)
%hash:{$k} $k = %hash{$k}
@array:[42] 42 = @array[1]
@array:[] @array.pairs
%hash:{}%hash.pairs
Unfortunately that would force
$obj.sort:{...}
to be written
$obj.sort :{...}
But then, I'd surely love to get rid of that colon on magical
blocks. It's the main place where Ruby is still prettier than Perl 6,
bikesheddily speaking. Even
$obj.sort: {...}
would be a vast improvement, though that has ambiguities with indirect
object syntax. Maybe we can still finesse it somehow. It's really
only ambiguous if there's a bare identifier in front somewhere:
foo $obj.sort: {...}
While we could decide based on the presence of such an unresolved
work, I think that allowing methods as list ops is actually more
important than indirect object syntax, so I think we can say that
.foo: is always a list operator form of .foo, and you have to say
foo ($obj.sort): {...}
to get the other thing. But in either case the trailing colon
postfix indicates a following list. And I think people will
naturally want the colon to bind more tightly to the immediately
foregoing thing anyway. Like placeholder syntax, indirect object
syntax is really only for simple cases.
Er, looks like I have to revise S6 yet again...
Larry
Re: new sigil
And in fact, its very existence defies another implicit principle of mine, that is, the principle of partial definition: Defining a new type or instance can only break a previously typechecking program by making it ambiguous. The idea behind that is that at some time you may realize that oen of your types already obeys another type, and declare that it conforms to that interface. But you don't go the other way around, undeclaring that an interface holds, without your program having been erroneous in the first place. Declaring that a new interface holds (so long as it actually does) shouldn't break anything that was already correct. The principle also has strong implications with library code: including a new library but doing nothing with it shouldn't start randomly breaking stuff. (Unless, of course, it breaks the rules and does crazy stuff, in which case anything goes) Is this better expressed as side-effect-free programming or loose coupling/tight cohesion? Rob
Re: +$arg changed to :$arg
Larry Wall skribis 2005-10-26 6:44 (-0700): I should point out that one of the major changes in the most recent S6 is that named arguments are now marked by : rather than +, with :foo($bar) being the way to declare parameter $bar but give it the external name of foo. A + is now reserved to mark mandatory parameters, though it's redundant on positionals. A mandatory named parameter is now marked +:$nonoptionaloption. If optional parameters get ?, then why don't give mandatory parameters !? Or, if you wish: if mandatory parameters get +, then why do optional parameters not get -? # The mandatory/optional thing could even be postfix, which results in # clearer code than the stacked +:$: # # sub foo ($this!, $is!, :$mandatory!, $optional?, $really?) I do like the s/+/:/ change, though! Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: +$arg changed to :$arg
Larry~ On 10/26/05, Larry Wall [EMAIL PROTECTED] wrote: So we'd get: :@array[42] 42 = @array[1] Do you mean C :@array[42] 42 = @array[42] ? The last three forms are more arguable than the first three, especially since they probably aren't valid formal parameters. We kind of need a subscript modifier instead: @array:[42] 42 = @array[1] Same question. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: new sigil
On Tue, Oct 25, 2005 at 10:25:48PM -0600, Luke Palmer wrote:
: Yeah, I didn't really follow his argument on that one. I, too, think
: that the one() junction in general is silly, especially for types.
Well, I think it's silly too. I'm just trying to see if we need to
reserve the syntax in case someone figures out a way to make it
unsilly in some dialect.
: When you say Dog^Cat, you're saying I want something that either
: conforms to the Dog interface or the Cat interface, but *definitely
: not both*! Why the heck would you care about that? Does there
: really arise a situation in which your code will be erroneous when the
: variable conforms to both interfaces?
:
: And in fact, its very existence defies another implicit principle of
: mine, that is, the principle of partial definition: Defining a new
: type or instance can only break a previously typechecking program by
: making it ambiguous. The idea behind that is that at some time you
: may realize that oen of your types already obeys another type, and
: declare that it conforms to that interface. But you don't go the
: other way around, undeclaring that an interface holds, without your
: program having been erroneous in the first place. Declaring that a
: new interface holds (so long as it actually does) shouldn't break
: anything that was already correct.
And that's basically what we decided in Portland when we went to
set types rather than junctional types. And that's why I'm kind of
pushing for a natural bundling via juxtaposition that can be viewed
as ANDing the constraints:
:(Any Dog Cat Fish ¢T $dc)
That says much the same thing as
:($ where {
.does(Any) and
.does(Dog) and
.does(Cat) and
.does(Fish) and
.does(Class) and ¢T := $dc.class and
.does(Scalar) and $dc := $_;
}
)
And basically, if | can be used to construct type sets, it ends up
meaning exactly the same thing:
:(Any|Dog|Cat|Fish ¢T $dc)
But maybe that just means we don't need it.
Larry
Re: +$arg changed to :$arg
On Wed, Oct 26, 2005 at 10:06:25AM -0400, Matt Fowles wrote: : Larry~ : : On 10/26/05, Larry Wall [EMAIL PROTECTED] wrote: : So we'd get: : : :@array[42] 42 = @array[1] : : Do you mean C :@array[42] 42 = @array[42] ? Yes. I was changing it because 42 : 1 :: foo : a, but I flubbed. : The last three forms are more arguable than the first three, especially : since they probably aren't valid formal parameters. We kind of need : a subscript modifier instead: : : @array:[42] 42 = @array[1] : : Same question. Same answer. Larry
Re: +$arg changed to :$arg
On Wed, Oct 26, 2005 at 04:02:06PM +0200, Juerd wrote: : Larry Wall skribis 2005-10-26 6:44 (-0700): : I should point out that one of the major changes in the most recent : S6 is that named arguments are now marked by : rather than +, with : :foo($bar) being the way to declare parameter $bar but give it the : external name of foo. A + is now reserved to mark mandatory : parameters, though it's redundant on positionals. A mandatory : named parameter is now marked +:$nonoptionaloption. : : If optional parameters get ?, then why don't give mandatory parameters : !? : : Or, if you wish: if mandatory parameters get +, then why do optional : parameters not get -? : : # The mandatory/optional thing could even be postfix, which results in : # clearer code than the stacked +:$: : # : # sub foo ($this!, $is!, :$mandatory!, $optional?, $really?) : : I do like the s/+/:/ change, though! That's interesting. Then we could say that = default implies ?. I think I like it. It would also ease transition of Pugs not to change the meaning of + immediately, but that's a secondary consideration. And really, + ought to mean a * but with a minimum of 1. Larry
Re: +$arg changed to :$arg
It also means you could write a prototype that looks like :(!, !, !, ?, ?) We don't need no stinkin' _. There's more than one way to not care. (I guess that means that in addition to supporting interesting values of undef, we also support interesting values of not caring...) But does that mean we can have a don't care with a default: :(!, !, !, ='foo', =42) We can even give them names without caring: :(:a!, :b!, :c!, :bar='foo', :answer=42) :-) One slightly serious ramification of the : switch is that the space is required after the colon indicating a null invocant. method doit (: $a, $b, $c) But it's only slightly serious, considering that it has a smiley. Larry
Re: +$arg changed to :$arg
On 10/26/05, Larry Wall [EMAIL PROTECTED] wrote: A mandatory named parameter is now marked +:$nonoptionaloption. Woo! :) -John
Re: [perl #31147] [TODO] metadata in bytecode
Will Coleda via RT [EMAIL PROTECTED] wrote: This was a very old TODO from the TODO file: Is this now covered with the recent changes? [coke - Sun Aug 15 13:27:07 2004]: Bytecode Metadata (source line number info, symbol table) Hard to say; depends if it's talking about HLL source line stuff and so on. HLL debug things are next on my todo list (I'll send a mail out soon with some thoughts, then hopefully people writing compilers can give me some input on what they want/need). But we've had line number info for PIR and PASM source for a while; my recent stuff was just about getting the filename right. Not sure what symbol table metadata is referring to. If it's HLL related and about attaching metadata to bytecode, that's part of the HLL debug stuff. So, maybe this stays with the clarification that it's about HLL debug data; #31145 can surely be closed though, as the assembly line numbers etc are done. Jonathan
Re: +$arg changed to :$arg
Larry Wall skribis 2005-10-26 7:31 (-0700):
One slightly serious ramification of the : switch is that the space
is required after the colon indicating a null invocant.
method doit (: $a, $b, $c)
Or, we could separate it with a . instead of a :, perhaps?
This is already more or less very heavily associated with invocants
anyway.
Hmmm...
method .doit (...) { ... }
method $foo.doit () { ... }
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Ways to add behavior
On Tue, Oct 25, 2005 at 05:17:40PM -0400, Stevan Little wrote:
: Larry,
:
: On Oct 25, 2005, at 4:37 PM, Larry Wall wrote:
: On Mon, Oct 24, 2005 at 06:33:20AM -0700, Ashley Winters wrote:
: : # behavior through prototype -- guessing realistic syntax
: : Base.meta.add_method(
: : do_it = method ($arg) {
: : say doing $arg!;
: : });
: :
: :
: : # or, just add it to a single instance
: : $x.meta.add_method(
: : do_it = method ($arg) {
: : say doing $arg!;
: : });
:
: I don't have a comment on your actual question, but I'd like to use
: this opportunity to point out the symmetry of Base and $x at this
: point, and the fact that .meta can't simply call .add_method in the
: metaclass, or it would lose track of the original invocant, which is
: needed to convey both class and instance information. I'm not sure
: it's even possible to say
:
: $m = $x.meta;
: $m.addmethod($arg);
:
: The only way that can work is if $x.meta returns a shadow class that
: is prebound only to $x. (Though that might explain how .addmethod
: knows it's only adding a method to the object.)
:
: This is actually the principe behind the Ruby style singleton methods
: (the shadow class), it basically creates an anon-class which inherits
: from $x's original class, then it rebinds/blesses $x into the anon-
: class. It is very simple really :)
Sure, but such a heavy behavior shouldn't be implied merely by trying
to get at the metaclass.
: As for if this is/should be accessible through .meta, i am not sure
: that is a good idea. The reason being is that .meta brings with it
: the idea of metaclasses, which then relates to classes, and so now
: the user is thinking they are accessing the metaclass of the class of
: which $x is an instance.
:
: I would suggest instead that we have a method, which is found in
: Object which allows instances to add methods to themselves (and only
: themselves). In Ruby this is called 'add_singleton_method' or
: something like that. I use that same name in the metamodel prototype
: too.
That's fine, and fits in with Prototype-Think anyway.
: Here is how it could be done.
:
: class ShadowClass does Class {}
:
: class Object is reopened {
That might change to is also, the generic trait for appending to things
that may or may not be classes. (And is instead is used to replace things.)
: method add_singleton_method (Str $label, Method $method) {
: if ($?SELF.class.class != ShadowClass) {
s/$?SELF/self/
And I think .class should be a coercion to the class view of its
invocant, which would make your second .class a no-op. I think what
you're calling .class.class I'm calling .meta.class. I want to
think of the class as an abstraction that is not an object. Everything
you call Class I want to sweep behind .meta, because the metaclass instance
is the real class object.
: my $shadow = ShadowClass.new();
: $shadow.meta.superclasses([ $shadow ]);
: $?SELF.class = $shadow;
I think that should be self.meta = $shadow. .class is not an
lvalue--it's just a restricted view of the current object. (Again,
by my definitions. I realize clashing definitions are at work here.
Maybe I can come up with a different word for what I call class.
Or maybe I get class, and you get Class :-) * .5
: }
: $?SELF.class.meta.add_method($label, $method);
That's just self.meta.add_method($label, $method) by my lights.
A .meta already implies/ignores the .class coercion. If we are to
support prototype-based programming $x.meta *must not care* whether
it has been given a class or an instance or something in between.
What I am calling a class here is basically that portion of the
current instance that is the same for all members of its class.
And that common information presumably includes information on what to
do if a method is called that is not directly recognized by the object.
Class-based and prototype-based systems have different answers to that,
but they have something in common, and I'd like to abstract that out
and call it something. I've been calling it class, but maybe I
should call it something else to avoid confusion. A type maybe.
That would imply that ¢ is really a type variable rather than a class
variable. But maybe type is too overloaded already. But maybe not.
Anyway, if my class turns into type or something else, maybe I
can be persuaded to go with ^T instead of ¢T.
Larry
Re: +$arg changed to :$arg
On Wed, Oct 26, 2005 at 04:59:04PM +0200, Juerd wrote:
: Larry Wall skribis 2005-10-26 7:31 (-0700):
: One slightly serious ramification of the : switch is that the space
: is required after the colon indicating a null invocant.
: method doit (: $a, $b, $c)
:
: Or, we could separate it with a . instead of a :, perhaps?
:
: This is already more or less very heavily associated with invocants
: anyway.
I think a . would be too lightweight visually within the signature.
Plus . is a postfix prefix syntactically, not a delimiter.
: Hmmm...
:
: method .doit (...) { ... }
: method $foo.doit () { ... }
I think it would be a mistake to move the invocant outside the
signature. We've just taken pains to move the return type *into*
the signature.
Larry
Re: Ways to add behavior
That's just self.meta.add_method($label, $method) by my lights. A .meta already implies/ignores the .class coercion. If we are to support prototype-based programming $x.meta *must not care* whether it has been given a class or an instance or something in between. What I am calling a class here is basically that portion of the current instance that is the same for all members of its class. And that common information presumably includes information on what to do if a method is called that is not directly recognized by the object. Class-based and prototype-based systems have different answers to that, but they have something in common, and I'd like to abstract that out and call it something. I've been calling it class, but maybe I should call it something else to avoid confusion. A type maybe. That would imply that ¢ is really a type variable rather than a class variable. But maybe type is too overloaded already. But maybe not. I'd like to take this moment and point to my somewhat hand-wavy metamodel proposal from last week. When Stevan and I were talking about this, we called it a quark. Atom also works quite nicely, but quarks are cooler. Plus, if you think about the definitions that go into creating an instance (class, role, prototype, etc), it makes sense that if the instance is the smallest indivisible thing there is, then the things that go about being its definition are the quarks. Anyway, if my class turns into type or something else, maybe I can be persuaded to go with ^T instead of ¢T. Q(T) ? :-) Rob
Re: +$arg changed to :$arg
Larry Wall skribis 2005-10-26 8:29 (-0700): I think a . would be too lightweight visually within the signature. Plus . is a postfix prefix syntactically, not a delimiter. If weight is the issue, @#@ should do ;) This aside, you could of course just double the colon. Or use a semicolon. I just really wouldn't like : to have two very differentmeanings in very similar places. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Ways to add behavior
On Wed, Oct 26, 2005 at 11:31:28AM -0400, Rob Kinyon wrote: : That's just self.meta.add_method($label, $method) by my lights. : A .meta already implies/ignores the .class coercion. If we are to : support prototype-based programming $x.meta *must not care* whether : it has been given a class or an instance or something in between. : What I am calling a class here is basically that portion of the : current instance that is the same for all members of its class. : And that common information presumably includes information on what to : do if a method is called that is not directly recognized by the object. : Class-based and prototype-based systems have different answers to that, : but they have something in common, and I'd like to abstract that out : and call it something. I've been calling it class, but maybe I : should call it something else to avoid confusion. A type maybe. : That would imply that ¢ is really a type variable rather than a class : variable. But maybe type is too overloaded already. But maybe not. : : I'd like to take this moment and point to my somewhat hand-wavy : metamodel proposal from last week. When Stevan and I were talking : about this, we called it a quark. Atom also works quite nicely, : but quarks are cooler. Yes, I was sorry it got Warnocked. : Plus, if you think about the definitions that go into creating an : instance (class, role, prototype, etc), it makes sense that if the : instance is the smallest indivisible thing there is, then the things : that go about being its definition are the quarks. : : Anyway, if my class turns into type or something else, maybe I : can be persuaded to go with ^T instead of ¢T. : : Q(T) ? :-) Will be misinterpreted as sexist, so not on the Q/T. :-) One wants to coin a word like Qlass. Unfortunately qlass is too easy to misread as glass. Oy veh, I'm getting notions of the qlass is half empty for a partially instantiated object. But it's probably not appropriate to coin a new term if we can force type to work. Someone please martial some objections. Of course, there are other words that are somewhat synonymous with class, Unfortunately sort is already hosed. Maybe kind. Then evolutionists could make jokes about the K(T) boundary, and creationists could make jokes about reproducing after their kind. Some of us could make either kind of joke. But perhaps it wouldn't be kind. Larry
Re: Ways to add behavior
Larry Wall wrote: Of course, there are other words that are somewhat synonymous with class, Unfortunately sort is already hosed. Maybe kind. Then evolutionists could make jokes about the K(T) boundary, and creationists could make jokes about reproducing after their kind. Some of us could make either kind of joke. But perhaps it wouldn't be kind. Which (sort of) takes us back to TSa's (non)sign-off note from 10/5, wherein he suggested: I've always taken the 'what type of expression' approach to programming languages and thus have an affinity to type systems and type theory. With 'type' in general and 'data type' in particular beeing too misleading or used in too many different meanings in other programming languages I propose to coin the notion of 'kind' which has the nice double meaning of nice and sort. And as such gives the nice pun Perl 6, the kind language with the two meanings Perl 6, a kind of language , the language of kind(ness) I don't know if this is a good sign or a bad one, but the jokes started before you even made the suggestion! :) /au
Re: Ways to add behavior
On Oct 26, 2005, at 12:05 PM, Larry Wall wrote: Of course, there are other words that are somewhat synonymous with class, Unfortunately sort is already hosed. Maybe kind. Actually kind is used in the Core Calculus for Metaclasses paper which I brought to the hackathon (not sure if you got to read it or not). Here is a link: http://research.sun.com/projects/plrg/core-calculus.pdf They present an rather interesting view on things, that the definition of the instance creating portion of a class should be seperated from the class or kind portion of the class. Actually the first metamodel prototype grew out of an implementation of the model they describe in the paper. Stevan
Re: Ways to add behavior
On Wed, Oct 26, 2005 at 09:05:22AM -0700, Larry Wall wrote: Of course, there are other words that are somewhat synonymous with class, Unfortunately sort is already hosed. Maybe kind. Maybe we could go with something Linnaean like family or genus even though their relation to class isn't quite the same. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Rough thoughts on the Object Space
Hello all, just unwarnocking myself here :)
These are some notes to add re: a short discussion with autrijus on
#perl6
The idea is that the interpreter/compiler is split into 3 parts.
- The first part parses the code, deals with flow control and syntax
stuff.
- The second part is the type engine. It has 2 phases:
phase 1: look at all type annotations and propagate them upwards
and downwards.
phase 2: standard type checking and inference
Then once all possible type information is squeezed out of the source
code, we go to the next part.
- Application-level (or user-level) code is then executed within the
context of the runtime (aka Object Space).
This is a very rough and high level view, and ignores little details
like macros, BEGIN blocks, etc.
Stevan
On Oct 23, 2005, at 12:29 PM, Stevan Little wrote:
Hello all,
So after reading fglock's Perl6::Value/Container modules, some p6l
backtracing and some discussions on #perl6 with Luke and autrijus,
I have arrived at a very early (read: probably wrong) thoughts for
the p6 Object Space.
I see this step as critical in the development of Pugs 6.28.0, and
so I wanted to start the discussion now.
When I speak of Object Space I mean it in the PyPy sense of the
word, a description of which can be found here: http://
codespeak.net/pypy/dist/pypy/doc/draft-dynamic-language-
translation.html#object-spaces.
Now, let me first start with a basic drawing, and use it to explain
what I am thinking. Here is the drawing:
http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel/docs/
Object_Space.jpg
Now, before anyone gets all up in arms that I have forgotten their
favorite p6 type, let me say that is not what the drawing is of,
and that it is purposfully incomplete in that sense.
Now, the drawing is to be read from left to right, with each
section being built upon the one which came before it. I will
explain each section in detail.
Core Runtime
This is the absolute bare minimum set of types which need to be
implemented on this level. These are *not* a list of the unboxed
types which will eventually be exposed to the p6 user, these are
runtime supplied types, for use in the runtime only (at least at
this point).
MetaModel Runtime
These are additional types which the runtime needs to supply in
order to support the Perl 6 MetaModel. It is possible (and very
likely) that these types will be implemented using the types in the
Core Runtime. However, this (probably) is not a requirement and
these types could be implemented natively for speed.
The instance type described here should be confused with the
Object type. Object (found in the meta-model level) is a class,
the instance type is just an opaque structure to describe an
instance of a class. It is a building block for the metamodel, just
like methods and attributes.
*NOTE*
At this point, we assume that a method dispatch mechanism is in
place. The details of which are not important at this point.
MetaModel
This is the object MetaModel, it provides classes, roles, modules,
packages and the base Object class.
Prior to this stage, we do not have any classes/objects available
on the user level. While the lower level types may (or may not) be
implemented in OO, but this has no correlation to the OO that the
user actually sees. The OO the user sees is implemented here.
Once this stage is complete, we are now ready to expose elements to
the user-level. In fact, Object is really the first user-level
thing which is exposed. Class, Package, Module and Role are meta-
level things and exactly how (and if) they get exposed to the
user-level is discussed at the end of this document.
Containers
The classic Perl Scalar, Array and Hash trio is implemented here.
These are container types, and for the most part, they hold the
other types found in the next level.
Boxed Types
This is a set of types (written using the meta-model), some of
which wrap primitive core runtime types, others which completely
are implemented here. I think that most of these will actually be
roles, and not classes. All these types are exposed in user-land.
-
Now, at this point, the Object Space should be completely
bootstrapped and ready for use. This is the end of the object
space, and the start of user-land.
I have a few other thoughts with respect to the user-level access
to the meta-model elements (Role, Class, Package Module). I think
that these elements should be wrapped in roles, along with method
and attributes as well. The .meta level will then handle wrapping
these elements in their respective roles for use in user-land.
This means that when I do this:
my $m = Foo.meta.get_method('bar');
I get back the primitive 'bar' method wrapped in the Method role.
This Method role will probably gather some meta-information from
various sources (not just the primitive method itself), and allow
Re: Ways to add behavior
Larry Wall: But perhaps it wouldn't be kind. 'caste' wouldn't either. For inspiraton: type sort class variety brand category breed manner style nature form hue caste set background stage setting milieu locale range assortment selection mixture strain suite scenery rank grade division status genre ... -- Grtz, Ruud
Re: Ways to add behavior
On 10/26/05, Stevan Little [EMAIL PROTECTED] wrote: On Oct 26, 2005, at 12:05 PM, Larry Wall wrote: Of course, there are other words that are somewhat synonymous with class, Unfortunately sort is already hosed. Maybe kind. Actually kind is used in the Core Calculus for Metaclasses paper which I brought to the hackathon (not sure if you got to read it or not). Here is a link: http://research.sun.com/projects/plrg/core-calculus.pdf They present an rather interesting view on things, that the definition of the instance creating portion of a class should be seperated from the class or kind portion of the class. Actually the first metamodel prototype grew out of an implementation of the model they describe in the paper. This might dovetail quite nicely into the discussion of how types are now sets instead of junctions. Objects are now a junction of the various kinds that were used to create it. Thus, boxed types are now almost trivial to implement ... ? Rob
Re: Ways to add behavior
Stevan Little: They present an rather interesting view on things, that the definition of the instance creating portion of a class should be seperated from the class or kind portion of the class. Its quality. Its character. Its features. Its face. -- Grtz, Ruud
Re: [perl #37477] [PATCH] Configure - improved lex yacc probing
At 03:02 19/10/2005 -0700, you wrote: # New Ticket Created by Joshua Hoblitt # Please include the string: [perl #37477] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37477 Any objections? $ cat config_lib.pasm # Generated by config/gen/config_pm.pl from the template # 'config/gen/config_pm/config_lib.in' and %PConfig ... set P0[bison_version], ARRAY(0x836803c) ... set P0[flex_Version], ARRAY(0x83526f4) ... set P0[gccversion], 3.3 Just a question, why produce a array (not serialized) and not a simple string like gcc ? A patch is attached. François -J bison_flex_version.patch Description: Binary data
Re: +$arg changed to :$arg
HaloO,
Larry Wall wrote:
On Wed, Oct 26, 2005 at 04:59:04PM +0200, Juerd wrote:
: Larry Wall skribis 2005-10-26 7:31 (-0700):
: One slightly serious ramification of the : switch is that the space
: is required after the colon indicating a null invocant.
What is an invocantless method other than a sub?
: method doit (: $a, $b, $c)
:
: Or, we could separate it with a . instead of a :, perhaps?
I have proposed to markup invocant parameters with a leading dot
sigil. More than one invocant either makes it a multi method or
a mono method on a more complicated type. If the zoning of parameters
is dropped however, interpersed dotted params might make Perl approach
Cecil in that respect and surpass it with combining dispatched params
with named params.
:
: This is already more or less very heavily associated with invocants
: anyway.
Yes, and dispatch as a runtime keyed access into a code multitude.
The covariant part of the method's sig! The code equivalent to keyed
data access into hashes.
I think a . would be too lightweight visually within the signature.
Plus . is a postfix prefix syntactically, not a delimiter.
How are multiple -- handled in a method sig? The standard case
of a method defined in a class puts the class type into a primary
or pre-dispatch position, or not? I mean that
class Foo
{
method bar ($x, $y) {...}
}
might just mean
class Foo
{
method bar (¢Foo $?SELF -- $x, $y -- ) {...}
}
The left -- is just the virtualizer call. I tend to call
that slot accessor. The return value of a dispatch is the
not yet invoked but curried on the invocant(s) method. This
two stage propcess is in my eyes nicely indicated by the
two --. But we could also but a : in the dispatch arrows
like -:- or :- or -: which all look somewhat ugly.
: Hmmm...
:
: method .doit (...) { ... }
: method $foo.doit () { ... }
I think it would be a mistake to move the invocant outside the
signature. We've just taken pains to move the return type *into*
the signature.
But the distinction between the dispatch/covariant part and the
contravariant lhs of the arrow type is difficult if we allow multiple
arrows in sigs. I would therefore like to propose anpther trait for
methods: the 'on' part. To wit:
method doit (...) on (invocant sig) { ... }
Well, we could take the ¢ sigil to form invocant twigils ¢$, ¢@, ¢%, ¢
which look a bit nicer with ^ though: ^$, ^@, ^%, ^. The association
with $^, @^, %^, ^ in placeholders is a bonus in my eyes because they
are post dispatch on void invocants :)
The guiding theme in my line of thinking about twigils is that there's
a void between their two chars. A pair of type constraint and uncaptured
actual invocant type so to say. Well and we could capture it with
method doit ( Constraint ^Actual $foo, NonInvocant $blahh ) {...}
to deal have it available inside. Am I makeing sense? Which impact all
this has an the self method discussion I don't know, but ^. and .^ come
to mind. The former would make ^.foo a method on the current invocant
and a bare .^ would dispatch the current method on the topic or some such.
--
$TSa.greeting := HaloO; # mind the echo!
[perl #37540] [TODO] core - document 'new_pad' op
# New Ticket Created by jerry gay # Please include the string: [perl #37540] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37540 there have been questions lately about the use of the 'new_pad' op. will coleda provided a failing example, which i've included below. upon investigating, i found no tests for new_pad. furthermore, i found no documentation for new_pad in order to start writing tests. so, before tests can be written, the documentation needs to be found or written. here's the failing code snippet: .sub _main :main new_pad 0 $P0 = compreg PIR $S0 = END_PIR .sub a $P1 = find_lex 1, '$a' .end END_PIR $P2 = $P0($S0) store_global b, $P2 $S0 = END_PIR .sub 'c' new_pad -1 $P0 = find_global 'b' $P0 = $P0() .end END_PIR $P1 = $P0($S0) $S0 = END_PIR .sub d $P0 = find_global 'c' $P0() .end END_PIR $P1 = $P0($S0) $P1() .end # fails with 'Pad index out of range' ~jerry
Re: Ways to add behavior
Larry Wall [EMAIL PROTECTED] wrote: Of course, there are other words that are somewhat synonymous with class, Unfortunately sort is already hosed. Maybe kind. Then evolutionists could make jokes about the K(T) boundary, and creationists could make jokes about reproducing after their kind. Some of us could make either kind of joke. But perhaps it wouldn't be kind. Flavor. (Shades of CLOS, but we're already building the most flexible object system since it...) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Ways to add behavior
HaloO, Austin Frank wrote: Which (sort of) takes us back to TSa's (non)sign-off note from 10/5, wherein he suggested: I just can't help it, I love the good work done on this list! And thanks for spelling the acronym correctly. The Kindly One of a class beeing the representative like the President of the United States is the First of Man :) With limited runtime, of course ... Who knows the Kindly Ones from the Sandman? This nicely complements the seven Endless and their sigils ;) But the German Sandmännchen has to put the kids to sleep now---sweet dreams to everyone. -- $TSa.greeting := HaloO; # mind the echo!
Re: Ways to add behavior
On Wed, Oct 26, 2005 at 12:22:07PM -0400, Stevan Little wrote: : : On Oct 26, 2005, at 12:05 PM, Larry Wall wrote: : Of course, there are other words that are somewhat synonymous with : class, Unfortunately sort is already hosed. Maybe kind. : : Actually kind is used in the Core Calculus for Metaclasses paper : which I brought to the hackathon (not sure if you got to read it or : not). Here is a link: : : http://research.sun.com/projects/plrg/core-calculus.pdf : : They present an rather interesting view on things, that the : definition of the instance creating portion of a class should be : seperated from the class or kind portion of the class. Actually : the first metamodel prototype grew out of an implementation of the : model they describe in the paper. Interesting. I didn't read it, but a bunch of us seem to be converging on the same elephant. I'm thinking of kind as the actual type of a real instance separate from the machinery. I think it probably corresponds to what Luke is saying about classes not really having names. So maybe we can define our terms like this: type: a completely generic metaterm for any of the following, and then some. class: a mutable interface object that manages instances in the classical way, with covariant derivational properties. role: an immutable and possibly generic interface class, with covariant compositional properties. kind: the abstract, often unnamed type of an actual instance or storage location, abstracted from any of its machinery or degree of definedness. You should not generally declare a kind, they just happen. subtype: a potentially contravariant type based on any of the previous types, allowed to impose constraints that are more selective than a kind is allowed to be. Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks if two objects are of the same type, but $x.kind isn't a class-like object, only an identity of some sort. $x.meta returns the Class instance, or whatever. At the moment, I think the weakest word choice is subtype. People from certain cultures will confuse subtypes with subclasses. The notion of constraints or limitations is already conveyed by where, and some subtypes may just be aliases. Plus, as we've defined them above, subtypes are the most generic type you can name in Perl. So maybe we should go with type...which is yet another thing I've waffled on repeatedly... Larry
Re: +$arg changed to :$arg
On Wed, Oct 26, 2005 at 07:06:15PM +0200, TSa wrote:
: HaloO,
:
: Larry Wall wrote:
: On Wed, Oct 26, 2005 at 04:59:04PM +0200, Juerd wrote:
: : Larry Wall skribis 2005-10-26 7:31 (-0700):
: : One slightly serious ramification of the : switch is that the space
: : is required after the colon indicating a null invocant.
:
: What is an invocantless method other than a sub?
It's not invocantless. I should have said implicit. But it's implicit
anyway if you leave the colon out. (And you can only leave out the invocant
for the declaration of single dispatch methods anyway.)
: : method doit (: $a, $b, $c)
: :
: : Or, we could separate it with a . instead of a :, perhaps?
:
: I have proposed to markup invocant parameters with a leading dot
: sigil. More than one invocant either makes it a multi method or
: a mono method on a more complicated type.
Could do that, but again . is kind of invisible, and doesn't give us
tie-breaking multiple colons.
: If the zoning of parameters
: is dropped however, interpersed dotted params might make Perl approach
: Cecil in that respect and surpass it with combining dispatched params
: with named params.
That seems like a mental disaster waiting to happen to newbies. Maybe
there are reasons people are avoiding Cecil...
: : This is already more or less very heavily associated with invocants
: : anyway.
:
: Yes, and dispatch as a runtime keyed access into a code multitude.
: The covariant part of the method's sig! The code equivalent to keyed
: data access into hashes.
Um, yeah. Won't play in Peoria, though.
: I think a . would be too lightweight visually within the signature.
: Plus . is a postfix prefix syntactically, not a delimiter.
:
: How are multiple -- handled in a method sig? The standard case
: of a method defined in a class puts the class type into a primary
: or pre-dispatch position, or not? I mean that
:
:class Foo
:{
:method bar ($x, $y) {...}
:}
:
: might just mean
:
:class Foo
:{
:method bar (¢Foo $?SELF -- $x, $y -- ) {...}
:}
:
: The left -- is just the virtualizer call. I tend to call
: that slot accessor. The return value of a dispatch is the
: not yet invoked but curried on the invocant(s) method. This
: two stage propcess is in my eyes nicely indicated by the
: two --. But we could also but a : in the dispatch arrows
: like -:- or :- or -: which all look somewhat ugly.
I kind of like : for that, actually. :-)
: : Hmmm...
: :
: : method .doit (...) { ... }
: : method $foo.doit () { ... }
:
: I think it would be a mistake to move the invocant outside the
: signature. We've just taken pains to move the return type *into*
: the signature.
:
: But the distinction between the dispatch/covariant part and the
: contravariant lhs of the arrow type is difficult if we allow multiple
: arrows in sigs. I would therefore like to propose anpther trait for
: methods: the 'on' part. To wit:
:
: method doit (...) on (invocant sig) { ... }
I don't see how that relates.
: Well, we could take the ¢ sigil to form invocant twigils ¢$, ¢@, ¢%, ¢
: which look a bit nicer with ^ though: ^$, ^@, ^%, ^. The association
: with $^, @^, %^, ^ in placeholders is a bonus in my eyes because they
: are post dispatch on void invocants :)
Don't know what that means either.
: The guiding theme in my line of thinking about twigils is that there's
: a void between their two chars. A pair of type constraint and uncaptured
: actual invocant type so to say. Well and we could capture it with
:
: method doit ( Constraint ^Actual $foo, NonInvocant $blahh ) {...}
:
: to deal have it available inside. Am I makeing sense? Which impact all
: this has an the self method discussion I don't know, but ^. and .^ come
: to mind. The former would make ^.foo a method on the current invocant
: and a bare .^ would dispatch the current method on the topic or some such.
I haven't the foggiest clue if you're making sense. And that's the
scary part.
Larry
Re: [perl #37540] [TODO] core - document 'new_pad' op
via RT jerry gay [EMAIL PROTECTED] wrote: there have been questions lately about the use of the 'new_pad' op. will coleda provided a failing example, which i've included below. upon investigating, i found no tests for new_pad. furthermore, i found no documentation for new_pad in order to start writing tests. so, before tests can be written, the documentation needs to be found or written. here's the failing code snippet: And here's a simpler snippet that displays the same failure: .sub _main :main .local pmc pir pir = compreg PIR new_pad 0 $S0 = END_PIR .sub a $P1 = find_lex 1, '$a' .end END_PIR $P2 = pir($S0) # using find_name to get the the PMC for a makes it work store_global b, $P2 c() .end .sub c new_pad -1 b() # changing this to a() also makes it work .end -- matt diephouse http://matt.diephouse.com
Re: Rough thoughts on the Object Space
On Wed, Oct 26, 2005 at 12:36:57PM -0400, Stevan Little wrote: : This is a very rough and high level view, and ignores little details : like macros, BEGIN blocks, etc. Yes, Perl 5 is conceptually a 3-pass compiler, but the passes have to be interwoven to do the literate compilation thing that Perl demands. Larry
Re: Ways to add behavior
LW == Larry Wall [EMAIL PROTECTED] writes: LW One wants to coin a word like Qlass. Unfortunately qlass is LW too easy to misread as glass. Oy veh, I'm getting notions of LW the qlass is half empty for a partially instantiated object. [EMAIL PROTECTED], i think you need some immediate mental help. please step back from the keyboard before you commit such a sin again. the next time, i will ask gloria to stick you with a knitting needle. is the smiley :) or (: ? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
[perl #37541] [PATCH] more helpful error message when opcode not found
# New Ticket Created by Allison Randal # Please include the string: [perl #37541] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37541 Currently the error message when a particular opcode isn't found gives the name of the opcode and the number of arguments passed in: error:imcc:op not found 'setattribute' (setattribute3) in file 'testlag.pir' line 51 But this isn't very helpful when I know that setattribute takes 3 arguments, and the problem is that I passed in PMC, STR, INT instead of PMC, STR, PMC. (Not really a big deal, but offputting for newbies, and I run into it just often enough to make it an itch.) I've attached a patch with a more verbose error message. Even more helpful would be listing the types that were passed in. Allison errormes_op_not_found.patch Description: Binary data
Re: [perl #37477] [PATCH] Configure - improved lex yacc probing
On Wed, Oct 26, 2005 at 09:54:10AM -0700, Fran??ois PERRAD via RT wrote: At 03:02 19/10/2005 -0700, you wrote: # New Ticket Created by Joshua Hoblitt # Please include the string: [perl #37477] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37477 Any objections? $ cat config_lib.pasm # Generated by config/gen/config_pm.pl from the template # 'config/gen/config_pm/config_lib.in' and %PConfig ... set P0[bison_version], ARRAY(0x836803c) ... set P0[flex_Version], ARRAY(0x83526f4) ... set P0[gccversion], 3.3 Just a question, why produce a array (not serialized) and not a simple string like gcc ? The idea was that the version string wouldn't have to be parsed again but I agree that it should look like everything else so we can always change this later. A patch is attached. Would you commit it? Cheers, -J -- pgpHYj4YdwgPe.pgp Description: PGP signature
Re: Ways to add behavior
So maybe we can define our terms like this: type: a completely generic metaterm for any of the following, and then some. class: a mutable interface object that manages instances in the classical way, with covariant derivational properties. role: an immutable and possibly generic interface class, with covariant compositional properties. kind: the abstract, often unnamed type of an actual instance or storage location, abstracted from any of its machinery or degree of definedness. You should not generally declare a kind, they just happen. subtype: a potentially contravariant type based on any of the previous types, allowed to impose constraints that are more selective than a kind is allowed to be. Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks if two objects are of the same type, but $x.kind isn't a class-like object, only an identity of some sort. $x.meta returns the Class instance, or whatever. A few questions: 1) Where does prototype-style OO fit into all of this? I hope it's not through repeated eigenclasses (or whatever they're called this week) ... that just sounds too heavy. 2) Isn't Dog|Cat kinda declaring a kind? Thus, can't you say my Dog|Cat $catdog; and be talking about a kind? I would think that a named kind is just a role ... 3) Aren't classes mutable and roles immutable by default only? Or has this changed? Rob
Re: [perl #37541] [PATCH] more helpful error message when opcode not found
On 10/26/05, via RT Allison Randal [EMAIL PROTECTED] wrote: I've attached a patch with a more verbose error message. Even more helpful would be listing the types that were passed in. thanks, applied as revision 9579. ~jerry
Re: Ways to add behavior
On Wed, Oct 26, 2005 at 03:54:35PM -0400, Rob Kinyon wrote: : So maybe we can define our terms like this: : : type: a completely generic metaterm for any of the following, : and then some. : : class: a mutable interface object that manages instances in the : classical way, with covariant derivational properties. : : role: an immutable and possibly generic interface class, with : covariant compositional properties. : : kind: the abstract, often unnamed type of an actual instance : or storage location, abstracted from any of its machinery or : degree of definedness. You should not generally declare a kind, : they just happen. : : subtype: a potentially contravariant type based on any of the : previous types, allowed to impose constraints that are more : selective than a kind is allowed to be. : : Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks : if two objects are of the same type, but $x.kind isn't a class-like : object, only an identity of some sort. $x.meta returns the Class : instance, or whatever. : : A few questions: : 1) Where does prototype-style OO fit into all of this? I hope it's not : through repeated eigenclasses (or whatever they're called this week) : ... that just sounds too heavy. I don't profess to be an expert on prototype style, but I think even if we do it with eigenclasses it's not too heavy as long as we find a way to share structurally identical eigenclasses. Copy on write would get some sharing benefit, though wouldn't coalesce eigenclasses that just happened to converge on the same definition. On the other hand, I think we can abstract out kindness sufficiently well that, for the prototype kind of object, the machinery can just clone the method refs along with the attributes. : 2) Isn't Dog|Cat kinda declaring a kind? If it resolves to a set of types, it can be *used* as a kind. But if you insist on the ORness of it, then it's really a subtype, because a kind supports all of its member roles, not just one of them. : Thus, can't you say my Dog|Cat $catdog; and be talking about a kind? No, that merely asserts that the kind of $catdog must support those two interfaces, assuming | just constructs a set. But it's not clear that we'll support | there at all, but assuming AND juxtapositional syntax, we can just write that: my Dog Cat $catdog; and get the same constraints on $catdog. And the fact of the matter is that either of Dog or Cat may be a constrained subtype, not a real kind. If we say my Even Odd $evenodd; then we'll never match our constraints, despite the fact that Even and Odd are both subtypes of Int, and Int can function as a kind. : I would think that a named kind is just a role ... No, other way around, a role is just a named kind. More precisely, a non-generic role can be forced to compose to a class that can function as a kind. But there can be kinds that don't behave well according to the rules of roles. You can't compose two kinds that happen to represent native types, for instance. : 3) Aren't classes mutable and roles immutable by default only? Or has : this changed? Of course. To change the default for a role, call it a class, and to change the default for a class, call it a role. :-) Larry
Re: Ways to add behavior
On 10/26/05, Larry Wall [EMAIL PROTECTED] wrote: So maybe we can define our terms like this: type: a completely generic metaterm for any of the following, and then some. class: a mutable interface object that manages instances in the classical way, with covariant derivational properties. role: an immutable and possibly generic interface class, with covariant compositional properties. kind: the abstract, often unnamed type of an actual instance or storage location, abstracted from any of its machinery or degree of definedness. You should not generally declare a kind, they just happen. We're screwing around with existing OO jargon, so it's probably not too bad to screw around with this one too, especially since it only appears under the covers in ML. A kind is the signature of a type. So, for instance, Int has kind * Array has kind * - * Array Int has kind * Other than that, I think the term works find. subtype: a potentially contravariant type based on any of the previous types, allowed to impose constraints that are more selective than a kind is allowed to be. Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks if two objects are of the same type, Don't you mean $x.kind eqv $y.kind? Ugh. but $x.kind isn't a class-like object, only an identity of some sort. $x.meta returns the Class instance, or whatever. At the moment, I think the weakest word choice is subtype. People from certain cultures will confuse subtypes with subclasses. The notion of constraints or limitations is already conveyed by where, and some subtypes may just be aliases. Plus, as we've defined them above, subtypes are the most generic type you can name in Perl. So maybe we should go with type...which is yet another thing I've waffled on repeatedly... constrained type? Though that only works for the literature, not Perl's active vocabulary. Luke
Roles vs. Classes (was Re: Ways to add behavior)
: 3) Aren't classes mutable and roles immutable by default only? Or has : this changed? Of course. To change the default for a role, call it a class, and to change the default for a class, call it a role. :-) Does this mean that roles are the recommended way to create immutable classes? Given that roles and classes now seem to differ only in their mutability, I can't see a reason why I would use class as my default object definer. I would prefer to use roles as they're closed by default, leaving class to be my powertool, if I need the power. Rob
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote: I would prefer to use roles as they're closed by default, leaving class to be my powertool, if I need the power. I don't understand this desire; can you explain your reasoning? (NB: closed here, as I use it, still *does not* correspond to licensing or availability of the source code.) -- c
Re: Roles vs. Classes (was Re: Ways to add behavior)
On 10/26/05, chromatic [EMAIL PROTECTED] wrote: On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote: I would prefer to use roles as they're closed by default, leaving class to be my powertool, if I need the power. I don't understand this desire; can you explain your reasoning? If a role is an immutable class, that means that its internals cannot be changed. Hence, the compiler can trust that it will be the same at the end as at the beginning. Which means it's optimized. Which means my objects run faster if I create them from roles than if I create them from classes. And, given that this seems to be the sole difference between them (mutability vs. immutability), why would I use classes as my standard? Rob
Re: Roles vs. Classes (was Re: Ways to add behavior)
On 10/26/05, Rob Kinyon [EMAIL PROTECTED] wrote:
On 10/26/05, chromatic [EMAIL PROTECTED] wrote:
On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote:
I would prefer to use roles as they're closed by default, leaving
class to be my powertool, if I need the power.
I don't understand this desire; can you explain your reasoning?
If a role is an immutable class, that means that its internals cannot
be changed. Hence, the compiler can trust that it will be the same at
the end as at the beginning. Which means it's optimized. Which means
my objects run faster if I create them from roles than if I create
them from classes. And, given that this seems to be the sole
difference between them (mutability vs. immutability), why would I use
classes as my standard?
Okay, an open class means you can add methods to it, right? So, let's
say you have this class:
class Foo {
method foo() {...}
method bar() {...}
}
And this code:
my Foo $x = Foo.new;
$x.foo();
$x.bar();
This might be compiled to the following pseudo intermediate code:
my $x = Foo[0]();
Foo[1]($x);
Foo[2]($x);
Now let's say you extend the class:
class Foo is also {
method baz() {...}
}
Is there any reason that the preceding pseudo intermediate code is no
longer valid? I don't see one; baz() is just installed in slot 3. So
why would you say it was faster to have it closed?
Indeed, it *could* be faster. But we find that many programmers make
decisions that trade readability and extensibility for an extra 1% of
speed, even when they are writing a command-line frontend to
MPlayer[1]. If those people are module writers, then we have a bunch
of modules on CPAN that are not friendly to the user who wants to use
the module in the one way the writer didn't expect.
So the reason we made classes open by default is so that people
wouldn't have a chance to make that decision until they're more
experienced. Indeed, no module writer can say that a class is closed;
only the main program may say that, because the main program knows the
most about how everything is used. The precise definition of main
program is not well-defined yet, but it's there so that a module
writer doesn't close himself off from the world without knowing how
his module is even being used.
And if you're going to use roles for everything because they're closed
and they will gain you 2% of speed on one particular backend, then
we'll have to make the same rule for them too. I know it sounds like
we're babying our programmers. We are, because it's such a
widespread superstition.
And just to reinforce that it's a superstition: a theory defines a
vtable. If you extend the class in an incompatible way, you have to
make a new instance of its theory, defining new vtable slots. Once
the new vtable is created, it is just as fast as the old one. There
is no speed loss whatsoever for keeping your class open.
Luke
[1] This is a concrete example that I actually witnessed.
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Wed, Oct 26, 2005 at 08:48:12PM -0400, Rob Kinyon wrote: : If a role is an immutable class, that means that its internals cannot : be changed. Hence, the compiler can trust that it will be the same at : the end as at the beginning. Which means it's optimized. Which means : my objects run faster if I create them from roles than if I create : them from classes. And, given that this seems to be the sole : difference between them (mutability vs. immutability), why would I use : classes as my standard? Because it might be a premature optimization to the extent that it restricts flexibility before you know whether it's going to affect performance. Part of the power of Ruby on Rails reputedly comes from the fact that Ruby leaves its classes open by default. Larry
Re: Ways to add behavior
On Wed, Oct 26, 2005 at 04:56:23PM -0600, Luke Palmer wrote: : Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks : if two objects are of the same type, : : Don't you mean $x.kind eqv $y.kind? : : Ugh. Now that infix::: has come available, maybe I mean: $x.kind :: $y.kind Now all we need is infix:: to calculate the value of the relationship of two items, and we can write: $a : $b :: $c : $d :-) * .5 Larry
Re: Ways to add behavior
On Wed, Oct 26, 2005 at 06:34:48PM -0700, Larry Wall wrote: : On Wed, Oct 26, 2005 at 04:56:23PM -0600, Luke Palmer wrote: : : Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks : : if two objects are of the same type, : : : : Don't you mean $x.kind eqv $y.kind? : : : : Ugh. : : Now that infix::: has come available, maybe I mean: : : $x.kind :: $y.kind And maybe eq and == could degenerate to :: if both args aren't coercable to the desired type. Larry
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Wed, 2005-10-26 at 19:22 -0600, Luke Palmer wrote: But we find that many programmers make decisions that trade readability and extensibility for an extra 1% of speed, even when they are writing a command-line frontend to MPlayer[1]. If those people are module writers, then we have a bunch of modules on CPAN that are not friendly to the user who wants to use the module in the one way the writer didn't expect. Worse, that's a *theoretical* 1% of speed based on non-profiled code. And if you're going to use roles for everything because they're closed and they will gain you 2% of speed on one particular backend, then we'll have to make the same rule for them too. I know it sounds like we're babying our programmers. We are, because it's such a widespread superstition. I prefer to think of it as Helping to prevent them from writing unreusable code. And just to reinforce that it's a superstition: a theory defines a vtable. If you extend the class in an incompatible way, you have to make a new instance of its theory, defining new vtable slots. Once the new vtable is created, it is just as fast as the old one. There is no speed loss whatsoever for keeping your class open. Even further, don't forget that someone, somewhere will really need to do something you didn't think of. Either he extends your class somehow or works around it in an ugly, funky way. Which one is faster to write? Which one is faster to execute? Which one is more likely to be correct? Which one is more maintainable? -- c
Re: Roles vs. Classes (was Re: Ways to add behavior)
On 10/26/05, Luke Palmer [EMAIL PROTECTED] wrote:
[snip]
Okay, an open class means you can add methods to it, right? So, let's
say you have this class:
class Foo {
method foo() {...}
method bar() {...}
}
And this code:
my Foo $x = Foo.new;
$x.foo();
$x.bar();
This might be compiled to the following pseudo intermediate code:
my $x = Foo[0]();
Foo[1]($x);
Foo[2]($x);
Now let's say you extend the class:
class Foo is also {
method baz() {...}
}
Is there any reason that the preceding pseudo intermediate code is no
longer valid? I don't see one; baz() is just installed in slot 3. So
why would you say it was faster to have it closed?
What about:
class Foo is also {
method foo() { ... }
}
Where the second foo() is no longer what the first foo() did.
Furthermore, let's say you have:
class Bar isa Foo {
method floober() { ... }
}
If they were roles, then role Bar could alias all the methods it
inherits from role Foo. In other words, it can cache all the method
lookups at compile-time. That's a substantial savings. If they're open
classes, the runtime has to throw out all the cached lookups the
moment any of the classes upstream are modified.
Plus, the argument is a straw man. Instead of:
class Some::Class is also {
}
you would do:
class My::Version {
does Some::Class;
}
Problem solved.
Rob
Re: Ways to add behavior
On Wed, 2005-10-26 at 14:52 -0400, Uri Guttman wrote: LW == Larry Wall [EMAIL PROTECTED] writes: LW One wants to coin a word like Qlass. Unfortunately qlass is LW too easy to misread as glass. Oy veh, I'm getting notions of LW the qlass is half empty for a partially instantiated object. [EMAIL PROTECTED], i think you need some immediate mental help. please step back from the keyboard before you commit such a sin again. the next time, i will ask gloria to stick you with a knitting needle. is the smiley :) or (: ? I can't believe you missed the opportunity to write qloria. -- c
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote:
Plus, the argument is a straw man. Instead of:
class Some::Class is also {
}
you would do:
class My::Version {
does Some::Class;
}
Problem solved.
Don't forget the fun of modifying all existing uses of Some::Class to
use My::Version instead, if that's even possible.
-- c
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Wed, Oct 26, 2005 at 07:35:05PM -0700, chromatic wrote:
: On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote:
:
: Plus, the argument is a straw man. Instead of:
:
: class Some::Class is also {
: }
:
: you would do:
:
: class My::Version {
: does Some::Class;
: }
:
: Problem solved.
:
: Don't forget the fun of modifying all existing uses of Some::Class to
: use My::Version instead, if that's even possible.
That should mostly be handled by virtualized class names.
Larry
Re: Microsoft Visual Toolkit, not quite built.
On Oct 25, 2005, at 5:11 AM, Konovalov, Vadim wrote:
I have a copy of XP Pro: I just installed ActiveState Perl, Visual C+
+ Toolkit 2003, the MS SDK and the .NET SDK (On my Virtual PC
installation on my mac, btw. Only took about 10 hours, on and
off =-)
trying to build parrot using the toolkit command prompt, I get:
...
Y:\type test.ldo
LINK : fatal error LNK1104: cannot open file 'user32.lib'
-nodefaultlib'
cl : Command line warning D4002 : ignoring unknown option '-debug'
cl : Command line warning D4002 : ignoring unknown option
'-machine:x86'
LINK : fatal error LNK1104: cannot open file 'ut:test.exe'
Suggestions?
You need better environment vars and settings (vcvars32.bat).
That's what I'm using. The Visual Toolkit 2003 Command prompt is,
looking at the shortcut: %comspec% /k vcvars32.bat.
Recent
README.win32 from perl distro explain that,
Ah. yes, some detailed instructions there. Updated the parrot
README.win32 to at least mention that file, along with a note about
an apparent change in directory ('Microsoft Platform SDK' vs.
'Microsoft SDK') -- Once I fixed those directory issues, the
Configure test that blew up (above) started working.
and I saw good descriptions at
perlmonks site.
Ok. I had found nothing helpful at perlmonks about this, other than
use vcvars, which I seem to be.
Also, start with compiling perl itself, so you'll be sure settings
are ok.
I hate to encourage folks hacking on parrot to have to build anything
else, too. (Especially given how long it took me to download and run
everything so far. =-)
I tried running with ActiveState Perl, and it all seems fine. one
small glitch in the Configure step, but parrot mostly built. After
quite a number of spontaneous reboots of the Virtual PC (eek!), I
ended up here:
link -out:.\miniparrot.exe -nologo -nodefaultlib -debug -
machine:x86
-debug imcc\main.obj blib\lib\libparrot_s.lib oldnames.lib
kernel32.lib user
32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib
ole32.lib ol
eaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib
version.lib odbc32
.lib odbccp32.lib msvcrt.lib src\null_config.obj
libparrot_s.lib(array.obj) : error LNK2019: unresolved external
symbol _CONST_ST
RING referenced in function _Parrot_Array_class_init
.\miniparrot.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
Re: Microsoft Visual Toolkit, not quite built.
On Oct 26, 2005, at 11:44 PM, Will Coleda wrote: I tried running with ActiveState Perl, and it all seems fine. one small glitch in the Configure step Whoops, which I forgot to mention: Running CPU specific stuff..Can't spawn .\test.exe: Bad file descriptor at lib/Parrot/Configure/Step.pm line 301. ..done.
Re: Roles vs. Classes (was Re: Ways to add behavior)
On 10/26/05, Rob Kinyon [EMAIL PROTECTED] wrote:
What about:
class Foo is also {
method foo() { ... }
}
Where the second foo() is no longer what the first foo() did.
Just overwrite the vtable.
Furthermore, let's say you have:
class Bar isa Foo {
method floober() { ... }
}
If they were roles, then role Bar could alias all the methods it
inherits from role Foo. In other words, it can cache all the method
lookups at compile-time. That's a substantial savings. If they're open
classes, the runtime has to throw out all the cached lookups the
moment any of the classes upstream are modified.
This one is a little better. It is expensive to rejig all the cached
methods, but that expense comes at the time when you reopen. If you
never reopen, you never pay a penalty.
Plus, the argument is a straw man. Instead of:
class Some::Class is also {
}
you would do:
class My::Version {
does Some::Class;
}
Problem solved.
Unless your module is the one creating the Some::Classes, or unless
(as you point out above) there are existing subclasses of Some::Class,
or unless some other thing that you didn't think of, which is the
whole point of this discussion. There is no omniscient library
writer; there is no omniscient language designer. :-)
Luke
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, 2005-10-20 at 17:12 -0700, Nate Wiger wrote: If Perl 6 is going to be successful, this means it must change the fewest key things with the most benefits. I think there's an assumption here that not only do I not hold but I do not even understand. Suppose that I am a game developer with a small, very devoted and vocal group of fans. I interact with them regularly through IRC, message boards, and occasionally even private e-mail. I decide to create a new game and start to do some market research. Obviously I ask my core group of fans what they want. They oblige: more of everything they loved from previous games, harder difficulties, more in-jokes, and all of the new features they've always wanted in my previous games. I listen to them and write the game that my core fans want and, if I'm really surprisingly amazingly lucky, other people want it too and it's a success. More likely, it sells a few copies outside of my fanbase and I learn a painful lesson: there are more people you are not currently reaching than you are currently reaching. It's worth keeping them in mind. -- c
