Re: Perl 6 Summary for 2005-08-15 through 2005-08-22
delurk On 23 Aug 2005, at 10:20, Leopold Toetsch wrote: On Aug 23, 2005, at 3:43, Matt Fowles wrote: Java on Parrot I vote for Jot. That's already occupied by another language http://en.wikipedia.org/ wiki/Iota_and_Jot. as is Java Parrot http://petstockroom.com/get_item_2jj_birdcage.htm /delurk
Re: Can a scalar be lazy ?
On Mon, Aug 22, 2005 at 13:25:57 -0700, Larry Wall wrote:
On Tue, Aug 23, 2005 at 04:09:29AM +0800, Yiyi Hu wrote:
: my( $s, $t ); $s = value t is $t; $t = xyz; print $s;
: in perl 5, it will give a warning, and won't do right thing.
: we have to use other way or eval '$s' before print to get a correct
answer.
:
: So I wonder, If we can make $scalar lazy also. As array now is lazy by
default.
:
: Even if making scalar lazy might cause problem sometimes, Is it
: possible to add a property which is like
: my $var is lazy; to handle these situation?
In Perl 6 you make lazy scalars by putting curlies around them:
my( $s, $t ); $s = { value t is $t }; $t = xyz; print $s();
Currently we also require the de-lazifying context to supply a
postfix .() marker, but possibly that could be assumed in a string
or numeric context.
I really don't see much benefit in making it easier than that.
I see one:
class Object {
has $.expensive_to_compute_but_cachable = delay {
...
};
}
OR
class Object {
has $.expensive_to_compute_but_cachable is delayed =
...;
}
And no one has to know that it's lazy.
With explicit code refs, you need to make an accessor:
class Object {
has $.expensive_to_compute_but_cachable;
method expensive_to_compute_but_cachable (
$.expensive_to_compute_but_cachable # i forget
how
# autrijus's returned attr on params works
) {
$.expensive_to_compute_but_cachable //= ...;
}
}
Which is just as much headache that we had to do in perl 5.
Also, lazifying semantics are consistent with
sub infix:|| ($left, $right is delayed) {
$left ?? $left :: ** $right; # can you steamroll a scalar?
}
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!!
pgpggG5DzwU3F.pgp
Description: PGP signature
Re: Perl 6 Summary for 2005-08-15 through 2005-08-22
On Aug 23, 2005, at 3:43, Matt Fowles wrote: Perl 6 Summary for 2005-08-15 through 2005-08-22 Java on Parrot I vote for Jot. That's already occupied by another language http://en.wikipedia.org/wiki/Iota_and_Jot. Perl 6 Language Type Inferencing in Perl 5 Autrijus (while discussing type inference in Perl 6) recalled that there was a google summer of code project on Type Inferencing in Perl 5. Gary Jackson, the summer coder, provide a more detailed description of his work. http://search.cpan.org/~bargle/Devel-TypeCheck-0.01/lib/Devel/ TypeCheck.pm Thanks for the summary, leo
Re: Perl 6 Summary for 2005-08-15 through 2005-08-22
On Mon, Aug 22, 2005 at 09:43:41PM -0400, Matt Fowles wrote: Java on Parrot Tim Bunce asked some preliminary questions about Java on Parrot. I provide preliminary answers, and Nattfodd and Autrijus posted links to related work. The important question of what it should be called remained unraised. I vote for Jot. http://xrl.us/g8b9 For the record, my interest isn't so much Java ON Parrot as Java WITH Parrot. Bidirectional interface between the Parrot VM and a linked-in Java VM. Tim.
Re: A PMC class for reference counting
Nicholas Clark wrote: Following on our discussion on IRC, what I think we agreed on was that Parrot should provide a new PMC class functionally similar to how the dod_register_pmc/dod_unregister_pmc works. Quite probably it can share implementation code with the DOD registration system. Done. $ perldoc -F classes/addrregistry.pmc Some tests are in t/op/gc.t There is also a new interface in extend.c to get the Parrot registry: Parrot_PMC Parrot_get_dod_registry(Parrot_INTERP); Nicholas Clark leo
Re: NCI: passing PMCs and using them
Leopold Toetsch wrote:
Klaas-Jan Stol wrote:
hi,
I'm currently trying to check out the NCI. As my Lua compiler only
uses PMCs (and not I/N/S registers), calling C functions will only be
done with PMCs.
I couldn't find info on this matter: suppose I have this string PMC,
how can I access the actual string in it?
so, when calling:
void print_pmc(void *PMC)
{
// how to access the string in P?
}
If it's a stringish PMC, then STRING *s = VTABLE_get_string(INTERP,
p); will do it.
The C code is just in a .c file, it's not like a PMC or something. So, I
don't think I can use INTERP, or VTABLE_get_string() at all. Or should
I link to parrotlib.a or something?
Is there some public API for accessing the fields in a PMC (for standard
PMCs, so accessing the intval for the Integer PMC and its decendents,
floatval for Float PMC, stringval for String PMCs, etc) ?
You might also consider switching to branches/leo-ctx5. The new
calling conventions do auto-conversion betwen PMCs and I/S/N in both
directions for NCI too.
Forgive my ignorance, but I don't really understand. I'm only using
PMCs, no I/S/N values. Why would using these auto-conversions be
interesting?
Btw, I also got this leo-ctx5 branch, compiled it, and run it from the
directory where my lua stuff is, like this:
$ ../leo-ctx5/parrot a.pir
it says:
PackFile_FixupTable_unpack: Unknown fixup type 1953066601!
PackFile_unpack segment 'FIXUP_luaglobals.pir' failed
Segmentation fault
I got this branch by doing this: (was not sure about the command, but I
considered this most probable)
svn checkout http://svn.perl.org/parrot/branches/leo-ctx5
Any idea what's wrong and causing the error?
klaas-jan
Calling positionals by name in presence of a slurpy hash
Hi,
(asking because a test testing for the converse was just checked in to
the Pugs repository [1])
sub foo ($n, *%rest) {...}
foo 13;
# $n receives 13, of course, %rest is ()
foo 13, foo = bar;
# $n receives 13 again, %rest is (foo = bar)
foo n = 13;
# $n receives 13, %rest is (), right?
foo n = 13, foo = bar;
# $n receives 13, %rest is (foo = bar), right?
--Ingo
[1] http://svn.openfoundry.org/pugs/t/subroutines/slurpy_param.t
--
Linux, the choice of a GNU | Row, row, row your bits, gently down the
generation on a dual AMD | stream...
Athlon!|
Python PMC's
Problem: Python PMC's just don't work in the leo-cxt5 branch which will become head/trunk at some time in the hopefully not to distant future. What I've done up time now: I've ported pyint.pmc, pystring.pmc to pass all tests in leo-cxt5 I've written t/dynclasses/pystring.t Note that there are something like 15-20 python.pmc's or which only 4 have corresponding test in I've written t/dynclasses/ I've ripped out a lot of the explicit passing of self as the first argument of pmc methods. - We don't have to pass self around, parrot makes it available to us automatically. Sam's implementation of Python PMC is old and outdated. He did a lot of pioneering work in the realm of the python object system on parrot. Probably the first real attempt at a full object system on top of parrot. Parrot has changed drastically since then. Sam's PMC's were also incomplete, they lacked support for a lot of the __add__ style python methods. This is quite understandable, Sam was trying to get something working. Proposal: I propose to gut all of PyObject, PyFunc, PyClass, PyType PMC's etc. Old New PyObject PyObject - will represent a instantiation of a python class, will inherit from ParrotObject PyClassPyClass - will represent a python class, will inherit from ParrotClass PyType PyMetaClass - will represent the meta-class of a class, this one is still open for debate. I plan on making these changes via test driven development. The plan is to reduce python object system pmc's code content and functionality to zero, and then rebuild it up Mainly because every time I try to morph Sam's code, Leo tells me the whole approach is wrong :) We will rebuild the python object system based on test cases, If functionality is missing, and you want it implemented, write and submit a test case first. One last design note. I had a conversation a long time ago with Dan, in which he agreed that given Python's property bag style object system. That class methods and data members should be stored in parrot properties and the vtable getattribute/setattribute methods for python pmcs should be overridden to use parrot properties instead parrot attributes. Sam's PMC appeared to follow the same idea though not fully flushed out, and I plan on building the new Python PMC in the same manner. Comments welcome. Kevin Tew
Re: Calling positionals by name in presence of a slurpy hash
On 8/23/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
Hi,
(asking because a test testing for the converse was just checked in to
the Pugs repository [1])
sub foo ($n, *%rest) {...}
foo 13;
# $n receives 13, of course, %rest is ()
foo 13, foo = bar;
# $n receives 13 again, %rest is (foo = bar)
foo n = 13;
# $n receives 13, %rest is (), right?
foo n = 13, foo = bar;
# $n receives 13, %rest is (foo = bar), right?
Yep, that's all correct. Matter of fact, what %rest actually gets has
not been defined. Maybe %rest mirrors all the named arguments, maybe
it doesn't. I can see a very small utility if it does, but it seems
like it would be faster[1] if it didn't. I think it's fair to say no
here.
[1] Yeah, yeah, premature optimization and whatnot. You always have
the sig (*%hash) if you really want to.
Luke
~ and + vs. generic eq
I don't like eqv, because it's ugly, inconsistent with anything else
in Perl 6, especially , ||, and ^^. It might be forced to fit into
the and, or, and xor family, but you'd expect to find 'eq' there,
and that's not what it means.
IMHO == is as generic as and ||, and is even more like ^^ since
it also returns a boolean.
the v in eqv is not much of a mnemonic, and overall looks like a
typo more than a meaningful distinction.
Furthermore, people culturally lean towards '==' for generic
equality, and that's what 99% of 'use overload' uses choose on the
CPAN.
Moreover, after a while of programming only real apps, that is,
few throw-away scripts (i think it was a period of 2-3 months) I
suddenly found myself comparing strings with == in such scripts.
I think this is more consistent, and just as useful:
10 == 10; # dispatches to num
10 == 10; # dispatched to Num, by means of coercion (== has some
affinity to it for backwards compatibility)
10 == 10; # dispatches to Str, due to better match
10.0 == 10; # unlike perl 5 this is false
10.0 +== 10; # but this is true
10 ~== 10; # like eq
$obj == $obj; # if $obj.ref implements ==, then goody, if not, i guess
it numifies, or falls back to =:= or whatever identity equality is this week
$obj eq $obj; # just a wrapper for == that is parsed with lower
precedence
$obj +== $obj; # numifies
$obj ~== $obj; # stringifies
@array +== @array; # length
@array == @array; # nested
Here are some reference implementations:
sub infix:+== (Any $l, Any $r -- Bool) { +$l == +$r }
sub infix:~== (Any $l, Any $r -- Bool) { ~$l == ~$r }
sub infix:?== (Any $l, Any $r -- Bool) { ?$l == ?$r } # useless?
multi sub infix:== (Num $l, Num $r -- Bool) { ... }
multi sub infix:== (Str $l, Str $r -- Bool) { ... }
multi sub infix:== (@l, @r -- Bool) { @l.elems +== @r.elems and @l
== @r }
sub infix:eq (Any $l, Any $r) is tighter(infix:and) { $l == $r }
The behavior of == is akin to ~~, for example regarding:
Array Array arrays are identical match if $_ = @x
extracted from S04.
The matchic MMD generator in the prelude, that makes the complex
set of rules found in s04 should simply apply to any infix operator
(and should be applied in the prelude to ~~, as well as ==), so that
~~ and == on collections are defined with the same aggregate
semantics, but MMD ~~ or == applies to the nested elements in the
same shape:
sub extend_comparators (op) {
...
my sub apply_to_arrays (Code op, Array @l, Array @r) {
@l op @r
}
op.add_mmd_variant(apply_to_arrays.assuming(op);
}
for (infix:~~ infix:==) extend_comparators;
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!
pgpISVweS3ChC.pgp
Description: PGP signature
Re: ~ and + vs. generic eq
Hi,
Yuval Kogman wrote:
I think this is more consistent, and just as useful:
10 == 10; # dispatches to num
10 == 10; # dispatched to Num, by means of coercion (== has some
affinity to it for backwards compatibility) 10 == 10; # dispatches
to Str, due to better match 10.0 == 10; # unlike perl 5 this is
false 10.0 +== 10; # but this is true
10 ~== 10; # like eq
sorry, I've some problems with this proposal:
== has always meant numeric equality in Perl and I'd like it to stay
that way.
More importantly, the distinction between +== and ~== is far too subtle,
I think -- the two long =s kind of hide the +~?. You have to look more
carefully to see the distinction between +== and ~==; == vs. eq is much
more apparent, IMHO.
Oh and +== isn't as good huffmanized as == is.
The matchic MMD generator in the prelude, that makes the complex
set of rules found in s04 should simply apply to any infix operator
(and should be applied in the prelude to ~~, as well as ==), so that
~~ and == on collections are defined with the same aggregate
semantics, but MMD ~~ or == applies to the nested elements in the
same shape:
sub extend_comparators (op) {
[...]
I think I like that idea, although I have to admit that I might have not
understood it fully.
I wonder whether it's possible to use an adverbial modifier to specify
the comparator:
say @foo ~~ @bar; # is really
say @foo ~~ @bar :comparator{ $^a ~~ $^b };
say @foo ~~ @bar :comparator{ $^a eq $^b };
say @foo ~~ @bar :comparator{ $^a == $^b };
--Ingo
--
Linux, the choice of a GNU | The future is here. It's just not widely
generation on a dual AMD | distributed yet. -- William Gibson
Athlon!|
Re: [pirate] Python PMC's
Kevin Tew wrote: Problem: Python PMC's just don't work in the leo-cxt5 branch which will become head/trunk at some time in the hopefully not to distant future. What I've done up time now: I've ported pyint.pmc, pystring.pmc to pass all tests in leo-cxt5 I've written t/dynclasses/pystring.t Note that there are something like 15-20 python.pmc's or which only 4 have corresponding test in I've written t/dynclasses/ I've ripped out a lot of the explicit passing of self as the first argument of pmc methods. - We don't have to pass self around, parrot makes it available to us automatically. I added self on Leo's request. Now it is unneccessary. *shrug* Sam's implementation of Python PMC is old and outdated. He did a lot of pioneering work in the realm of the python object system on parrot. Probably the first real attempt at a full object system on top of parrot. Parrot has changed drastically since then. Sam's PMC's were also incomplete, they lacked support for a lot of the __add__ style python methods. This is quite understandable, Sam was trying to get something working. Check out parrot/t/dynclass/pyint_2.pmc. __add__ style methods were working, and tested. Proposal: I propose to gut all of PyObject, PyFunc, PyClass, PyType PMC's etc. Old New PyObject PyObject - will represent a instantiation of a python class, will inherit from ParrotObject PyClassPyClass - will represent a python class, will inherit from ParrotClass PyType PyMetaClass - will represent the meta-class of a class, this one is still open for debate. I plan on making these changes via test driven development. The plan is to reduce python object system pmc's code content and functionality to zero, and then rebuild it up Mainly because every time I try to morph Sam's code, Leo tells me the whole approach is wrong :) We will rebuild the python object system based on test cases, If functionality is missing, and you want it implemented, write and submit a test case first. No matter what you do, Leo will tell you that the whole approach is wrong. I talked this past weekend with Larry Wall, Chip Saltzberg, and chromatic. Hopefully we will get some more people involved. Leo is great at details, but has a tendency to set a new direction every week. I say that knowing that Leo follows this list. (Hi Leo!) I do agree with test-driven development. That is exactly the approach I took. I will also state that I learned a lot *ABOUT* *PYTHON* in running the pie-thon tests. I'd recommend that you don't gut until you try the following: * PirateTest.py is a good sanity test to say that you have something resembling python to work with. Until that test passes, there isn't much point. * parrot/t/dynclasses give you a similar level of confidence in the pmcs. * Once you get that far, cd to parrot/languages/python and issue make. That will run the various tests (culiminating in the pie-thon tests themselves). To run that test, you will need a small batch file in your search PATH named pirate. Mine looks like: export LD_LIBRARY_PATH=/home/rubys/runtime/parrot/dynext python /home/rubys/pirate/pirate.py $* One last design note. I had a conversation a long time ago with Dan, in which he agreed that given Python's property bag style object system. That class methods and data members should be stored in parrot properties and the vtable getattribute/setattribute methods for python pmcs should be overridden to use parrot properties instead parrot attributes. Sam's PMC appeared to follow the same idea though not fully flushed out, and I plan on building the new Python PMC in the same manner. It just might be more fully flushed out than you appreciate. Comments welcome. I'm following this list, and questions are welcome in return. Again, my suggestion is to try to get the existing tests to work again - modifying the tests as necessary to remove now unnecessary self parameters. And, again, resist the temptation to follow Leo's advice du jour. Focus on what is actually implemented - while that does change over time, running code has a tendency to change more slowly than the advice you may receive. Kevin Tew ___ pirate mailing list [EMAIL PROTECTED] http://cornerhost.com/mailman/listinfo/pirate - Sam Ruby
Re: NCI: passing PMCs and using them
On Aug 23, 2005, at 14:38, Klaas-Jan Stol wrote:
Leopold Toetsch wrote:
Klaas-Jan Stol wrote:
void print_pmc(void *PMC)
{
// how to access the string in P?
}
If it's a stringish PMC, then STRING *s = VTABLE_get_string(INTERP,
p); will do it.
The C code is just in a .c file, it's not like a PMC or something. So,
I don't think I can use INTERP, or VTABLE_get_string() at all. Or
should I link to parrotlib.a or something?
INTERP is just translated to interpreter (see any classes/.c file).
VTABLE_get_string is available in the whole Parrot tree, it's a macro
define in include/parrot/vtable.h. I don't know in what relation your
plain .c file is to parrot, but you might have a look at
src/extend.c, which also provides interfaces for such stuff.
Is there some public API for accessing the fields in a PMC (for
standard PMCs, so accessing the intval for the Integer PMC and its
decendents, floatval for Float PMC, stringval for String PMCs, etc) ?
Have a look at src/extend.c for the most abstract API.
You might also consider switching to branches/leo-ctx5. The new
calling conventions do auto-conversion betwen PMCs and I/S/N in both
directions for NCI too.
Forgive my ignorance, but I don't really understand. I'm only using
PMCs, no I/S/N values. Why would using these auto-conversions be
interesting?
If you are calling a NCI method, which takes native types (or returns
one) from PIR, you can still pass in PMCs (and will get a PMC as
result, if appropriate).
Btw, I also got this leo-ctx5 branch, compiled it, and run it from the
directory where my lua stuff is, like this:
$ ../leo-ctx5/parrot a.pir
it says:
PackFile_FixupTable_unpack: Unknown fixup type 1953066601!
PackFile_unpack segment 'FIXUP_luaglobals.pir' failed
$ make realclean and be sure to delete your .pbc files too. You can't
share PBCs between trunk and leo-ctx5 - run a.pir in distinct
directories.
klaas-jan
leo
Re: ~ and + vs. generic eq
On Tue, Aug 23, 2005 at 18:15:07 +0200, Ingo Blechschmidt wrote:
sorry, I've some problems with this proposal:
== has always meant numeric equality in Perl and I'd like it to stay
that way.
For simple values like numbers and strings == is numberic, because
it's affinity to it.
snip
10 == 10; # dispatched to Num, by means of coercion (== has some
affinity to it for backwards compatibility)
/snip
I guess the difference is that this will fallback to dispatching to
strings if 10 can't be numified.
I think what sets perl 6 apart from perl 5 is that it's 95% as
optimized for simple values as perl 5 was, but a magnitude times
better for complex types (first class functions, better objects),
and in this sense generic equality is a place I find the current
spec lacking.
More importantly, the distinction between +== and ~== is far too subtle,
I think -- the two long =s kind of hide the +~?. You have to look more
carefully to see the distinction between +== and ~==; == vs. eq is much
more apparent, IMHO.
Arguably it should only matter when it's explicitly stated, so in
this case I think your argument is very strong. The only difference
is that I don't feel that ~== and +== are very close to == visually,
and although they are hard to distinguish, they do stand apart from
just bare ==.
Oh and +== isn't as good huffmanized as == is.
99% of the time you should use == for numbers anyway... It's
unambiguous.
The matchic MMD generator in the prelude, that makes the complex
set of rules found in s04 should simply apply to any infix operator
(and should be applied in the prelude to ~~, as well as ==), so that
~~ and == on collections are defined with the same aggregate
semantics, but MMD ~~ or == applies to the nested elements in the
same shape:
sub extend_comparators (op) {
[...]
I think I like that idea, although I have to admit that I might have not
understood it fully.
I wonder whether it's possible to use an adverbial modifier to specify
the comparator:
say @foo ~~ @bar; # is really
say @foo ~~ @bar :comparator{ $^a ~~ $^b };
say @foo ~~ @bar :comparator{ $^a eq $^b };
say @foo ~~ @bar :comparator{ $^a == $^b };
In this example I would say
my sub comparator ($a, $b) { .. your comparison here };
Prelude::extend_comparators(comparator);
say comparator(@foo @bar);
and the name comparator could be a lexically scoped infix:~~ just the
same.
It's not as short, but I'm sure an evil macro could be cooked up if
it recurrs.
We can even specify
multi infix:~~ (Any $a, Any $b, :comparator) { # what is the
# syntax for mandatory positionals nowadays?
my augmented = comparator; # a copy
Prelude::extend_comparators(augmented);
augmented($a, $b);
}
And have your interface wrap around this behavior.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me beats up some cheese: neeyah!
pgpT5UYfABJHt.pgp
Description: PGP signature
Re: ~ and + vs. generic eq
On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote: : 10 == 10; # dispatches to Str, due to better match Nope, that will continue to coerce to numeric comparison. The design team did in fact consider pure equivalence MMD dispatch of == in the last meeting, but rejected it in favor of eqv, which has the benefit of looking more Huffmanly abstract to Perl 5 and C programmers. Otherwise we lose the main point of being an operator-rich language, which is to use the operators to drive coercion in the common cases instead continually casting between strings and numbers. Larry
Re: [pirate] Python PMC's
On Aug 23, 2005, at 17:09, Kevin Tew wrote: Problem: Python PMC's just don't work in the leo-cxt5 branch which will become head/trunk at some time in the hopefully not to distant future. Err, I hope to merge RSN ;-) I had a conversation a long time ago with Dan, in which he agreed that given Python's property bag style object system. That class methods and data members should be stored in parrot properties and the vtable getattribute/setattribute methods for python pmcs should be overridden to use parrot properties instead parrot attributes. This isn't quite right - or only partially I think. The main problem with properties is: props dont' inherit. It of course depends a lot on the Pyton - PIR translator. But I think the following strategy should work: - use parrot object system with a PyClass base class - make the compiler smarter about attribute access, it can create a list of attribute names - let these static attributes be handled by the parrot code - provide an additional hash slot (__dict__) as another internal attribute for dynamic attributes and per object attributes - Python __slots__ translates to the arrayish Parrot layout w/o changes probably - you have to check for __xxx__ attributes anyway to get e.g. overloading or other special attribute handling done correctly. Comments welcome. Kevin Tew leo
Re: [pirate] Python PMC's
On Tue, Aug 23, 2005 at 12:21:42PM -0400, Sam Ruby wrote: Kevin Tew wrote: I've ripped out a lot of the explicit passing of self as the first argument of pmc methods. - We don't have to pass self around, parrot makes it available to us automatically. I added self on Leo's request. Now it is unneccessary. *shrug* Parrot's calling conventions having updated, everybody must adjust, it's not about Pirate. I like to think that this most recent change in calling convention is an improvement, by and large. Sam's implementation of Python PMC is old and outdated. He did a lot of pioneering work in the realm of the python object system on parrot. Probably the first real attempt at a full object system on top of parrot. Parrot has changed drastically since then. Sam's PMC's were also incomplete, they lacked support for a lot of the __add__ style python methods. This is quite understandable, Sam was trying to get something working. Check out parrot/t/dynclass/pyint_2.pmc. __add__ style methods were working, and tested. I remember seeing the implementation of __*__. It looked fine to me in design, though I didn't review every particular one. At OSCON I learned that IronPython contrives to make CLR classes look just like native Python classes even under introspection, and that's just plain nifty. The Parrot equivalent would be to make the class look like it has an __add__ method iff the underlying Parrot class implements __add. Interesting? The plan is to reduce python object system pmc's code content and functionality to zero, and then rebuild it up Mainly because every time I try to morph Sam's code, Leo tells me the whole approach is wrong :) No matter what you do, Leo will tell you that the whole approach is wrong. It's a fair cop. Leo's always has strong ideas about how things should evolve. But in language-specific code like the Python classes, I don't see why Leo -- or I, for that matter -- should have standing to tell you what to do. If Python users are happy with the results, whatever they may be, and if the core functionality of Parrot isn't impacted for other languages, more power to you. If we got all unreasonable on you, you'd just take Pirate development out of the Parrot tree or else just quit, and neither of those alternatives is good for Parrot. As Larry says: Live and let learn. Therefore, if you _want_ to rebuild from zero, please by all means go ahead. Just be prepared to discover that the original structure was actually better than you thought. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [pirate] Python PMC's
On Tue, Aug 23, 2005 at 06:35:39PM +0200, Leopold Toetsch wrote: On Aug 23, 2005, at 17:09, Kevin Tew wrote: Problem: Python PMC's just don't work in the leo-cxt5 branch which will become head/trunk at some time in the hopefully not to distant future. Err, I hope to merge RSN ;-) That's my Parrot priority this week: the leo-ctx5 branch. I know I like the feature set, and it's just a matter of reviewing the interface and implementation details. And, since the collective You are reading this message, which therefore must exist, it can be deduced that I have more Parrot bandwidth this week than I have for the past $TIMEPERIOD. :-) -- Chip Salzenberg [EMAIL PROTECTED]
Re: [pirate] Python PMC's
On Aug 23, 2005, at 18:21, Sam Ruby wrote:
Kevin Tew wrote:
We don't have to pass self around, parrot
makes it available to us automatically.
I added self on Leo's request. Now it is unneccessary. *shrug*
Parrot's new calling conventions are passing 'self' as the first
argument of a method. Therefore all the old workarounds like:
METHOD PMC* __abs__(Interp* interp, PMC* SELF, PMC* self) {}
aren't needed any more.
Sam's PMC's were also incomplete, they lacked support for a lot of the
__add__ style python methods. This is quite understandable, Sam was
trying to get something working.
Check out parrot/t/dynclass/pyint_2.pmc. __add__ style methods were
working, and tested.
PMC* __add__(PMC *self, PMC *value)
Please note that this signature includes like above already the
interpreter and, SELF i.e. the invocant PMC. This is for sure not
correct. The implementation is in pyobject.pmc and redispatches via MMD
to the actual multi sub.
So yes, the pyint.t test worked - overloading didn't.
No matter what you do, Leo will tell you that the whole approach is
wrong. I talked this past weekend with Larry Wall, Chip Saltzberg, and
chromatic. Hopefully we will get some more people involved. Leo is
great at details, but has a tendency to set a new direction every week.
I say that knowing that Leo follows this list. (Hi Leo!)
One year ago we had some discussion, where e.g. we both stated that the
object should be passed as first argument to methods. Now it's
eventually done in my branch.
I do agree with test-driven development. That is exactly the approach
I
took.
Well, I agree - until I see such tests (pyint_1):
$P2 = $P1.__abs__($P1)
- Sam Ruby
leo
Re: Calling positionals by name in presence of a slurpy hash
On Tue, Aug 23, 2005 at 09:11:15AM -0600, Luke Palmer wrote:
: On 8/23/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
: Hi,
:
: (asking because a test testing for the converse was just checked in to
: the Pugs repository [1])
:
: sub foo ($n, *%rest) {...}
:
: foo 13;
: # $n receives 13, of course, %rest is ()
:
: foo 13, foo = bar;
: # $n receives 13 again, %rest is (foo = bar)
:
: foo n = 13;
: # $n receives 13, %rest is (), right?
:
: foo n = 13, foo = bar;
: # $n receives 13, %rest is (foo = bar), right?
:
: Yep, that's all correct. Matter of fact, what %rest actually gets has
: not been defined. Maybe %rest mirrors all the named arguments, maybe
: it doesn't. I can see a very small utility if it does, but it seems
: like it would be faster[1] if it didn't. I think it's fair to say no
: here.
:
: [1] Yeah, yeah, premature optimization and whatnot. You always have
: the sig (*%hash) if you really want to.
The Apocalypse explicitly left the question open because of the
performance issue, since we might be forced into copying all the
entries of a potentially huge hash just to weed out a few entries.
(Think environment variables.)
You can't just mark certain entries as unavailable since it's probably
a reference to someone else's hash. You could set up a proxying
filter hash that makes some of the keys vanish, but then you're at
the mercy of the owner of the real hash not to change the proxied
hash while your function is executing, and there's some overhead in
setting up the proxy hash. It's possible that COW hashes can be made
to work efficiently. We'll need to copy hashes if we want to modify
them to pass to subfunctions, just as when you change your environment
it doesn't affect your parent process's environment variables.
Actually, I envision the named arguments coming in as a separate list
of pairs and hash refs, so we could just say that all readonly access
to the slurpy hash actually scans that argument list. That assumes
that we don't care that much about the efficiency of environmental
lookups, but I think it might optimize for the common case of argument
binding if we process positionals in order and do scanning lookups in
the named list for missing positionals. Doing your primary scan on
the named list to look for things that might or might not be wanted
in the positional list is going to be really slow in cases where a
lot of environment is passed around.
Anyway, what I'm saying is that, assuming we bind the slurpy hash
interface to the list implementation, we could just put nulling
entries on the front of that list as we use up keys. So maybe that's
a way to remove keys that's not too much overhead. I suppose we could
even suppress that if there was a pragma allowing dups. So there's
something to be said for the cleaner semantics.
On the other hand, maybe those semantics are not actually cleaner.
If we take environment variables as our model, we *don't* remove
them from the environment when we use them, since child processes
may want the same value. If we weed out values from the slurpy
hash, we force environmental hashes to be passed some other way.
Whether that's a feature or not depends on whether you view such an
environment as default values for named parameter bindings.
Larry
Re: Can a scalar be lazy ?
On Tue, Aug 23, 2005 at 11:03:52AM +0300, Yuval Kogman wrote:
: On Mon, Aug 22, 2005 at 13:25:57 -0700, Larry Wall wrote:
: On Tue, Aug 23, 2005 at 04:09:29AM +0800, Yiyi Hu wrote:
: : my( $s, $t ); $s = value t is $t; $t = xyz; print $s;
: : in perl 5, it will give a warning, and won't do right thing.
: : we have to use other way or eval '$s' before print to get a correct
answer.
: :
: : So I wonder, If we can make $scalar lazy also. As array now is lazy by
default.
: :
: : Even if making scalar lazy might cause problem sometimes, Is it
: : possible to add a property which is like
: : my $var is lazy; to handle these situation?
:
: In Perl 6 you make lazy scalars by putting curlies around them:
:
: my( $s, $t ); $s = { value t is $t }; $t = xyz; print $s();
:
: Currently we also require the de-lazifying context to supply a
: postfix .() marker, but possibly that could be assumed in a string
: or numeric context.
:
: I really don't see much benefit in making it easier than that.
:
: I see one:
:
: class Object {
: has $.expensive_to_compute_but_cachable = delay {
: ...
: };
: }
Which already seems to be there with
lazy {...}
which is, I presume, mostly syntactic sugar for something like:
sub is cached {...}
along with the notion of implicit .() on value use, as I already
conceded above. Plus we can assume is cached on any function
that can be proven pure. So I think maybe you're responding to a
different position than the one I'm actually taking.
: OR
:
: class Object {
: has $.expensive_to_compute_but_cachable is delayed =
...;
: }
:
: And no one has to know that it's lazy.
:
: With explicit code refs, you need to make an accessor:
:
: class Object {
: has $.expensive_to_compute_but_cachable;
:
: method expensive_to_compute_but_cachable (
: $.expensive_to_compute_but_cachable # i forget
how
: # autrijus's returned attr on params works
: ) {
: $.expensive_to_compute_but_cachable //= ...;
: }
: }
:
: Which is just as much headache that we had to do in perl 5.
We could probably extend is cached to attributes (and their implied
accessors) if lazy blocks aren't sufficient.
: Also, lazifying semantics are consistent with
:
: sub infix:|| ($left, $right is delayed) {
: $left ?? $left :: ** $right; # can you steamroll a scalar?
: }
I'd really like to discourage people from writing thunks without curlies.
I don't think steamrollering a scalar works--it would just take it
as an operation on a list rather than on the elements of the list.
You can't really delazify until you know what kind of a scalar you
want, I suspect, because the lazy closure itself might need to know
in what context to run. Otherwise you just have to return a proxy
object that might turn into a string or number or int or whatever
value is eventually wanted. Of course, presumably infix:|| has
that context already, so maybe we're looking for something like
$right.want
to force value-finding behavior iff it's called for. After all, you
probably want it to stay lazy if you call it in undifferentiated scalar
context:
$x = $y || lazy { z() }
But maybe I'm confusing levels there. Wouldn't be the first time...
Larry
Re: Can a scalar be lazy ?
On Tue, Aug 23, 2005 at 10:56:08 -0700, Larry Wall wrote:
We could probably extend is cached to attributes (and their implied
accessors) if lazy blocks aren't sufficient.
Hmm... With the whole distinction of foo as a value and foo() as a
application of the value, maybe we can sometimes assign a sub as an
rvalue by making a weak call.
sub lazy (Code f) {
return f.weak_call;
}
I like the relation to is cached, but I think it might be incorrect,
if the lazy block is reused.
BTW, I'm the nothingmuch who initially lobbied for lazy { }... =)
: sub infix:|| ($left, $right is delayed) {
: $left ?? $left :: ** $right; # can you steamroll a scalar?
: }
I'd really like to discourage people from writing thunks without curlies.
Then how do we define infix:||'s prototype?
I don't think steamrollering a scalar works--it would just take it
as an operation on a list rather than on the elements of the list.
You can't really delazify until you know what kind of a scalar you
want, I suspect, because the lazy closure itself might need to know
in what context to run. Otherwise you just have to return a proxy
object that might turn into a string or number or int or whatever
value is eventually wanted. Of course, presumably infix:|| has
that context already, so maybe we're looking for something like
$right.want
This makes sense, but shuts off the 'want' behavior.
I think we should have an implicit $?CONTEXT object in each sub, and
then you can say to it
$?CONTEXT.unwrap($right);
or something along that metaphor.
This is also nice for things like
method moose (...) {
my Container $x = $?CONTEXT.eval( $?SELF.SUPER::moose ); #
maybe even a bit like Sub::Uplevel
...
# you can look inside $x now, but you can't damage it
# anymore
...
$x.unwrap; # this serves as context passthrough
}
to force value-finding behavior iff it's called for. After all, you
probably want it to stay lazy if you call it in undifferentiated scalar
context:
$x = $y || lazy { z() }
Yes, I didn't think about that... This is lazyness stacking though,
I think.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /methinks long and hard, and runs away: neeyah!!!
pgpwvUluaTRr8.pgp
Description: PGP signature
Re: [pirate] Python PMC's
Leopold Toetsch wrote: I do agree with test-driven development. That is exactly the approach I took. Well, I agree - until I see such tests (pyint_1): $P2 = $P1.__abs__($P1) Take a look at the difference between r7254 and r7312. The tests originally passed without a self argument. Then I was told that that was all wrong, so I changed it (both the test and the code). Now Kevin is being told that passing self is all wrong. Reverting that particular change is not all that difficult. And it can be done without gutting. - Sam Ruby
Re: [pirate] Python PMC's
Sam, Thanks for the comments, They were very much appreciated. Sam Ruby wrote: I added self on Leo's request. Now it is unneccessary. *shrug* I understand completely. Check out parrot/t/dynclass/pyint_2.pmc. __add__ style methods were working, and tested. Yes many are working, I should clarify, there are more to be added. No matter what you do, Leo will tell you that the whole approach is wrong. I talked this past weekend with Larry Wall, Chip Saltzberg, and chromatic. Hopefully we will get some more people involved. Leo is great at details, but has a tendency to set a new direction every week. I say that knowing that Leo follows this list. (Hi Leo!) I do agree with test-driven development. That is exactly the approach I took. I will also state that I learned a lot *ABOUT* *PYTHON* in running the pie-thon tests. I'd recommend that you don't gut until you try the following: * PirateTest.py is a good sanity test to say that you have something resembling python to work with. Until that test passes, there isn't much point. * parrot/t/dynclasses give you a similar level of confidence in the pmcs. * Once you get that far, cd to parrot/languages/python and issue make. That will run the various tests (culiminating in the pie-thon tests themselves). To run that test, you will need a small batch file in your search PATH named pirate. Mine looks like: export LD_LIBRARY_PATH=/home/rubys/runtime/parrot/dynext python /home/rubys/pirate/pirate.py $* Point well taken, I've been leaning back between, rewrite and evolving your work. I have a current change set that is passing most of your original tests that are in t/dynclasses/py*.t It is more of an evolution than a rewrite, which I favor. Some test fail due to remaining uunimplemented features in leo-cxt5(default args), or my lack of understanding. But a lot of the tests pass. I wrote the original email, mainly because I didn't agree with all of leo's comment. I do however value his insight and like to hear his ideas. I have learned what I know about parrot in many cases due to pestering Leo with questions. Leo++. Without Leo, I'd still probably be more lost than I am now. That being said I will continue with the evolution path rather than a gut and rewrite. One last design note. I had a conversation a long time ago with Dan, in which he agreed that given Python's property bag style object system. That class methods and data members should be stored in parrot properties and the vtable getattribute/setattribute methods for python pmcs should be overridden to use parrot properties instead parrot attributes. Sam's PMC appeared to follow the same idea though not fully flushed out, and I plan on building the new Python PMC in the same manner. It just might be more fully flushed out than you appreciate. Your completely right. My apologies. Bad last sentence of the paragraph on my part. I was trying to get some explanation and/or debate on attributes vs properties, which Leo seems to have done in his reply. Comments welcome. I'm following this list, and questions are welcome in return. Again, my suggestion is to try to get the existing tests to work again - modifying the tests as necessary to remove now unnecessary self parameters. And, again, resist the temptation to follow Leo's advice du jour. Focus on what is actually implemented - while that does change over time, running code has a tendency to change more slowly than the advice you may receive. Will do, attached is my work in progress for those interested. Comments appreciated and welcome.
Re: [pirate] Python PMC's Missed attachment
My current work. Python PMC Patch to leo5-cxt5
Re: [pirate] Python PMC's
Kevin Tew wrote: Point well taken, I've been leaning back between, rewrite and evolving your work. I have a current change set that is passing most of your original tests that are in t/dynclasses/py*.t It is more of an evolution than a rewrite, which I favor. Some test fail due to remaining uunimplemented features in leo-cxt5(default args), or my lack of understanding. But a lot of the tests pass. Take a look at the following: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type help, copyright, credits or license for more information. def f(a,b=1,c=2): ... pass ... f.func_defaults (1, 2) In December, this was fully implemented and tested. In pirate.py, search for self.append(setprop %s, 'func_defaults', %s % (ref, defaults)) and search for func_defaults in pyfunc.pmc, pyboundcall.pmc, and pybuiltin.pmc. Finally, take a look at the third test in parrot/languages/python/t/basic/func.t - Sam Ruby
defaults (was: Python PMC's)
How will Perl6 evaluate defaults? Like Python: global x x=1 def f(p1=x): return p1 x=2 print f() or like Ruby: $x=1 def f(p1=$x) return p1 end $x=2 puts f() - Sam Ruby P.S. The former prints 1, the latter, 2.
Re: [pirate] Python PMC's
On Aug 23, 2005, at 20:28, Sam Ruby wrote: Leopold Toetsch wrote: I do agree with test-driven development. That is exactly the approach I took. Well, I agree - until I see such tests (pyint_1): $P2 = $P1.__abs__($P1) Take a look at the difference between r7254 and r7312. I just find a log message about the change w/o any reason. I have always proposed (against Dan's opinion) the the object should be passed as the first argument to methods. This is done now. I've stated that the old MMD syntax, which needed to pass the existing destination PMC is inappropriate, suboptimal and whatever for almost all HLLs. Now you have a complete opcode subset that returns *new* destination PMCs. http://xrl.us/g9dp .pragma n_operators 1 ... $P0 = $P1 + $P2 # return new $P0 PMC Here is a test I've written for pycomplex: .pragma n_operators 1 .HLL Python, python_group .sub main @MAIN .local pmc d, c c = new .PyComplex c = 3+4j d = abs c print d print \n $S0 = typeof d print $S0 print \n .end And *yes* that creates a new PyFloat. Please also not that python_group is autoloaded. Sam, please follow Parrot dev (or stop spreading FUD) - thanks. The tests originally passed without a self argument. Then I was told that that was all wrong, so I changed it (both the test and the code). Please show me one message where you was told that abs has a signature of that one in the test or that another 'self' should be passed in. - Sam Ruby leo
Re: [pirate] Python PMC's
On Tue, Aug 23, 2005 at 09:58:21PM +0200, Leopold Toetsch wrote: Sam, please follow Parrot dev (or stop spreading FUD) - thanks. Be gentle, please. Parrot needs language developers. I'm not saying you're right or wrong. I'm just asking you to be a little more diplomatic. -- Chip Salzenberg [EMAIL PROTECTED]
Re: defaults (was: Python PMC's)
On Tue, Aug 23, 2005 at 03:48:03PM -0400, Sam Ruby wrote: How will Perl6 evaluate defaults? I would like to help with this question, but I can't, and in general p6i won't be the right place to ask. Nobody knows the final form of Perl 6; nobody knows the currently understood form of Perl 6 except for @Larry. You're likely to get a provisionally correct answer if you ask the perl6-language list. I can talk about Parrot, though. Parrot has no concept of default values. It does have a concept of optional parameters. How they're filled in is entirely an HLL decision. -- Chip Salzenberg [EMAIL PROTECTED]
Re: ~ and + vs. generic eq
On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote: On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote: : 10 == 10; # dispatches to Str, due to better match Nope, that will continue to coerce to numeric comparison. The design team did in fact consider pure equivalence MMD dispatch of == in the last meeting, but rejected it in favor of eqv BTW, regardless of whether it's called 'eqv' or '==', the semantics shared between the MMD variants of ~~ and eqv as proposed in the bottom of the message are not utter crap, right? -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me does a karate-chop-flip: neeyah!! pgpvpO6wniHfk.pgp Description: PGP signature
Re: Python PMC's
On Aug 23, 2005, at 22:48, Sam Ruby wrote: From December 16, 2004: http://tinyurl.com/8smmq Sounds like a really ugly misunderstanding, the more that I've proposed not to pass the object (P2 in old parlance) out of band. I've stated several times that calling conventions need changes to properly support HLLs with minor success at these times. What I've always said (and what is actually implemented now in the branch) is that methods gets the object as its first argument. A typical snippet in PIR code is now .sub __abs .param pmc self or if denoted as method: .sub __abs method # 'self' param automagically available The first argument of NCI or vtable methods is and was always SELF, which usually is the invocant and always is the object (the current only excpetion is an invocation through super()). I'm sorry if this caused confusion. - Sam Ruby leo
Re: Python PMC's
Leopold Toetsch wrote: On Aug 23, 2005, at 22:48, Sam Ruby wrote: From December 16, 2004: http://tinyurl.com/8smmq Sounds like a really ugly misunderstanding, the more that I've proposed not to pass the object (P2 in old parlance) out of band. I've stated several times that calling conventions need changes to properly support HLLs with minor success at these times. With the diversity of HLLs out there, I'm not certain that it is wise to declare one set of semantics proper, thereby implicitly declaring all others improper. What I've always said (and what is actually implemented now in the branch) is that methods gets the object as its first argument. A typical snippet in PIR code is now .sub __abs .param pmc self or if denoted as method: .sub __abs method # 'self' param automagically available The first argument of NCI or vtable methods is and was always SELF, which usually is the invocant and always is the object (the current only excpetion is an invocation through super()). It might help to anchor this discussion if we focus on a tangible test case. In particular, lets look at the first few lines of the first pie-thon test, which can be found here: http://svn.perl.org/parrot/trunk/languages/python/t/pie/b0.t What code should be generated for the declaration of proto___new__ or proto___repr__ functions? What code should be generated for the various assignment statements in the declaration of the method __new__ inside the MetaToken class? Particularly, the one involving a staticmethod? The conclusion I came to is that there is no way to tell in advance how a given function or method in Python is ever going to be called as there effectively is no difference between the two. - Sam Ruby
Re: ~ and + vs. generic eq
On Wed, Aug 24, 2005 at 12:43:46AM +0300, Yuval Kogman wrote:
: On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote:
: On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
: : 10 == 10; # dispatches to Str, due to better match
:
: Nope, that will continue to coerce to numeric comparison. The design
: team did in fact consider pure equivalence MMD dispatch of == in
: the last meeting, but rejected it in favor of eqv
:
: BTW, regardless of whether it's called 'eqv' or '==', the semantics
: shared between the MMD variants of ~~ and eqv as proposed in the
: bottom of the message are not utter crap, right?
Hmm, well, I don't think op is valid syntax, but you did say
semantics, so I can't criticize that part. :-)
Not that the rest of what I say amounts to criticism. More just thinking
in your general direction.
I don't know how close ~~ and eqv will end up. There are some
differences in emphasis, and when two operators get too much like each
other, I tend to add more differences to make them inhabit different
parts of the solution space. One current difference is that, despite
the symmetry of ~~, it's not actually a symmetrical operator much of
the time, such as when matching values to rules. ~~ is intended to
be heavily dwimmical, so it's allowed to do various kinds of abstract
coercions to figure out some mystical good enough quotient. But eqv
on the other hand should probably be false in asymmetrical situations.
The implementation of ~~ may delegate to eqv in certain symmetrical
situations, of course.
Another difference in emphasis is that eqv is intended to equate values
(one of the reasons for the 'v') that would be treated as equal when used
as keys of an object hash. Now the funny thing about an object hash is
that you don't ever want to hash based on a mutable value. Ordinary
value types are immutable, so this 42 is the same as that 42 over there.
So we have
$a = 42;
$b = 42;
$a eqv $b # always true
$a =:= $b # might be true
The =:= operator always compares object identities, even if the
objects want to pretend to be values. So eqv lets them pretend,
while =:= doesn't. But for objects that don't want to pretend to be
values, eqv can delegate to =:=.
On the other hand, it's not clear whether eqv (and by extension hashes)
should take snapshots of mutable values. That is, it's not clear
whether this should say true true or false false:
my %hash is shape(Object);
%hash{ [1,2,3] } = 1;
if exists %hash{ [1,2,3] } { say true } else { say false }
if [1,2,3] eqv [1,2,3] { say true } else { say false }
But whatever it says, I think it should say the same thing both times.
Certainly if we had Pythonic immutable tuples
if (1,2,3) eqv (1,2,3) { say true } else { say false }
should say true, since those are the same values, and they can't
change. However, in Perl-5-Think, [1,2,3] produces mutable arrays,
so unless we come up with some kind of fancy COW for [1,2,3] to be
considered immutable until someone, er, mutes it, I think eqv would
have to return false, and consider two such objects to be different
values (potentially different if not actually different).
It would be possible to declare %hash some way that forces a snapshot
via some kind of serialization or other, but then it gets hard to keep
the identity around. Then the question arises how we doctor
if [1,2,3] eqv [1,2,3] { say true } else { say false }
to do the same snapshot comparison. Arguably ~~ could do it, since it's
explicitly *not* about identity.
if [1,2,3] ~~ [1,2,3] { say true } else { say false }
Or we could have a more explicit way of doing whatever it is that the
snapshot hash does to each argument.
if [1,2,3].snap eqv [1,2,3].snap { say true } else { say false }
Or we could have a different operator that coerces like == and eq, only
via .snap:
if [1,2,3] equals [1,2,3] { say true } else { say false }
(Actual name negotiable, of course). The advantage of the latter approach
is that you can say
@foo equals @bar
and the .snaps are automatically distributed. Otherwise you'd have to say
@foo.snap eqv @bar.snap
which is a pain. On top of which, equals doesn't actually have to
implemented in terms of .snap--it could just compare the current
values of the mutable objects directly. (Just as =:= doesn't have
to be implemented in terms of .id.)
Larry
Re: Python PMC's
Chip Salzenberg wrote: On Tue, Aug 23, 2005 at 07:15:41PM -0400, Sam Ruby wrote: Leopold Toetsch wrote: I've stated several times that calling conventions need changes to properly support HLLs with minor success at these times. With the diversity of HLLs out there, I'm not certain that it is wise to declare one set of semantics proper, thereby implicitly declaring all others improper. Well, let's try more coherent and less confusing, then, or maybe just better. HLLs don't have to expose the 'self' parameter if they don't want to. Just extract it into a PMC register that's never used. Let me try again to move the discussion from subjective adjectives to objective code. Consider: def f(x,y): return y class Foo: f = f def g(self,y): return y foo = Foo() g=foo.g print f(0,1) print foo.f(2) print g(3) If you run this, you will get 1,2,3. When called as a function, f will return the value of the second parameter. When called as a method, the same code will need to return the value of the first parameter. I'm open to suggestions as to what PIR code should be emitted by Pirate to correspond to the above code. The way this currently works with Pirate and the existing Py*.pmc closely follows the Python definition, which you can find here: http://users.rcn.com/python/download/Descriptor.htm#functions-and-methods To illustrate how this works today, lets consider the call to foo.f(2) above. This involves both a find_method and an invoke. Lets consider each in turn: * pyclass.find_method first calls getprop on f. * pyclass.find_method then calls __get__ on the pyfunc returned, passing the object on which this method was called on. * pyfunc.__get__ creates a new PyBoundMeth object, saving both the original function and the object. * This PyBoundMeth object is then returned then: * pyboundmeth.invoke shifts all registers right, inserts the original object as the first parameter, and then calls invoke on the original function. Needless to say, this doesn't necessarily show off Parrot to its best advantage from a performance perspective. I tried a number of times to argue for a combined find_and_invoke VTABLE entry as much of the above can be optimized if you know that result of the find_method will only be used a single time for an invoke. If you like, you can scan the archives to see what reception this suggestion received. Precisely emulating the behavior above is an important part of distinguishing a Python-like language from a true Python language, and is necessary to pass the b0 pie-thon test (grep for __get__ to see what I mean). As to whether this is more coherent and less confusing, then, or maybe just better... well, lets just say that I'll leave the adjectives to others. - Sam Ruby
Re: Python PMC's
On Tue, Aug 23, 2005 at 07:15:41PM -0400, Sam Ruby wrote: Leopold Toetsch wrote: I've stated several times that calling conventions need changes to properly support HLLs with minor success at these times. With the diversity of HLLs out there, I'm not certain that it is wise to declare one set of semantics proper, thereby implicitly declaring all others improper. Well, let's try more coherent and less confusing, then, or maybe just better. HLLs don't have to expose the 'self' parameter if they don't want to. Just extract it into a PMC register that's never used. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Python PMC's
I apologize to Leo for accidentally making this reply to the list. It was supposed to be private mail, but I hit 'y' just a _little_ too soon. I had no intention of embarassing anyone. Sorry. On Tue, Aug 23, 2005 at 01:04:58PM -0700, Chip Salzenberg wrote: On Tue, Aug 23, 2005 at 09:58:21PM +0200, Leopold Toetsch wrote: Sam, please follow Parrot dev (or stop spreading FUD) - thanks. Be gentle, please. Parrot needs language developers. I'm not saying you're right or wrong. I'm just asking you to be a little more diplomatic. -- Chip Salzenberg [EMAIL PROTECTED] -- Chip Salzenberg [EMAIL PROTECTED]
Re: defaults (was: Python PMC's)
On Tue, Aug 23, 2005 at 03:48:03PM -0400, Sam Ruby wrote: : How will Perl6 evaluate defaults? : : Like Python: : : global x : x=1 : def f(p1=x): : return p1 : x=2 : print f() : : or like Ruby: : : $x=1 : def f(p1=$x) : return p1 : end : $x=2 : puts f() By default, delayed like Ruby, but you can easily force earlier evaluation if that's what you want. In general, pseudo-assignment to declarators is special-cased to happen at the time appropriate to the scope and lifetime of the declarator, and formal parameters are no exception. Basically, the container constructor is passed the closure of what's on the right of the =, and it can choose to evaluate that closure whenever it wants. For instance, state $s = $x; sets $s to the current value of $x only the first time it's executed. So while formal parameter defaults execute as late as possible, and state variable initializations run just in time, object attribute defaults actually run right away, that is, class declaration time (aka BEGIN time), and you have to add braces to delay evaluation till object init time. Arguably that's a little inconsistent, but the inconsistency can be viewed as implicit to the declarator, not the pseudo-assignment syntax, which is just syntactic sugar for a closure. Larry
Re: Python PMC's
Chip Salzenberg wrote: I apologize to Leo for accidentally making this reply to the list. It was supposed to be private mail, but I hit 'y' just a _little_ too soon. I had no intention of embarassing anyone. Sorry. You did, however, cause me to cancel the email I was composing. If people only respond in private to emails such as the one that you responded to, the public perception is that emails such as Leo's are acceptable. In any case, here is a shorter version of what I said in the email I cancelled: From December 16, 2004: http://tinyurl.com/8smmq The commit message for December 17, 2004: r7312 | rubys | 2004-12-17 22:51:48 -0500 (Fri, 17 Dec 2004) | 2 lines Pass 'self' as the first argument on method calls - Sam Ruby
