Re: Mutil Method Questions
Thomas Wittek [EMAIL PROTECTED] writes:
Steffen Schwigon schrieb:
At least the many keywords seem to be necessary to map the complexity
of different paradigms possible in Perl6. Multimethods are not just
overloading as in C++. Second, the different keywords declare
different behaviour you can choose. Just read S06, it's explained
quite understandable.
Hm, but wouldn't whose be equivalent?
sub foo ($bar) {
$bar.say;
}
multi sub foo ($bar) {
$bar.say;
}
Aren't subs a subset of multi subs, meaning that every sub can be
expressed as a multi sub?
Is there anything a sub has in advantage of a multi sub?
So might not just every sub be a multi sub?
If the only difference is, that you _must not_ declare a sub twice with
different argument lists, I think that this one is relatively
unimportant and letting every sub be a multi sub seems to be more
consistent to me in opposite to this arbitrary looking distinction.
Maybe I just phenomenally misunderstood multi subs, but unless I
did, I can't see why we want to have subs when we can have multi
subs that can do the same and even more.
I understand your point and I confess I'm not sure.
At least there seems to be a visibility difference. In S12 I found
those two sentences:
1. [sub (or method) without a multi] [...] Only one such sub (or
method) can inhabit a given namespace, and it hides any outer subs
(or less-derived methods) of the same short name.
2. [subs or methods declared multi] [...] It does not hide any
routines with the same short name but a different long name. In
other words, multis with the same short name can come from several
different namespaces provided their long names differ and their
short names aren't hidden by a non-multi declaration in some
intermediate scope.
GreetinX
Steffen
--
Steffen Schwigon [EMAIL PROTECTED]
Dresden Perl Mongers http://dresden-pm.org/
Re: Using Perl in QA departments
On 6/17/06, Gabor Szabo [EMAIL PROTECTED] wrote: http://www.szabgab.com/perl_in_test_automation.html This is really neat. You might want to add a link to Test::Expect too, which makes it almost to easy to test terminal-based programs. Thanks again! Leon
Re: Mutil Method Questions
Steffen Schwigon:
Thomas Wittek [EMAIL PROTECTED]:
Maybe I just phenomenally misunderstood multi subs, but unless I
did, I can't see why we want to have subs when we can have multi
subs that can do the same and even more.
I understand your point and I confess I'm not sure.
At least there seems to be a visibility difference. In S12 I found
those two sentences:
1. [sub (or method) without a multi] [...] Only one such sub (or
method) can inhabit a given namespace, and it hides any outer subs
(or less-derived methods) of the same short name.
2. [subs or methods declared multi] [...] It does not hide any
routines with the same short name but a different long name. In
other words, multis with the same short name can come from several
different namespaces provided their long names differ and their
short names aren't hidden by a non-multi declaration in some
intermediate scope.
So it looks like we can hide several multis with one sub:
class Foo {
multi method somesub (Int $arg) {
foo - Int: $arg.say
}
multi method somesub ($arg) {
foo - Scalar: $arg.say
}
}
class Bar is Foo {
multi method somesub ($arg) {
bar - Scalar: $arg.say
}
}
class Baz is Foo {
method somesub ($arg) {
baz - Scalar: $arg.say
}
}
my $foo = Foo.new;
my $bar = Bar.new;
my $baz = Baz.new;
$foo.somesub(scalar);
# foo - Scalar: scalar
$foo.somesub(42);
# foo - Int: 42
$bar.somesub(scalar);
# Bar - Scalar: scalar
$bar.somesub(42);
#I'd expect (but it doesn't do that, see text below):
#using more specialized method from Foo
# Foo - Int: 42
$baz.somesub(scalar);
# Baz - Scalar: scalar
$baz.somesub(42);
#_not_ using method from Foo as a non-multi sub overwrites it
# Baz - Scalar: 42
Interestingly $bar.somesub(42) doesn't use the multi method somesub (Int
$arg) of the class Foo (whose signature would provide a better match)
but it also uses multi method somesub ($arg) of the class Bar. So
actually every method that somehow matches in a less derived class
will be used. The more specialized methods of the more derived classes
are hidden, which I didn't expect (but what probably will be better
performance wise).
So I have no Idea why I would like to use a non-multi as even multis
hide the methods of more derived classes.
So even if there are cases where I want the non-multi-behavior (what
ever it really is), I think they are rare.
So I'd suggest that this behavior shouldn't be the default for all subs.
Instead I'd find it more intuitive if every sub is a multi sub by
default and that you could opt in the non-multi-behavior with a keyword
like overriding, dominant or preferred.
I think that the multi-behavior will be more common and thus should be
the default (as it is in most other languages). The probably less common
non-multi-behavior should require an additional keyword. Not vice versa.
Again, that's all written from my fairly small knowledge of the Perl6
language. But supposed that one, who starts learning Perl6, will also
have a small knowledge at the beginning, this concepts might confuse the
beginner, if he/she has to define extra keywords for a behaviour that's
probably more common and omitting the keywords will lead to a less
common behavior.
Maybe we should steal the ruby principle of least surprise here, which
I find a very good principle.
Maybe someone can enlighten me ;)
Best regards,
-Thomas
Re: Mutil Method Questions
Thomas Wittek [EMAIL PROTECTED] writes: So it looks like we can hide several multis with one sub: [ example ] Maybe the type system in Pugs is not yet in such a final state to experiment with it in all that details. I can construct other examples or reverse engineer the neighbor discussion about foo(123) where it also doesn't behave as I would expect. Maybe we should steal the ruby principle of least surprise here, which I find a very good principle. I'm quite confident that Larry already stole all good principles he could find. If there would be a Full Metal Perl movie, the imdb quote collection would contain: These are great days we're living, bros. We are jolly green giants, walking the Earth with Perl6. These principles we stole here today are the finest principles we will ever know. After we rotate back to the world, we're gonna miss not having any principle around that's worth stealing. GreetinX Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Jun 26 13:15:01 2006 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 80 new + 202 open = 282 Created this week: 4 Closed this week: 3 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 39454 [TODO] [easy] $svn keyword expansion$ 39430 Method cache not always invalidated 39426 [BUG] Can't build with cygwin. 2 - 3 weeks old 39329 Check to make sure PMC_str_val, etc. are used appropriately 3 - 4 weeks old 39248 Parrot release 0.4.6 4 - 5 weeks old 39197 lib/Parrot/Test.pm ignores core dumps failures! 39196 [TODO] tests - need to test addmethod 5 - 6 weeks old 6 - 7 weeks old 39132 [TODO] pirtidy - call for help 7 - 8 weeks old 39092 [TODO] Autogenerate functions in *.h files from source 39088 [TODO] Add conditional GCC attributes to functions 39051 Test failure in t/pmc/objects_62.pasm (attributes) 39050 Build failure in compilers/pge/pgc.pir 39043 [TODO] Dynamic PMCs should not include 'parrot/parrot.h' 8 - 9 weeks old 39018 t/pmc/complex failures on Solaris 8/SPARC 39004 [PDD] review pdd25_threads.pod 39003 [PDD] review pdd24_events.pod 39001 [PDD] review pdd22_io.pod 39000 [PDD] review pdd19_pir.pod 38999 [PDD] review pdd18_security.pod 38998 [PDD] review pdd17_basic_types.pod 38997 [PDD] review pdd16_native_call.pod 38996 [PDD] review pdd15_objects.pod 38995 [PDD] review pdd14_bignum.pod 38994 [PDD] review pdd13_bytecode.pod 38993 [PDD] review pdd12_assembly.pod 38992 [PDD] review pdd11_extending.pod 38991 [PDD] review pdd10_embedding.pod 38990 [PDD] review pdd09_gc.pod 38989 [PDD] review pdd08_keys.pod 38988 [PDD] review pdd07_codingstd.pod 38987 [PDD] review pdd06_pasm.pod 38986 [PDD] review PDD05_opfunc.pod 38985 [PDD] review PDD04_datatypes.pod 38984 [PDD] review pdd02_vtables.pod 38983 [PDD] review PDD01_overview.pod 38969 parrot source does not conform to standards 38967 Parrot release 0.5.0 9 - 10 weeks old 10 - 11 weeks old 11 - 12 weeks old 38887 Result of INFINITY or NAN stringification is platform dependent 12 - 13 weeks old 38823 [BUG] solaris 10 w gcc 13 - 14 weeks old 14 - 15 weeks old 38764 Test results of parrot on Freebsd 15 - 16 weeks old 16 - 17 weeks old 17 - 18 weeks old 38594 [BUG] source line numbers 18 - 19 weeks old 19 - 20 weeks old 38469 [BUG] -O1 branch optimization 20 - 21 weeks old 38432 Exception thrown from constructor leads to oddness --- Overview of Open Issues Platform Severity Tag Lang Win32 3abandoned 05005threads 0 BASIC0 sco 0fatal 0notok 0 scheme 0 riscos0High 1ok0 tcl 25 qnx 0low 1Patch10 urm 0 powerux 0medium0regex 0 bc 0 other 0none 0sendToCPAN0 punie1 os390 0Normal1Todo176 Amber0 os2 0unknown 0unknown 0 Zcode0 openbsd 1Wishlist 3utilities 0 Lisp 0 next 0 notabug 0 ruby 0 Solaris 0 library 0 python 0 sunos 0 install 1 befunge 0 svr4 0 bounce0 bf 0 VOS 0 Bug 18 cola 0 vms 0 compiler 0 forth0 uts 0 configure 0 jako 0 unknown 0 core 0 m4 0 unix 0 dailybuild0 ook 0 unicosmk 0 docs 0 plot 0 unicos0 duplicate 0 perl60 sysv 0 wontfix 0 svr5 0 netbsd0 mswin32 0 dynixptx 0 dos 0 dgux 0 dec_osf 0 darwin0 cygwin_nt 0 cygwin0 bsdos 0 All 2 freebsd 0 generic 0 gnu 0 MacOS X 0 macos 0 machten 0 mac 0 lynxos0 Linux 0 irix640 irix 0 HPUX 0 aix 0 --- Ticket Status By Version New or Open
Re: Parrot Bug Summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can we format this a bit better? On Jun 26, 2006, at 9:15 AM, Parrot Bug Summary wrote: Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Jun 26 13:15:01 2006 GMT -- - * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets -- - Numbers Ticket Counts: 80 new + 202 open = 282 Created this week: 4 Closed this week: 3 -- - New Issues New issues that have not been responded to yet 1 - 2 weeks old 39454 [TODO] [easy] $svn keyword expansion$ 39430 Method cache not always invalidated 39426 [BUG] Can't build with cygwin. 2 - 3 weeks old 39329 Check to make sure PMC_str_val, etc. are used appropriately 3 - 4 weeks old 39248 Parrot release 0.4.6 4 - 5 weeks old 39197 lib/Parrot/Test.pm ignores core dumps failures! 39196 [TODO] tests - need to test addmethod 5 - 6 weeks old 6 - 7 weeks old 39132 [TODO] pirtidy - call for help 7 - 8 weeks old 39092 [TODO] Autogenerate functions in *.h files from source 39088 [TODO] Add conditional GCC attributes to functions 39051 Test failure in t/pmc/objects_62.pasm (attributes) 39050 Build failure in compilers/pge/pgc.pir 39043 [TODO] Dynamic PMCs should not include 'parrot/parrot.h' 8 - 9 weeks old 39018 t/pmc/complex failures on Solaris 8/SPARC 39004 [PDD] review pdd25_threads.pod 39003 [PDD] review pdd24_events.pod 39001 [PDD] review pdd22_io.pod 39000 [PDD] review pdd19_pir.pod 38999 [PDD] review pdd18_security.pod 38998 [PDD] review pdd17_basic_types.pod 38997 [PDD] review pdd16_native_call.pod 38996 [PDD] review pdd15_objects.pod 38995 [PDD] review pdd14_bignum.pod 38994 [PDD] review pdd13_bytecode.pod 38993 [PDD] review pdd12_assembly.pod 38992 [PDD] review pdd11_extending.pod 38991 [PDD] review pdd10_embedding.pod 38990 [PDD] review pdd09_gc.pod 38989 [PDD] review pdd08_keys.pod 38988 [PDD] review pdd07_codingstd.pod 38987 [PDD] review pdd06_pasm.pod 38986 [PDD] review PDD05_opfunc.pod 38985 [PDD] review PDD04_datatypes.pod 38984 [PDD] review pdd02_vtables.pod 38983 [PDD] review PDD01_overview.pod 38969 parrot source does not conform to standards 38967 Parrot release 0.5.0 9 - 10 weeks old 10 - 11 weeks old 11 - 12 weeks old 38887 Result of INFINITY or NAN stringification is platform dependent 12 - 13 weeks old 38823 [BUG] solaris 10 w gcc 13 - 14 weeks old 14 - 15 weeks old 38764 Test results of parrot on Freebsd 15 - 16 weeks old 16 - 17 weeks old 17 - 18 weeks old 38594 [BUG] source line numbers 18 - 19 weeks old 19 - 20 weeks old 38469 [BUG] -O1 branch optimization 20 - 21 weeks old 38432 Exception thrown from constructor leads to oddness -- - Overview of Open Issues Platform Severity Tag Lang Win32 3abandoned 05005threads 0 BASIC0 sco 0fatal 0notok 0 scheme 0 riscos0High 1ok0 tcl 25 qnx 0low 1Patch10 urm 0 powerux 0medium0regex 0 bc 0 other 0none 0sendToCPAN0 punie1 os390 0Normal1Todo176 Amber0 os2 0unknown 0unknown 0 Zcode0 openbsd 1Wishlist 3utilities 0 Lisp 0 next 0 notabug 0 ruby 0 Solaris 0 library 0 python 0 sunos 0 install 1 befunge 0 svr4 0 bounce0 bf 0 VOS 0 Bug 18 cola 0 vms 0 compiler 0 forth0 uts 0 configure 0 jako 0 unknown 0 core 0 m4 0 unix 0 dailybuild0 ook 0 unicosmk 0 docs 0 plot 0 unicos0 duplicate 0 perl60 sysv 0 wontfix 0 svr5 0 netbsd0 mswin32 0 dynixptx 0 dos 0 dgux 0 dec_osf 0 darwin0 cygwin_nt 0 cygwin0 bsdos 0 All 2 freebsd 0 generic 0 gnu 0 MacOS X 0 macos 0 machten 0 mac 0 lynxos0 Linux 0 irix640 irix 0 HPUX 0 aix
Parrot Platform API
Hi Chip, I have been looking at the Parrot code for last couple of weeks. While going through the code there were a few things that striked me. There are quite a few places where #ifdef constructs were used to define platform specific code (#ifdef WIN32). I was thinking would it make sense to define a Parrot Platform API that all parrot ports need to implement. This is very similar to the Linux kernel source. During the build time we should be able to resolve the platform specific code and link it in the parrot executable. There are couple of advantages of this. 1. Define a clean API that new parrot ports need to implement. 2. Keeps platforms specific code out of the parrot's core logic. 3. The new ports will not introduce bugs for already working ports. I have had some discusion with Leo about this and he thought it might be a good idea to run it by you. My initial thoughts are we could include following things could be added to the Parrot Platform API: 1. File I/O. This includes sync as well as async I/O. For platforms that do not have native Async I/O support we could build an emulation of Async I/O. 2. Network I/O: This would include API for TCP, UDP and possibly SCTP (Stream control Transmission protocol). 3. Threads and Mutexes 4. Signals / Events () 5. Environment: API to read the environment variables from OS 6. Math library (we could possibly use http://www.netlib.org/fdlibm/ for platforms that support IEEE 754 floating-point arithmetic) The idea is to define a clean seperation between parrot and the platform parrot is running on. The Parrot Platform API would possibly be the interface via which the Parrot VM discovers the platform specific functionality. A good example of a simiar abstraction is the Apache Portable Runtime ( http://apr.apache.org/). This is used in the Apache HTTP Webserver. Let me know what your thoughts are. I would not mind writing up a draft PDD or doing some proof of concept work. -- Thanks, Vishal
Re: Parrot Bug Summary
On 6/26/06, Watson Ladd [EMAIL PROTECTED] wrote: Can we format this a bit better? It is nicely formatted if you see with fixed-width fonts. And the link http://rt.perl.org/rt3/NoAuth/parrot/Overview.html takes to the HTML page from which this ASCII report was extracted.
Re: Parrot Platform API
On Mon, Jun 26, 2006 at 12:08:52PM -0500, Vishal Soni wrote: Hi Chip, Let me know what your thoughts are. I would not mind writing up a draft PDD or doing some proof of concept work. Chip's currently at YAPC::NA, and he's not yet presented his talk, so I'm guessing it might be a little while before he gets a chance to read any of his e-mail. Nicholas Clark
[svn:perl6-synopsis] r9718 - doc/trunk/design/syn
Author: audreyt
Date: Mon Jun 26 14:27:49 2006
New Revision: 9718
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: This is invalid syntax:
for @list sub { ... }
because statement control only admins pointy or bare blocks.
Since pointies and anonymous subs are actually very dissimilar
(for return handling etc), we don't show the translation anymore
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podMon Jun 26 14:27:49 2006
@@ -140,11 +140,13 @@
given traits. Syntactically a pointy sub is parsed exactly like a
bare block.
-$sq = - $val { $val**2 }; # Same as: $sq = sub ($val) { $val**2 };
+my $sq = - $val { $val**2 };
+say $sq(10); # 100
-for @list - $elem {# Same as: for @list sub ($elem) {
-print $elem\n;# print $elem\n;
-} # }
+my @list = 1..3;
+for @list - $elem {
+say $elem; # prints 1\n2\n3\n
+}
It also behaves like a block with respect to control exceptions. If you
Creturn from within a pointy sub, it will return from the innermost
