aggregate clone vtable
- Array, PerlArray, Hash, PerlHash clone is a deep copy
- {Fixed,Resizable}PMCArray is a shallow copy
The deep copy of Array and Hash breaks (infinite recursion) with
self-referential structures.
I think the deep copy should be a shallow copy.
Deep copy can always be done in a safe way by freeze/thaw.
leo
Re: [perl #34391] [TODO] thr-primes.imc should not use PerlUndef
Bernhard Schmalhofer [EMAIL PROTECTED] wrote: Hi, the example 'thr-primes.imc' should not use the PerlUndef PMC, as the Perl* PMCs are being moved into 'dynclasses'. Replacing the PerlUndef PMC with the standard Undef PMC mostly works. However, after 499 is found as a prime, an infinite loop seems to be entered. The PerlUndef has the Integer PMC in its parents and inherits an empty Cshare vtable slot. Undef used the Parrot_default_share implementation which throws an internal_exception. The strange part is, why this exception isn't visible and why the program runs to the end and hangs there. Anyway I've put in an empty share into the Undef PMC and now it works. CU, Bernhard Thanks for looking at it, leo
[perl #34394] [TODO] implement the splice vtable in *PMCArrays
# New Ticket Created by Leopold Toetsch # Please include the string: [perl #34394] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34394 The splice opcode has the functionality of the perl5 function, so that should be rather straight to implement. See also classes/array.pmc:splice. FixedPMCArray can have a splice too, if the array limit isn't hit. Other type*Arrays should first be adapted to the allocation scheme and layout of the *PMCArray types. Oh well, while at it, the *BooleanArray should just use one bit per item not an INTVAL. leo
RFC: general feedback on module port
If any of you are willing, I would appreciate any general feedback on my first complete module port to Perl 6, including test suite, particularly if any parts don't look like proper Perl 6. I haven't tried executing it yet, since Pugs lacks some features. But it will be easier on them if what they try to execute is correct in the first place. I am referring to any file in the Pugs version control under this directory: /modules/Locale-KeyedText You can browse the whole Pugs source tree on the web here: http://rt.openfoundry.org/Foundry/Project/Source/index.html/pugs/browse/ Alternately, the core module itself is visible here: http://rt.openfoundry.org/Foundry/Project/Source/index.html/pugs/checkout/modules/Locale-KeyedText/lib/Locale/KeyedText.pm I have already applied or considered everything said on this list in answer to my questions. On a side note, I also decided to apply one of Larry's style preferences to all of my Perl 5 modules (and the above Perl 6 module), which is to not use parenthesis with 'return'. I will start porting another module that is about 25 times larger in a week or two; any feedback I get meanwhile may also aid that task being done correctly. Thanks to the rest of you who are working on driving Perl 6 in some fashion; we're much better off for your contributions. Have a good day. -- Darren Duncan
Re: MMD as an object.
[EMAIL PROTECTED] wrote:
It would behave like a tied sub (or method), with a .dispatch method
to decide which of the contained routines should be called this
particular time. Manhattan would be the default. However, one can
override the dispatch logic; implementing Luke's Patterns idea, for
example.
Hmm, that ties into my wishlist item. Would it be possible to implement
method combinators (or rather, multimethod combinators) from Common LISP
in addition to this? The only CLOS feature that A12 doesn't mention,
can't let that happen. ;)
class A { ... }
class B is A { ... }
1 multi foo ($a) is before { ... }
2 multi foo (B $a) { ... next METHOD; ...}
3 multi foo (A $a) { ... }
4 multi foo ($a) is after { ... }
5 multi foo ($a) is around { ... next METHOD; }
6 multi foo ($a) is before { ... }
and this runs all 5 methods, in order 5 1 2 6 3 (returns
to 2) 4 (returns to 5)
And yes, 6 and 1 do have the same signature. The rule is to run all
before methods in order of the currently selected distance (ties broken
in random order ;) ), and all after methods in the reverse order.
Oh, and the reason why around methods are useful?
multi foo ($a) is around {
CATCH { ... }
next METHOD;
}
Note that this catches the exceptions thrown by any version of foo, even
though at this point you don't know whether foo will be specialised.
before methods aren't useful for this since their stack frame and
handler blocks don't linger during the executions of other methods.
Common LISP references:
Standard method combination (before, after, around)
http://www.lispworks.com/documentation/HyperSpec/Body/07_ffb.htm
Other method combinations (+, and, etc)
http://www.lispworks.com/documentation/HyperSpec/Body/07_ffd.htm
Creating your own method combinations (define-method-combination)
http://www.lispworks.com/documentation/HyperSpec/Body/m_defi_4.htm
Come to think of this, it seems that the only thing that'd need to be
modified to accomodate both Rod's and mine proposal is to move CALLONE
and CALLALL from the class to be MMD object somehow. Perhaps
multi CALLONE ($obj, $method where { $_ == func }, [EMAIL PROTECTED]) { ... }
Hmm, but this syntax strikes me as icky.
Miro
Re: [perl #33103] Subclass op subclass naming
Simon Glover [EMAIL PROTECTED] wrote: ... However, if we want to create an anonymous subclass, using the 2-argument form of the subclass op, then we hit a problem -- the code: newclass P0, City subclass P1, P0 newclass P2, State subclass P3, P2 end also fails, with the error: Class already registered! Fixed. Internal anonymous names are now different. ... , or change how subclass generates classnames for anonymous subclasses? [*]. [*] Yes, I know this sounds odd, but we need to be able to distinguish between an anonymous subclass of Foo and an anonymous subclass of Bar, which implies it must have some kind of name beyond ''. These are now Foo\0\0anon_1 and Bar\0\0anon_2. leo
Re: Argument Patterns
Luke Palmer [EMAIL PROTECTED] wrote:
Leopold Toetsch writes:
All infix operators are multi subs. I can't imagine that we want to pay
the penalty for simple operations like:
$a = $b + $c
to inspect the values of operands, constraints, rules and what not.
Having written several multi dispatch systems, I know that this is easy
to optimize. If nobody has defined + on any fancy subtypes, then we can
quickly fall back to a bitset-intersection dispatch algorithm on the
types (or even, eew, direct lookup).
The Plan for implementing MMD is currently (given above add statement):
1) the assembler converts the '+' into something like:
infix __add, Pa, Pb, Pc # which is basically the same as
Pa = Pb.__add(Pb, Pc)
2) during predereferncing (once per call site := PBC location):
.) do a fully dynamic MMD lookup
.) depending on the found function:
if its a NCI (C-function, builtin)
.) convert the opcode to the PIC version:
cache = cur_opcode[1]
b = cur_opcode[3]
c = cur_opcode[4]
if (cache.types == (b.type | c.type 16))
cur_opcode[2] = (cache.c.function)(b,c)
else
# ... test more chache entries
if its an assembly function (user code, overloaded)
.) convert opcode to a function call
...
if (cache.types == (b.type | c.type 16))
VTABLE_invoke(cache.pasm.function)
...
.) add an internal opcode that processes return results and
restores registers
3) this assumes that the Perl6 compiler or Parrot can detect, when the
infix:+ operation is overloaded or that another multi variant of that
operations is added. In that case the cache for the involved classes has
to be invalidated.
This works of course only, if the dispatch is on types only.
... If + has been defined on fancy
subtypes, then we compile the quickest way to figure out whether none of
the arguments are one of them, and fall back. This is a little tricky,
but some elementary graph theory gets us there.
This means that the Perl6 compiler emits code to check the constraints
on all possible MMD candidates?
But we always have enough knowledge to optimize the hell out of this,
and they're not not handwavy we can probably optimizations. They're
real, and they're pretty darn easy.
What happens if C eval 'infix:+(A $a, B $b) {...}' is done?
Luke
leo
Re: MMD as an object.
Rod Adams [EMAIL PROTECTED] wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all the
various routines that share that short name.
Discussion seems to have went off into esoteric cases of locally
overriden dispatcher policies and what not.
What I'd like to know is more basic things:
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
If yes, who is creating it: the Perl6 compiler emits code to do so or
it's up to Parrot to do the right thing?
2) namespaces of (multi) subs.
A non-multi method is in the classes' namespace. In Parrot terms that's
currently:
%globals{\0class_name}{method_name}
I'm not quite sure, if the method hash shouldn't live inside the class.
A multi method is similar, except that their can be more then one
with the same short name (which probably means that there has to be a
MultiSub object holding the long names)
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Re: Test::Builder-create
On Tue, Mar 08, 2005 at 10:11:09PM -0500, Michael Graham wrote: Would this make it possible to run many test scripts (each with its own plan) within the same perl process? 'Cos that would be nifty. Yes. Though beyond testing testing libraries I don't know why you'd want to do that. Well, all I was going to do was try to shave a few seconds off the running time of my test suite (which is now climbing up to the 10 minute mark). I figured I could do the mod_perl thing: preload all my modules and do most of my setup at startup and then require each of the test scripts. Dunno if it will be worth the effort but it was something I was going to play with for a couple of hours. If script startup and module loading really is the culprit you could try the mod_perl approach. Load all required modules and then for each script, fork a new perl process which uses do testxxx.t to run each script. Not sure how windows friendly this is though but that might not matter to you, F
Re: Regarding status of Parrot and pure perl Perl6 compiler
Millsa Erlas wrote: What is the current status of the development of the Parrot and the Perl 6 compiler written in Perl? I hope that producing a Perl 6 compiler written in Perl 6 and the Parrot VM is still a high priority and is being actively developed as the premier compiler and VM for the Perl 6 language. A Perl 6 compiler written in Perl 6 I believe is an extremely useful and essential component since it will allow Perl programmers to participate and assist in the development of the Perl 6 compiler. Also where is the CVS/SVn repisitory for Perl6 compiler kept these days? I've been following the development of pugs (http://pugscode.org/), so I can give a short answer based on that. While pugs is currently written in Haskell, roadmap does mention the idea to eventually port pugs to perl6 if needed, which would give us a Perl 6 compiler written in Perl. (see http://svn.perl.org/perl6/pugs/trunk/docs/01Overview.html) The if needed means, I'd guess, that if no other implementation of perl6 compiler written in perl exists at that time, we can get one from the pugs project. About the status of pugs-project: Pugs is currently approaching first milestone 6.2. Because this project is still so new, it's quite impossible to give any estimates about any further milestones. (And porting pugs to Perl6 is the final milestone v6.283185) I think that after few months of development, we should have a lot better picture of how quickly pugs-project can continue to implement the various features perl6-language requires. And of course we will eventually need working Parrot to compile perl6 into a Parrot-code, but I don't know much about that as I'm currently mainly interested about the development of pugs-project. -- Markus Laire Jam. 1:5-6
Re: MMD as an object.
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
There lingers the case of:
use Foo; # from above, exports bar is MMD::Random
multi sub bar {...}
Does this generate an error, since one could expect this particular bar
to be Manhattan? Or does it assume Random, since there's already a bar
in existence? In my head, it currently makes sense to say that the new
bar inherits the Random policy. Only something like:
This seems like action-at-a-distance to me; I use some random module,
define a couple of multis without realizing that they also exist in
the module, and am baffled as to why I don't get the dispatch behavior
I expect.
--Dks
Re: some misc Perl 6 questions
Larry Wall wrote: That's...sick... I love it. *Please* don't tell Damian. whisper Well there are some people who consider it quite sane :) http://www.cduce.org/papers/icalp04.pdf Abstract: This paper studies the problem of matching sequences against regular expressions in order to produce structured values. To me handling XML data is an area where Perl 6 could|should|will excel! I think Perl 5 already does. /whisper MfG -- TSa (Thomas Sandlaß)
Junctions - feedback and desires
I gave a talk on Perl 6 Junctions at the Thousand Oaks Perl Mongers
meeting last night
http://www.hcoop.net/~terry/perl/talks/p6-junctions/index.html
and two questions/desires came out of it:
1: will it be possible to know which element of a junction is
currently being used? E.g.:
my @first_set = qw(1 1);
my @new_set = qw(1 1.4 1 1 8 1 1 1 0.8);
my $any_new_set = any(@new_set);
my $any_first_set = any(@first_set);
if ( (abs($any_first_set - $any_new_set)) 0.5) {
a variation in the readings is too large.say;
printf we we examining %d and %d when it happened,
$any_new_set.current, $any_first_set.current ; # desired feature
}
2: Unless the array of values can be specified lazily, it will not be
practical to use Perl 6 Junctions on large datasets. For example I
might like to be able to specify a sub ref/closure whose execution yields a
new array value or undef when no more values. I.e.:
sub mynext {
my($age) = $sth-fetchrow_array;
$age
}
my $junction = any(\mynext) ;
3: Do junctions short circuit? I.e., whenever the condition is met,
does it continue immediately. Using the example from point #1, can we assume
that the body of the then branch will fire when 8 of @new_set is
encountered?
Re: MMD as an object.
[EMAIL PROTECTED] wrote:
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Uh, the real problem is the interaction between multisubs and modules.
If you import a multi with the same short name from another module, you
get a real issue that needs resolving. Especially if they do
fundamentally different things and you don't expect a clash. Like
module Users;
multi get(Stream $f, UserDescriptor $u) {...}
...
module FileTransfer;
multi get(Server $s, File $f) {...}
Even if this is easy to fix by renaming, the error message would take a
while to track down and it'd be annoying distraction during development.
I believe the DWIM thing to do would be to merge multis into the same
MMD object on module load. This would have to happen during runtime,
since that's when the module load can occur.
Miro
Re: Adding linear interpolation to an array
HaloO Luke, you wrote: The words 'covariant' and 'contravariant' in this context seem like voodoo math. Please explain what you mean. 'Co' means together like in coproduction. And 'contra' is the opposite as in counterproductive. With instanciating parametric types the question arises how a subtype relation between instanciating types propagates to the template. E.g with Int : Num, covariance would result in Array[Int] : Array[Num]. Referential classes are actually quite difficult because upon write they are contravariant and covariant when read! So a third case of uncomparable types is needed as well, or it is the default if nothing else is specified. That's not true. I don't believe it would be an error to specify all nine combinations. Ohh, sorry. Of course implementing all is fine as well. But a bit tedious for larger collections of classes. MfG -- TSa (Thomas Sandla)
Parrot 0.1.2 with MinGW32 (some experimets)
Failed TestStatus Wstat Total Fail Failed List of Failed
imcc/t/imcpasm/opt1.t 1 256491 2.04% 48
t/dynclass/pybuiltin.t 5 1280 65 83.33% 1-2, 4-6
t/dynclass/pyclass.t 6 1536 66 100.00% 1-6
t/dynclass/pycomplex.t 1 256 11 100.00% 1
t/dynclass/pyfunc.t4 1024 44 100.00% 1-4
t/dynclass/pyint.t25 640025 25 100.00% 1-25
t/native_pbc/integer.t 1 256 11 100.00% 1
t/native_pbc/number.t 1 256 11 100.00% 1
t/op/spawnw.t 2 512 32 66.67% 2-3
t/pmc/object-meths.t 271 3.70% 19
t/pmc/objects.t 602 3.33% 53, 57
t/pmc/sys.t1 256 11 100.00% 1
5 tests and 66 subtests skipped.
Failed 12/136 test scripts, 91.18% okay. 50/2210 subtests failed, 97.74%
okay
# --- imcc/t/imcpasm/opt1.t ---
imcc/t/imcpasm/opt1.# Failed test (imcc/t/imcpasm/opt1.t at line 626)
# got: '_main:
# set N0, 1.6e+022
# end
# '
# expected: '_main:
# set N0, 1.6e+22
# end
# '
# Looks like you failed 1 tests of 49.
--- imcc/t/syn/file.t, line 363
{ local $/; $err_msg = FOO; }
+$err_msg =~ s/\r//g;
$ perl -Ilib imcc/t/syn/file.t
...
ok 11 - including a non-existent file
...
# --- t/dynclass/ ---
t/dynclass/pybuiltin.# Failed test (t/dynclass/pybuiltin.t at line 22)
# got: ''
# expected: '31
# '
$ parrot.exe -t t/dynclass/pybuiltin_1.imc
10 lines compiled.
Running...
0 new_pad 0
2 new P30, PyInt - P30=PMCNULL,
$ echo Any ideas?
# --- t/native_pbc/integer.t ---
# --- t/native_pbc/number.t ---
t/native_pbc/integer.# Failed test (t/native_pbc/integer.t at line 51)
# got: 'Parrot VM: Can't locate
c:/usr/parrot-t/t/native_pbc/integer_1.pbc, code 2.
# main: Packfile loading failed
$ pwd
/c/usr/parrot-src
$ parrot.exe t/native_pbc/integer_1.pbc
270544960
$ parrot.exe /c/usr/parrot-src/t/native_pbc/integer_1.pbc
Parrot VM: Can't locate c:/usr/parrot-src/t/native_pbc/integer_1.pbc,
code 2.
main: Packfile loading failed
$ ls c:/usr/parrot-src/t/native_pbc/integer_1.*
c:/usr/parrot-src/t/native_pbc/integer_1.pbc
# same for:
parrot.exe c:/usr/parrot-src/t/native_pbc/integer_1.pbc
ls /c/usr/parrot-src/t/native_pbc/integer_1.*
echo Seems like mingw/msys isssue.
# --- t/op/spawnw.t ---
t/op/spawnw.# Failed test (t/op/spawnw.t at line 57)
# got: 'return code: 0
# '
# expected: 'return code: 123
# '
# Failed test (t/op/spawnw.t at line 71)
# got: 'return code: 0
# '
# expected: 'return code: 3
# '
# Looks like you failed 2 tests of 3.
# --- t/pmc/object-meths.t ---
t/pmc/object-meths..FAILED test 19
not ok 19 - constructor - diamond parents # TODO wrong init order?
# Failed (TODO) test (t/pmc/object-meths.t at line 519)
...
# get E init expected E
# get D init expected A
# get B init expected D
# get A init expected B
# get C init expected C
# get F init expected F
$ echo Move A after E. :-)
# --- t/pmc/objects.t ---
t/pmc/objects...FAILED tests 53, 57
not ok 53 - PMC as classes - derived 3 # TODO methods can't be
overridden in derived class only
# Failed (TODO) test (t/pmc/objects.t at line 1660)
not ok 57 - __init argcP # TODO new Px, Ix: argcP is wrong in __init method
# Failed (TODO) test (t/pmc/objects.t at line 1800)
# --- t/pmc/sys ---
t/pmc/sys...# Failed test (t/pmc/sys.t at line 26)
# got: '. Not found ...
--- config_lib.pasm
- set P0[slash], /
+ set P0[slash], \\
$ parrot config_lib.pasm
$ parrot.exe t/pmc/sys_1.imc
Hello, World!
0
So seems like Parrot_run_slash != MinGW_build_slash. Because I still
need Configure::Data-set( slash = '/' ); inside
config\init\mswin32.pl to properly build.
# --- Some other ideas: ---
$ perl -e print $^O
msys
--- config\init\hints.pl
sub runstep {
+ my $O = lc($^O);
+ $O = 'mswin32' if $O =~ /^(msys|mingw)/;
- my $hints = config/init/hints/ . lc($^O) . .pl;
+ my $hints = config/init/hints/ . $O . .pl;
S pozdravem Michal Jurosz
http://xrl.us/fddn
Re: Adding linear interpolation to an array
On Thu, 10 Mar 2005, [UTF-8] Thomas Sandla~_ wrote: 'Co' means together like in coproduction. And 'contra' is the opposite 'Streaming of digestive byproducts'? ;-) Sorry for the OT - couldn't resist! This pun first occurred to me wrt (cathegorical) coproducts... Michele -- SILVIO CLEPTOMANE - Scritta su un muro, Via F. Sforza, Milano
Re: Adding linear interpolation to an array
At 17:53 +0100 3/10/05, Thomas Sandlaß wrote: 'Co' means together like in coproduction. And 'contra' is the opposite as in counterproductive. With instanciating parametric types the question arises how a subtype relation between instanciating types propagates to the template. E.g with Int : Num, covariance would result in Array[Int] : Array[Num]. Referential classes are actually quite difficult because upon write they are contravariant and covariant when read! So a third case of uncomparable types is needed as well, or it is the default if nothing else is specified. A word of caution: Just as in vector operators had their names changed to pacify the mathematicians - thank you - there is a conflict in terms. Covariant and contravariant tensors are the meat of Einstein's formulation of relativity. It all has to do with transformations being in the same direction or the opposite direction as the coordinate differentials. Perhaps there is some similarity. Einstein's presentation is a whole lot easier to understand than the one above. -- -- Marriage and kilo are troubled words. Turmoil results when centuries-old usage is altered in specialized jargon --.
Re: Adding linear interpolation to an array
At 17:53 +0100 3/10/05, Thomas Sandlaß wrote: [request for clarification of 'covariant' and 'contravariant' usage] 'Co' means together like in coproduction. And 'contra' is the opposite as in counterproductive. With instanciating parametric types the question arises how a subtype relation between instanciating types propagates to the template. E.g with Int : Num, covariance would result in Array[Int] : Array[Num]. Referential classes are actually quite difficult because upon write they are contravariant and covariant when read! So a third case of uncomparable types is needed as well, or it is the default if nothing else is specified. Thomas, I appreciate you attempting to explain this, but it remains clear as mud, at least to me. Could you please try again, using very short, very non-technical words and not assuming a mathematical or scientific background on the part of your reader? Something that would help: We could all look the words up in a dictionary, so we don't need a definition. What we need is a clarification, in simple terms, of what *you* mean by them, in this context. Thank you. --Dks
Re: Parrot 0.1.2 with MinGW32 (imcc/t/syn/file.t)
I am sorry for mystification. Without my cheat 'imcc/t/syn/file.t' fail too.
# --- imcc/t/syn/file.t ---
imcc/t/syn/file.# Failed test (imcc/t/syn/file.t at line 388)
# got: 'error:imcc:No such file or directory
# in file 'temp.imc' line 2
# '
# expected: 'error:imcc:No such file or directory
# in file 'temp.imc' line 2
# '
# Looks like you failed 1 tests of 12.
Seems like carriage return (\r\n vs. \n) problem.
--- imcc/t/syn/file.t, line 363
{ local $/; $err_msg = FOO; }
+$err_msg =~ s/\r//g;
$ perl -Ilib imcc/t/syn/file.t
...
ok 11 - including a non-existent file
...
Michal Jurosz
ICQ#:93348414
Re: Parrot 0.1.2 with MinGW32 (some experimets)
On Thu, 10 Mar 2005 18:33:00 +0100, Michal Jurosz [EMAIL PROTECTED] wrote: Failed TestStatus Wstat Total Fail Failed List of Failed imcc/t/imcpasm/opt1.t 1 256491 2.04% 48 t/dynclass/pybuiltin.t 5 1280 65 83.33% 1-2, 4-6 t/dynclass/pyclass.t 6 1536 66 100.00% 1-6 t/dynclass/pycomplex.t 1 256 11 100.00% 1 t/dynclass/pyfunc.t4 1024 44 100.00% 1-4 t/dynclass/pyint.t25 640025 25 100.00% 1-25 t/native_pbc/integer.t 1 256 11 100.00% 1 t/native_pbc/number.t 1 256 11 100.00% 1 t/op/spawnw.t 2 512 32 66.67% 2-3 t/pmc/object-meths.t 271 3.70% 19 t/pmc/objects.t 602 3.33% 53, 57 t/pmc/sys.t1 256 11 100.00% 1 5 tests and 66 subtests skipped. Failed 12/136 test scripts, 91.18% okay. 50/2210 subtests failed, 97.74% okay Some of these same tests are failing on debian, fedora, and freebsd (fresh checkouts). It looks like someone broke something. Failed TestStat Wstat Total Fail Failed List of Failed --- t/dynclass/gdbmhash.t13 332813 13 100.00% 1-13 t/dynclass/pybuiltin.t5 1280 65 83.33% 1-2 4-6 t/dynclass/pyclass.t 6 1536 66 100.00% 1-6 t/dynclass/pycomplex.t1 256 11 100.00% 1 t/dynclass/pyfunc.t 4 1024 44 100.00% 1-4 t/dynclass/pyint.t 25 640025 25 100.00% 1-25 2 tests and 63 subtests skipped. Failed 6/136 test scripts, 95.59% okay. 54/2235 subtests failed, 97.58% okay. -- matt diephouse http://matt.diephouse.com
Re: Junctions - feedback and desires
Terrence Brannon wrote:
I gave a talk on Perl 6 Junctions at the Thousand Oaks Perl Mongers
meeting last night
http://www.hcoop.net/~terry/perl/talks/p6-junctions/index.html
and two questions/desires came out of it:
1: will it be possible to know which element of a junction is
currently being used? E.g.:
my @first_set = qw(1 1);
my @new_set = qw(1 1.4 1 1 8 1 1 1 0.8);
my $any_new_set = any(@new_set);
my $any_first_set = any(@first_set);
if ( (abs($any_first_set - $any_new_set)) 0.5) {
a variation in the readings is too large.say;
printf we we examining %d and %d when it happened,
$any_new_set.current, $any_first_set.current ; # desired feature
}
I do not believe that is possible.
This is the filtering or unification behavior that people keep
wanting junctions to have, which they do not.
A given junction always has all of the values it was made with. No more,
no less. If you want something else, you have to make a new junction.
Consider that it's been decided that :
$j = 11|0;
10 $j 1
Is true. $j retains the 0 even after the 0 failed a test.
As for the current value, there is only a current value during
threading. In this example, the threading is fully contained in C
(abs($any_first_set - $any_new_set)) 0.5 . By the time the printf
comes, the threading is long past.
If you wish to change the behavior, you're welcome to put out some
proposals. But I'll warn you from experience that Damian is rather
stubborn about the current behavior. =)
2: Unless the array of values can be specified lazily, it will not be
practical to use Perl 6 Junctions on large datasets. For example I
might like to be able to specify a sub ref/closure whose execution yields a
new array value or undef when no more values. I.e.:
sub mynext {
my($age) = $sth-fetchrow_array;
$age
}
my $junction = any(\mynext) ;
You now have a junction whose only value is a coderef.
I do not believe that you can create a 'lazy junction'. But I don't
recall the topic coming up before, so we'll have to wait for Damian to
come back unless someone else knows for certain.
3: Do junctions short circuit? I.e., whenever the condition is met,
does it continue immediately. Using the example from point #1, can we assume
that the body of the then branch will fire when 8 of @new_set is
encountered?
Yes, they short circuit.
However, your second statement might be a bit misleading. When the 8 is
encountered, the evaluation of the junctions terminates, and then
processing moves on to the next statement, in this case the say. What
you said might be construed as the junctions were still being threaded
when the the say and printf occurred.
HTH,
-- Rod Adams
Re: MMD as an object.
David Storrs wrote:
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
There lingers the case of:
use Foo; # from above, exports bar is MMD::Random
multi sub bar {...}
Does this generate an error, since one could expect this particular bar
to be Manhattan? Or does it assume Random, since there's already a bar
in existence? In my head, it currently makes sense to say that the new
bar inherits the Random policy. Only something like:
This seems like action-at-a-distance to me; I use some random module,
define a couple of multis without realizing that they also exist in
the module, and am baffled as to why I don't get the dispatch behavior
I expect.
Well, if you were not expecting Foo to export some bar's, then you're
in for a surprise regardless of dispatch when you call bar in your code
and one of Foo::bar gets called instead of one of yours, because it was
a closer match.
I would say that people should know what they are getting into when they
C use something. In Perl 6, that use could conviently swap the
meanings of all the + and - signs, and not say a word. In my head, this
extends to knowing what it exports, and if there's anything weird about it.
If I am consciously adding more multi's into something a package
provided, to extend it's functionality, I would think that keeping the
original dispatch system would make sense. Otherwise the imported
methods could fail to work properly.
-- Rod Adams
Re: Test::Builder-create
If script startup and module loading really is the culprit you could try the
mod_perl approach.
Load all required modules and then for each script, fork a new perl process
which uses do testxxx.t to run each script.
That's a good idea - thanks!
I gave it a try and these are the times I got:
Time Method
--
6:09 prove -r tests/
4:14 for i in tests/**/*.t ; do perl $i; done
2:57 runscripts-forking.pl tests/**/*.t
This is for a suite of 165 test scripts.
So it does look like there are efficiencies to be had, it's just a
question of whether it's worth the bother (e.g. to figure out how to
parse the output of the forked scripts).
runscripts-forking.pl basically looks like this:
#!/usr/bin/perl
use strict;
# ... use a ton of modules here ...
foreach my $script (@ARGV) {
warn Script: $script\n;
unless (runscript($script)) {
warn FAILED: Script $script: $! [EMAIL PROTECTED];
last;
}
}
sub runscript {
my $script = shift;
my $pid;
if (!defined($pid = fork)) {
warn Cannot fork: $!\n;
return;
}
elsif ($pid) {
my $ret = waitpid($pid, 0);
return $ret;
}
do $script or die Compile errors: $script: [EMAIL PROTECTED];
exit;
}
Michael
--
Michael Graham [EMAIL PROTECTED]
sub and method name overlap.
Given:
class Foo {
method Bar () {...};
}
sub Bar (Any $x) {...};
my Foo $f;
Bar $f;
Is that last line the same as:
Bar.($f);
or
$f.Bar;
Does it matter if we change C sub Bar to C multi sub Bar ?
Is there some form of implicit multi sub that gets created to make C
Bar $f; C $f.Bar ? Or does it only work if there is no C multi? sub
bar in sight?
-- Rod Adams
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Some of these same tests are failing on debian, fedora, and freebsd (fresh checkouts). It looks like someone broke something. Seems to have went all wrong between 20:35 and 21:35 on 9th(gmt). With only the loosest understanding of stuff I think ( a little knowledge can be a dangerous thing) it may be related to pmc.c revision 1.95 date: 2005/03/09 14:52:01; author: leo; state: Exp; lines: +2 -2 Objects 1 - class, mro vtable slots * renamed vtable-data to class as this is it's usage anyway * new vtable-mro slot - empty for now
Re: MMD as an object.
Leopold Toetsch wrote:
Rod Adams [EMAIL PROTECTED] wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all the
various routines that share that short name.
Discussion seems to have went off into esoteric cases of locally
overriden dispatcher policies and what not.
I don't think it's as esoteric as you might think. Consider:
package Foo;
use MMD::Random;
our bar is MMD::Random is export(DEFAULT);
multi sub bar ($x) {...};
multi sub bar ($x) {...};
multi sub bar ($x) {...};
==
use Foo;
multi sub bar ($x) {...};
Note that they all have the same signature. The Manhattan policy would
complain about this, since it's looking for the closest parameter match.
The Random policy does not care. It's going to randomly pick any member
method for each call.
So what we then fall into is the problem of which policy is in effect
for a given multi can affect what's in scope at a given point. If the
later file included:
sub baz {
my multi sub bar ($x) {...};
bar(5);
}
A Manhattan policy would have the local bar mask the package bar with
the same signature. A Random policy would temporarily add it into the mix.
Since the main goal of treating multis as an object was to be able to
override the dispatch policy, I think how a user defined policy
interacts with different localities is very much on topic.
What I'd like to know is more basic things:
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
As for whether such a thing is visible at the Perl level, I think that
depends on if we allow user defined dispatch policies or not. If not,
it's just an introspection tool that could be addressed in other ways.
Even without custom policies, p6c may decide to go the MultiSub object
route at the compiler level. But I can't speak to that, nor on the
Compiler - Parrot interaction.
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
This can be seen as questioning how to keep track of what multi's are in
scope at any given point in time, because you must dispatch amongst all
the multi's visible, regardless of the differing scope. Method dispatch
has a similar issue with hunting down all the C isa s for possible
method's to include in dispatch. So far, I think this issue has been
politely ignored as p6c's problem, not p6l's.
However if you have multi's from a mix of different sources and scopes,
all with the same short name, which policy decides how to dispatch
amongst them at a given calling locality is very much at issue, and is
roughly where we are in the discussion.
Thanks for clarifying,
Sorry I couldn't clarify more.
-- Rod Adams
Re: Parrot 0.1.2 with MinGW32 (some experimets)
On Thu, 2005-03-10 at 16:36 -0500, [EMAIL PROTECTED] wrote:
Seems to have went all wrong between 20:35 and 21:35 on 9th(gmt).
With only the loosest understanding of stuff I think ( a little
knowledge can be a dangerous thing) it may be related to
pmc.c
revision 1.95
date: 2005/03/09 14:52:01; author: leo; state: Exp; lines: +2 -2
Objects 1 - class, mro vtable slots
* renamed vtable-data to class as this is it's usage anyway
* new vtable-mro slot - empty for now
That's my guess too. It segfaults for me during make:
If the next line prints 0.1.2-devel, it did help.
./parrot parrot-config.imc VERSION DEVEL
make: *** [runtime/parrot/include/config.fpmc] Segmentation fault
make: *** Deleting file `runtime/parrot/include/config.fpmc'
The parrot trace is:
$ parrot -t parrot-config.imc VERSION DEVEL
0 set P15, P5 - P15=PMCNULL, P5=SArray=PMC(0x1054bf78)
3 set I14, P15 - I14=0, P15=SArray=PMC(0x1054bf78)
6 lt I14, 2, 97- I14=3, ,
10 set P14, PMC_C[12] - P14=PMCNULL,
13 set I0, 1- I0=0,
16 set I1, 0- I1=0,
19 set I2, 0- I2=0,
22 set I3, 0- I3=1,
25 set I4, 0- I4=0,
28 set P0, P14 - P0=PMCNULL, P14=Sub=PMC(0x1054bf90
Adr:0x105ed9cc)
31 invokecc
# Calling sub '_config'
# in file 'parrot-config.imc' near line 32
113 open P15, runtime/parrot/inclu, - P15=PMCNULL, ,
117 defined I30, P15 - I30=0, P15=ParrotIO=PMC(0x1054bf30)
120 if I30, 17 - I30=1,
137 read S30, P15, 6 - , P15=ParrotIO=PMC(0x1054bf30),
141 close P15- P15=ParrotIO=PMC(0x1054bf30)
143 thaw P30, S30- P30=PMCNULL, S30=(null)
The backtrace is:
#0 0x100aff70 in pobject_lives (interpreter=0x1038e678, obj=0x35)
at src/dod.c:196
#1 0x1026920c in Parrot_SArray_mark (interpreter=0x1038e678,
pmc=0x1054d748)
at classes/sarray.c:276
#2 0x100b05c4 in Parrot_dod_trace_children (interpreter=0x1038e678,
how_many=4294967295) at src/dod.c:460
#3 0x100b037c in trace_active_PMCs (interpreter=0x1038e678,
trace_stack=1)
at src/dod.c:378
#4 0x100b1188 in Parrot_dod_ms_run (interpreter=0x1038e678, flags=1)
at src/dod.c:1200
#5 0x100b12a8 in Parrot_do_dod_run (interpreter=0x1038e678, flags=1)
at src/dod.c:1239
#6 0x10142c0c in mem_allocate (interpreter=0x1038e678,
req_size=0x7174,
pool=0x103aec80, align_1=15) at src/resources.c:142
#7 0x10143ab0 in Parrot_allocate_string (interpreter=0x1038e678,
str=0x105e4e98, size=1061) at src/resources.c:613
#8 0x10062e04 in string_make_direct (interpreter=0x1038e678,
buffer=0x105d2198, len=1061, encoding=0x103aee88,
charset=0x103aef28,
flags=131072) at src/string.c:668
...
I set a breakpoint near #1:
Breakpoint 1, Parrot_SArray_mark (interpreter=0x1038e678,
pmc=0x1054d748)
at classes/sarray.c:275
275 if (UVal_pmc(e-val))
(gdb) p e
$1 = (HashEntry *) 0x10555298
(gdb) p e-val
$2 = {_b = {_bufstart = 0x0, _buflen = 53}, _ptrs = {_struct_val = 0x0,
_pmc_val = 0x35}, _i = {_int_val = 0, _int_val2 = 53},
_num_val = 2.6185479229586067e-322, _string_val = 0x0}
(gdb) x interpreter
0x1038e678: 0x30893ae8
(gdb) p interpreter
$3 = (Interp *) 0x1038e678
(gdb) p e-val
$4 = {_b = {_bufstart = 0x0, _buflen = 53}, _ptrs = {_struct_val = 0x0,
_pmc_val = 0x35}, _i = {_int_val = 0, _int_val2 = 53},
_num_val = 2.6185479229586067e-322, _string_val = 0x0}
(gdb) p 0x35
$5 = 53
(gdb) p (PObj*) 0x35
$6 = (Buffer *) 0x35
-- c
Re: Junctions - feedback and desires
Rod Adams wrote:
I do not believe that is possible.
This is the filtering or unification behavior that people keep
wanting junctions to have, which they do not.
Aww! But what about all the great problems that could be expressed
with them? I know of two languages that consider this to be a core
feature now (Prolog, Oz[1]).
A given junction always has all of the values it was made with. No more,
no less. If you want something else, you have to make a new junction.
Consider that it's been decided that :
$j = 11|0;
10 $j 1
Is true. $j retains the 0 even after the 0 failed a test.
I can't see how this can be possible with the possibility of
autothreading as described in [2]. Maybe the example you suggest is
true, if both comparisons happen simultaneously, but what about this
one?
if ($j 10) {
if ($j 1) {
say $j took on two values at once;
}
}
Let's say that the implementation chose to implement the first if() by
auto-threading. The first thread where $j == 11 succeeds. The second,
where $j == 1 fails. In the second thread, $j == 11 fails.
It is by this assumption that the example in [3] was built.
But wait, isn't (10 $j 1) likely to produce the same opcode tree
as if($j10){if($j1){}} ?
As for the current value, there is only a current value during
threading.
Isn't the threading conceptual, and actual threading invoked only when
the optimiser has finished using available logic / set theory operations
to prevent absurd numbers of threads being made that exit immediately?
Sam.
References:
1. http://xrl.us/fehh (Link to www.mozart-oz.org)
A representation of send+more=money in Oz
2. http://dev.perl.org/perl6/synopsis/S09.html
Some contexts, such as boolean contexts, have special rules for dealing
with junctions. In any scalar context not expecting a junction of values,
a junction produces automatic parallelization of the algorithm. In
particular, if a junction is used as an argument to any routine (operator,
closure, method, etc.), and the scalar parameter you are attempting to
bind the argument to is inconsistent with the Junction type, that
routine is autothreaded, meaning the routine will be called
automatically as many times as necessary to process the individual scalar
elements of the junction in parallel.
3. An implementation of send+more=money using Perl 6 Junctions
http://svn.openfoundry.org/pugs/examples/sendmoremoney.p6
http://xrl.us/feis (revision at time of writing this message)
Re: Junctions - feedback and desires
Rod Adams wrote: I do not believe that you can create a 'lazy junction'. But I don't recall the topic coming up before, so we'll have to wait for Damian to come back unless someone else knows for certain. My understanding is that all lists are conceptually lazy. any(2..Inf) is perfectly valid.
Re: Junctions - feedback and desires
Sam Vilain wrote:
Rod Adams wrote:
I do not believe that is possible.
This is the filtering or unification behavior that people keep
wanting junctions to have, which they do not.
Aww! But what about all the great problems that could be expressed
with them? I know of two languages that consider this to be a core
feature now (Prolog, Oz[1]).
I'm not disputing that it would be powerful. I'm simply saying that as
currently defined, junctions do not behave in this fashion. It also does
not make a lot of sense to filter out restricting values in a none()
junction.
And as one who recently proposed a way of getting Prolog like features
in Perl (through Rules, not Junctions), I understand the appeal
completely. Junctions are not the way to that goal. They are something
different.
A given junction always has all of the values it was made with. No
more, no less. If you want something else, you have to make a new
junction. Consider that it's been decided that :
$j = 11|0;
10 $j 1
Is true. $j retains the 0 even after the 0 failed a test.
I can't see how this can be possible with the possibility of
autothreading as described in [2].
because it gets interpreted as:
10 $j 1
-- (10 $j) ($j 1)
-- (10 any(0, 11)) (any(0, 11) 1)
-- any(10 0, 10 11) any(0 1, 11 1)
-- any(false, true) any(true, false)
-- true true
-- true.
Maybe the example you suggest is
true, if both comparisons happen simultaneously, but what about this
one?
if ($j 10) {
if ($j 1) {
say $j took on two values at once;
}
}
The Csay would occur, even with the first condition as C $j 10 ,
as you likely intended it to be.
Taking multiple values at once is what junctions are all about.
People seem to forget the role the predicate plays in junction
evaluation. You thread over the different values, gain a result, and
then use the predicate to recombine the results into a single scalar.
If instead I had said:
$j = 11 0;
10 $j 1
it would be false, because C all( true, false) is false.
$j itself never changes. It is always a collection of values with a
predicate. If you wish to have a junction with different values in it,
you have to create a new one.
Let's say that the implementation chose to implement the first if() by
auto-threading. The first thread where $j == 11 succeeds. The second,
where $j == 1 fails. In the second thread, $j == 11 fails.
Except that the threadings are indendent of each other.
$j = any(0,11);
$j != $j;
is true.
$j != $j
-- any(0,11) != any(0,11)
-- any(0 != any(0,11), 11 != any(0,11))
-- any(any(0 != 0, 0 != 11), any(11 != 0, 11 != 11))
-- any(any(false, true), any(true, false))
-- any(true, true)
-- true
Similarly:
$j = all(0,11);
$j == $j;
is false.
It is by this assumption that the example in [3] was built.
That assumption is in err, and the example does not generate the
solutions desired
See my response to it in
http://www.nntp.perl.org/group/perl.perl6.language/19428
But wait, isn't (10 $j 1) likely to produce the same opcode tree
as if($j10){if($j1){}} ?
Well
if 10 $j 1 { ... }
if 10 $j { if $j 1 { ... }}
Could easily wind up with the same opcodes. Unless the optimizer saw
something in the first one where it could prove C $j 1 is false.
As for the current value, there is only a current value during
threading.
Isn't the threading conceptual, and actual threading invoked only when
the optimiser has finished using available logic / set theory operations
to prevent absurd numbers of threads being made that exit immediately?
The optimizer can skip threading over values that it can prove will not
affect the outcome. That's short circuiting.
But asking the optimizer to know in advance what is absurd is a tall order.
Even without junctions, someone could make $j an object with an
overloaded set of compare operators against Num. And there's no way for
the compiler to know if those operators are consistent and transitive.
(One could hope they were, but you never know).
I would not call the threading conceptual. It's a very real thing.
2. http://dev.perl.org/perl6/synopsis/S09.html
Some contexts, such as boolean contexts, have special rules for dealing
with junctions. In any scalar context not expecting a junction of values,
a junction produces automatic parallelization of the algorithm. In
particular, if a junction is used as an argument to any routine
(operator,
closure, method, etc.), and the scalar parameter you are attempting to
bind the argument to is inconsistent with the Junction type, that
routine is autothreaded, meaning the routine will be called
automatically as many times as necessary to process the individual scalar
elements of the junction in parallel.
In the cases above, the routine being threaded over is the comparison
operator, not the surrounding code block that contains it.
-- Rod Adams
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Strangely all the tests ( well pyclass pycomplex and pyfunc so far ) pass on freebsd but do so very very slowly and parrot is eating memory like there is no tomorrow. Gets above 300meg during each of the tests. Not sure if this is new as its a long time since I tried parrot on freebsd. -Original Message- From: chromatic [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Michal Jurosz [EMAIL PROTECTED]; perl6-internals@perl.org Sent: Thu, 10 Mar 2005 13:52:51 -0800 Subject: Re: Parrot 0.1.2 with MinGW32 (some experimets) On Thu, 2005-03-10 at 16:36 -0500, [EMAIL PROTECTED] wrote: revision 1.95 date: 2005/03/09 14:52:01; author: leo; state: Exp; lines: +2 -2 Objects 1 - class, mro vtable slots * renamed vtable-data to class as this is it's usage anyway * new vtable-mro slot - empty for now That's my guess too. It segfaults for me during make:
Re: Junctions - feedback and desires
Dave Whipp wrote: Rod Adams wrote: I do not believe that you can create a 'lazy junction'. But I don't recall the topic coming up before, so we'll have to wait for Damian to come back unless someone else knows for certain. My understanding is that all lists are conceptually lazy. any(2..Inf) is perfectly valid. The list being fed into the junction can be lazy. But I believe that the list gets iterated over completely in the creation of the junction, so C any(2..Inf) is valid, but melts your processor similar to C sort 2..Inf . My impression has been that after the creation of a junction, the values that junction has are set in stone. Allowing some form of lazy list to add values at will seems a bit counter to me. But if @Cabal think it's okay to have lazy junctions, I won't argue with them. -- Rod Adams
Re: Junctions - feedback and desires
RA == Rod Adams [EMAIL PROTECTED] writes: My understanding is that all lists are conceptually lazy. any(2..Inf) is perfectly valid. RA The list being fed into the junction can be lazy. But I believe that RA the list gets iterated over completely in the creation of the RA junction, so C any(2..Inf) is valid, but melts your processor RA similar to C sort 2..Inf . i was under the impression that junctions could be smart about ranges like that and do it correctly. sort can't possibly handle that but some junctions and ranges would work fine. it isn't hard to convert that (with the proper boolean) to a boolean expression internally. RA My impression has been that after the creation of a junction, the RA values that junction has are set in stone. Allowing some form of lazy RA list to add values at will seems a bit counter to me. But if @Cabal RA think it's okay to have lazy junctions, I won't argue with them. lazy only when you can actually cheat IMO. 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
Re: MMD as an object.
On Thu, Mar 10, 2005 at 02:22:20PM -0600, Rod Adams wrote:
David Storrs wrote:
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
use Foo; # from above, exports bar is MMD::Random
multi sub bar {...}
Does this generate an error, since one could expect this particular bar
to be Manhattan? Or does it assume Random, since there's already a bar
in existence?
This seems like action-at-a-distance to me;
Well, if you were not expecting Foo to export some bar's, then you're
in for a surprise regardless of dispatch when you call bar in your code
and one of Foo::bar gets called instead of one of yours, because it was
a closer match.
I would say that people should know what they are getting into when they
C use something.
What I'm hearing you say here is Yes, it's action-at-a-distance, but
it's your job to make sure it doesn't trip you up. The problem that
I see is that I may well be able to keep track of everything from the
modules I import, but what about the ones THEY import...and the ones
THEY import...and so on. In a medium-to-large software project, that
can get to be a lot of modules, very quickly.
--Dks
Re: sub and method name overlap.
On Thu, Mar 10, 2005 at 03:27:23PM -0600, Rod Adams wrote:
Given:
class Foo {
method Bar () {...};
}
sub Bar (Any $x) {...};
my Foo $f;
Bar $f;
Is that last line the same as:
Bar.($f);
or
$f.Bar;
I don't see how it can be anything but the former. As I understand
things, when searching for a matching sub/method, the subs are
given preference over indirect objects.
Does it matter if we change C sub Bar to C multi sub Bar ?
Nope.
Is there some form of implicit multi sub that gets created to make C
Bar $f; C $f.Bar ?
I don't think so.
Or does it only work if there is no C multi? sub bar in sight?
That's how I see (no sub or multi in sight)
You can always be explicit if you really want to use the IO notation:
Bar $f:;
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: MMD as an object.
From: Leopold Toetsch [EMAIL PROTECTED]
Date: Thu, 10 Mar 2005 10:53:11 +0100
Rod Adams [EMAIL PROTECTED] wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all the
various routines that share that short name.
Discussion seems to have went off into esoteric cases of locally
overriden dispatcher policies and what not.
What I'd like to know is more basic things:
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
If yes, who is creating it: the Perl6 compiler emits code to do so or
it's up to Parrot to do the right thing?
FWIW, Common Lisp specifies a generic function [1] that collects all
methods defined for a given operation name. (In Perl/Parrot, the
generic function name for your examples would be the string foo; in
Lisp, it would be the symbol FOO in some package, but the practical
difference should be slight.) The important thing is that the GF has
all the information required to make method dispatch decisions.
GFs can be created explicitly with defgeneric [2], or implicitly by
defining methods. According to that model, the Perl6 compiler would
emit code for each method, and ask Parrot to add it to the appropriate
MMD object, which may cause effective methods to be recomputed (or be
marked as invalid for lazy recomputation).
Mind you, I haven't read up on p6 objects, so my $0.02 might not be
worth very much. If so, please rub my nose in the relevant apocalypses,
etc., and I'll shut up. But on the other hand, the CL community has
more than 15 years of experience with MMD, so I wanted to be sure
everyone was aware of it.
2) namespaces of (multi) subs.
A non-multi method is in the classes' namespace. In Parrot terms that's
currently:
%globals{\0class_name}{method_name}
I'm not quite sure, if the method hash shouldn't live inside the class.
Is naming at this level really important here? The operation itself
needs a name (so that people can call it), and classes need class names
(maybe), but all methods are implicitly named by the combination of
operation plus argument signature. Which would seem to mean that,
unlike perl5, the package in which a multimethod is defined doesn't
matter; all that is captured by the argument signature. Or is it
possible to have more than one method with the identical signature? And
if so, what does that mean?
The long name is therefore a list of class names, which suggests
that the single-dispatch naming above is backwards. Of course, I'm
probably out of my depth here . . .
A multi method is similar, except that their can be more then one
with the same short name (which probably means that there has to be a
MultiSub object holding the long names)
I'm not sure it is meaningful to give a sub a short name, certainly
not in the sense that perl5 methods can also be called as subs with the
right package qualification. You can't guarantee that they will be
unique, correct?
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
This sounds right to me. Or perhaps
%globals{foo} -- MultiSub{[foo, 'A', 'B'] = Sub, ...}
just to belabor the point a bit.
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Is this really different? After all, the operation foo should be just
a string in either case. Or is this just my ignorance showing?
-- Bob Rogers
http://rgrjr.dyndns.org/
[1] http://www.lispworks.com/documentation/HyperSpec/Body/t_generi.htm
[2]
http://www.lispworks.com/documentation/HyperSpec/Body/m_defgen.htm#defgeneric
Re: MMD as an object.
David Storrs wrote:
On Thu, Mar 10, 2005 at 02:22:20PM -0600, Rod Adams wrote:
David Storrs wrote:
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
use Foo; # from above, exports bar is MMD::Random
multi sub bar {...}
Does this generate an error, since one could expect this particular bar
to be Manhattan? Or does it assume Random, since there's already a bar
in existence?
This seems like action-at-a-distance to me;
Well, if you were not expecting Foo to export some bar's, then you're
in for a surprise regardless of dispatch when you call bar in your code
and one of Foo::bar gets called instead of one of yours, because it was
a closer match.
I would say that people should know what they are getting into when they
C use something.
What I'm hearing you say here is Yes, it's action-at-a-distance, but
it's your job to make sure it doesn't trip you up. The problem that
I see is that I may well be able to keep track of everything from the
modules I import, but what about the ones THEY import...and the ones
THEY import...and so on. In a medium-to-large software project, that
can get to be a lot of modules, very quickly.
The question is not what they import. The question is what they export
into your package. If it's not exported into your package, the other
multi's are in a different package, and get a different short name. I
see the short name as including the package name for subs, class name
for methods. Only the signature is chopped off.
I'm only asking you to keep track of what gets imported into your
current package, which I do not think is asking for too much, even in a
large scale project. Whatever your used modules have in their packages
which they keep to themselves, including everything _they_ imported from
_other_ modules, is not your concern... that's a different package space.
If you go pumping new multi's into someone else's package by saying C
multi sub Foo::Bar {...} , well, you better be familiar with what's
already there.
So, it could be considered action at a distance, but feels more like
keeping track of what you've asked others to dump in your lap.
-- Rod Adams
Re: Junctions - feedback and desires
Rod Adams writes:
Dave Whipp wrote:
Rod Adams wrote:
I do not believe that you can create a 'lazy junction'. But I don't
recall the topic coming up before, so we'll have to wait for Damian
to come back unless someone else knows for certain.
My understanding is that all lists are conceptually lazy.
any(2..Inf) is perfectly valid.
The list being fed into the junction can be lazy. But I believe that
the list gets iterated over completely in the creation of the
junction, so C any(2..Inf) is valid, but melts your processor
similar to C sort 2..Inf .
Well, if we guarantee that .states never returns two of the same value,
then of course you can not call .states on an infinite junction.
And indeed, while it's possible to do this (taking the range to be an
arbitrary infinite list):
if any(2...) 100 {...}
You'll melt if you do this:
if any(2...) 2 {...}
We could make junctions smart about ranges, so that the latter can just
fail, but I argue that we can only do it well in the simplest of cases.
It's probably better not to allow infinite ranges in junctions.
On the other hand, if we give junctions well-defined semantics in terms
of their underlying lists (such as orderedness), then lazy junctions may
be just fine. There's a lot you can do with lazy lists, and there are a
lot of very nice idioms having to do with junctions, and I'd like to
find a way to make those two things not be mutually exclusive.
Luke
Problem with Readonly and Devel::Cover
Anyone seen this message with Readonly running under Devel::Cover: Invalid tie at (eval 22)[/usr/local/lib/perl5/site_perl/5.8.0/Readonly.pm:338] line 9 It's a little spooky... my tests used to be fine, but then I made a couple innocuous changes in one test file (changing log levels) and I starting getting this failure -- in a completely different test file!! -kevin
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Matt Diephouse [EMAIL PROTECTED] wrote: Some of these same tests are failing on debian, fedora, and freebsd (fresh checkouts). It looks like someone broke something. Release or current CVS? leo
Re: Parrot 0.1.2 with MinGW32 (some experimets)
On Thu, 10 Mar 2005 22:23:07 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Matt Diephouse [EMAIL PROTECTED] wrote: Some of these same tests are failing on debian, fedora, and freebsd (fresh checkouts). It looks like someone broke something. Release or current CVS? Current CVS. Failed TestStat Wstat Total Fail Failed List of Failed --- t/dynclass/foo.t 1 256 11 100.00% 1 t/dynclass/gdbmhash.t13 332813 13 100.00% 1-13 t/dynclass/pybuiltin.t5 1280 65 83.33% 1-2 4-6 t/dynclass/pyclass.t 6 1536 66 100.00% 1-6 t/dynclass/pycomplex.t1 256 11 100.00% 1 t/dynclass/pyfunc.t 4 1024 44 100.00% 1-4 t/dynclass/pyint.t 25 640025 25 100.00% 1-25 [EMAIL PROTECTED]:~/parrot$ ./parrot -t --gc-debug /home/matt/parrot/t/dynclass/pyint_10.imc trace.log 0 loadlib P1, python_group - P1=RetContinuation=PMC(0x849e848 Adr:0x0), Segmentation fault -- matt diephouse http://matt.diephouse.com
SEND + MORE = MONEY (works now in pugs with junctions!)
Rod Adams wrote:
And as one who recently proposed a way of getting Prolog like features
in Perl (through Rules, not Junctions), I understand the appeal
completely. Junctions are not the way to that goal. They are something
different.
Taking multiple values at once is what junctions are all about.
People seem to forget the role the predicate plays in junction
evaluation. You thread over the different values, gain a result, and
then use the predicate to recombine the results into a single scalar.
That assumption is in err, and the example does not generate the
solutions desired
I've changed examples/sendmoremoney.p6 in the pugs distribution to use
junctions correctly to demonstrate that they *can* be used to solve these
sorts of problems, and that it is just a matter of semantics and writing
code correctly.
However, poor semantics can make the task of writing optimisers
unnecessarily difficult or impractical, as Bourne demonstrated.
in short, it seems people want this:
my $a = any(1..9);
my $b = any(1..9);
my $c = any(0..9);
if ( $a != $b $b != $c $a != $c
($a + $b == $a * 10 + $c) ) {
print $a + $b = $a$c;
}
To mean this (forgive the duplication of collapse() here):
sub collapse($x, $sub) { $sub.($x) }
sub collapse($x, $y, $sub) { $sub.($x,$y) }
my $a = any(1..9);
my $b = any(1..9);
my $c = any(0..9);
collapse($a, $b, - $a, $b {
($a != $b)
collapse($c, - $c {
if ( ( $b != $c ) ( $a != $c )
($a + $b == $a * 10 + $c) ) {
say $a + $b = $a$c;
}
});
});
(and YES THAT WORKS g).
However, the former keeps the optimisation out of the algorithm, so that
when someone comes along later with a nice grunty optimiser there is more
chance that it gets a go at the entire solution space rather than having
to fall back to exhaustive searching.
(which might have to find ways to prove associativity of , etc, to make
`real' optimisations).
I'm trying to see a way that these two ways of using junctions are
compatible. As I see it, people want to stretch out the time that the
junction is true, to something non-zero, without having to explicitly
create all those closures.
Getting the old behaviour would be easy, just set a variable in the `if'
clause:
my $j1 = any(1..5);
my $j2 = any(5..9);
my $they_equal;
if ($j1 == $j2) {
# intersection of sets - $j1 and $j2 are any(5), any(5)
$they_equal = 1;
} else {
# symmetric difference of sets - $j1 and $j2 are now
# any(1..5), any(5..9) (where $j1 != $j2 :))
}
if ($they_equal) {
}
Now, the `where $j1 != $j2' bit there, which looks like it's on crack, is
a way of representing that instead of actually calling that second branch
24 times, it could be calling it with two junctions which are `entangled'
(or, if you prefer, `outer joined'). $j1 and $j2 appear almost untouched
- except any test that uses $j1 and $j2 together will not see the
combination of ($j1 == 5) and ($j2 == 5).
I mean, wouldn't it really be nice if you could write stuff like this:
my @users is persistent(users.isam);
my @accounts is persistent(accounts.isam);
my $r_user = any(@user);
my $r_account = any(@account);
if ( $r_account.user == $r_user ) {
say(That junction is:, $r_user);
}
$r_user at that point represents only the users which have at least one
object in @accounts for which there exists an $r_account with a `user'
property that is that $r_user member[*].
The closure would then either be run once, with $r_user still a junction
(if the interpreter/`persistent' class was capable of doing so), or once
for every matching tuple of ($r_account, $r_user). We're still talking in
terms of Set Theory, right?
One last thing - that comment about any(@foo) == one(@foo) not
checking for uniqueness in a list is right - the correct version
is:
all(@foo) == one(@foo)
Sam.
Footnotes:
* - any relational database `experts' who want to remind me of which
normalisation form rules this breaks, please remember that RDBMSes
and normalised forms approximate Set Theory, which this is trying to
do as well, so I believe such discussion is irrelevant.
