Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)

Patrick (>), Carl (>>), Patrick (>>>): >> > But yes, I expect that it will be caught as >> > a compile-time error. >> >> And do you agree it's reasonable to expect this of every compiler? > > Reasonable to expect it, yes -- but whether or not this rises to the > level of being a "requirement in th

Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)

Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote: Pm (>): In Rakudo's case, we just haven't implemented read-only traits on variables yet. Goodie. I guessed as much. But yes, I expect that it will be caught as a compile-time error. And do you agree it's reasonable to expect t

Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)

On Fri, May 09, 2008 at 05:09:31PM +0200, Carl Mäsak wrote: > Pm (>): > > In Rakudo's case, we just haven't implemented read-only traits > > on variables yet. > > Goodie. I guessed as much. > > > But yes, I expect that it will be caught as > > a compile-time error. > > And do you agree it's rea

Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)

Pm (>): > In Rakudo's case, we just haven't implemented read-only traits > on variables yet. Goodie. I guessed as much. > But yes, I expect that it will be caught as > a compile-time error. And do you agree it's reasonable to expect this of every compiler? // Carl

Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)

On Fri, May 09, 2008 at 03:02:28PM +0200, Carl Mäsak wrote: > TSa (>): > > sub bar ($x) > > { > >$x = 3; # error, $x is readonly > >foo($x); # error, could hit rw Str > > } > > By the way, I hope it's possible to make the assignment `$x = 3` to > the read-only variable $x a compile-time

Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)

HaloO, Carl Mäsak wrote: By the way, I hope it's possible to make the assignment `$x = 3` to the read-only variable $x a compile-time error. I hope so, too. The variable and its read-only constraint is known at compile time and *not* dependend on the value inside. How it came in there in the f

Compile-time checking of assignment to read-only variables (Re: MMD distances)

TSa (>): > sub bar ($x) > { >$x = 3; # error, $x is readonly >foo($x); # error, could hit rw Str > } By the way, I hope it's possible to make the assignment `$x = 3` to the read-only variable $x a compile-time error. In fact, I hope this to such a degree that I would like it to be part

Re: MMD distances

HaloO, John M. Dlugosz wrote: TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: It's called overload resolution. Perl 6 can't do that at compile time unless *all* targets are available as rw and readonly variants. I don't follow that statement. Can you give an example? multi sub foo (Int $i

Re: MMD distances

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: It's called overload resolution. Perl 6 can't do that at compile time unless *all* targets are available as rw and readonly variants. I don't follow that statement. Can you give an example?

Re: MMD distances

HaloO, John M. Dlugosz wrote: - const int& is preferred over int/int&. - const int* is preferred over int*. You mean when in each case both versions are defined as overloads only the preferred ones are ever called? C++ is the other way around. For an int* argument the int* version is preferred

Re: MMD thoughts 2008

HaloO, Buddha Buck wrote: Is this right? (E,D,D) to (A,C,C) is (4,1,1), with a L1 metric of 6. (E,D,D) to (D,A,A) is (1,3,3) with an L1 metric of 7. Are you sure (E,D,D) would bind to (D,A,A)? Oh, shit. I fail with the simplest of mathematics. Indeed (E,D,D) binds to (D,A,A). The problem I w

Re: MMD thoughts 2008

Sorry, you're not following me at all. I'll try again later. TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: HaloO, John M. Dlugosz wrote: OK, why would someone create those forms in the first place? I would think they grow like that historically. A five steps long subtyping chain is not p

Re: MMD thoughts 2008

Sorry to reply to the wrong comment, but I lost the original thread in my mail archives and didn't notice this until now. On Tue, May 6, 2008 at 1:54 PM, John M. Dlugosz <[EMAIL PROTECTED]> wrote: > TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: > > > > > The fundamental flaw of metric mmd is th

Re: MMD thoughts 2008

HaloO, John M. Dlugosz wrote: OK, why would someone create those forms in the first place? I would think they grow like that historically. A five steps long subtyping chain is not particularly extraordinary. Note that multi entries live outside of classes and their single dispatch. The sub

Re: mmd for bitwise_and causes a segfault with my pmc types

It seems to work in general, but in some cases (especially when I allocate too much memory) it causes me a segfault or an error like: Trace/breakpoint trap (core dumped) It was caused by some unitialized memory in src/mmd.c. rt #43105 solves it. -- Mehmet

Re: mmd-draft.txt, why coercions

HaloO, I wrote: This depends on the partial order of parameter types of the candidates. Note that this order is rooted at the actual argument type. I don't know if the following is obvious but I want to rant about it ;) This partial order of the parameter types is in the case of a readonly par

Re: mmd-draft.txt, why coercions

HaloO, I have one further question to the document. It mentions chains of type coercions that are applied in the compatibility stage. A type that has fewer conversion steps is considered more specific. But is that a wise thing to do in an MMD system? I would expect no coercions to occur. How can

Re: mmd-draft.txt

HaloO, Audrey Tang wrote: > A variant's score cards only records two Boolean values for each > variant: "voting" and "qualified". Here is a summary of the explanation Audrey gave me on #perl6. Note that this is from memory because I didn't save the log. In particular I don't remember exactly whe

Re: mmd-draft.txt

在 Oct 26, 2006 10:26 AM 時，TSa 寫到： I figure that http://svn.openfoundry.org/pugs/docs/notes/multi_method_dispatch/ mmd-draft.txt hasn't made it into S06 yet. So what is the current state of affairs? The original plan was to have Larry review it in Brazil and check it in along with an implem

Re: MMD roundup 2 - TODO and design items

Rather than adding another file, I'd recommend putting these under DESIGN in docs/ROADMAP. Then they're all in one place for Chip when he gets more tuits. I added a link to this one there. Regards. On Jul 25, 2005, at 10:53 AM, Leopold Toetsch wrote: Nicholas Clark wrote: This all g

Re: MMD roundup 2 - TODO and design items

Nicholas Clark wrote: This all got Warnocked, didn't it? Having read it twice, I don't think I'm going to get closer to a decent response than "er, this is really a call for the designer to make, isn't it?" Mway be it's time to start a WARNOCKED file in parrot's root dir and collect such und

Re: MMD roundup 2 - TODO and design items

On Mon, Apr 18, 2005 at 12:15:34PM +0200, Leopold Toetsch wrote: > Below is some stuff, which I'm unsure of how it should be implemented > eventually. Input is highly welcome. > TODO items and design issues > > 1) bitwise or, and, xor > > We currently have two distinct sets of opcodes and MMD

Re: MMD handling (was Re: Hackathon notes)

On Fri, Jul 08, 2005 at 19:19:34 -0500, Rod Adams wrote: > Then all we need is a DWIMish sort function. Think of parameter list shape (slurpiness, arity) as a mold you can fit stuff into. Then it becomes a simple matter of reducing the match list to your compatible subs. Then see http://svn.ope

Re: MMD handling (was Re: Hackathon notes)

David Storrs wrote: On Jul 8, 2005, at 4:25 PM, Dave Whipp wrote: Rod Adams wrote: multi method foo#bar (Num x) {...} multi method foo#fiz (String x) {...} $y = 42; $obj.foo#fiz($y); # even though $y looks like a Num $obj.foo($z); # let MMD sort it out. Instead of ch

Re: MMD handling (was Re: Hackathon notes)

On Fri, Jul 08, 2005 at 16:45:09 -0400, David Storrs wrote: > Could we break them out into separate threads so that our poor summarizer > doesn't go > bonkers? See? That's what specialization/particulation is good for. Thanks for strengthening my point! -- () Yuval Kogman <[EMAIL PROTECTE

Re: MMD vs. anonymous parameter types referencing earlier parameters

On Tue, Jun 14, 2005 at 04:25:17PM +0200, Chip Salzenberg wrote: : On Tue, Jun 14, 2005 at 03:43:42PM +0200, "TSa (Thomas Sandlaß)" wrote: : > The syntax might just be: : > : >&is_equal:(Integer $a, Integer where { $_ == $a } :) : > : : It's a new type object every time, so every time you ru

Re: MMD vs. anonymous parameter types referencing earlier parameters

Chip Salzenberg wrote: Link link. http://www.cs.washington.edu/research/projects/cecil/www/Papers/gud.html In case it matters, we're trying to support the Perl 6 semantics of both ($a:$b:) and ($a,$b:). The former looks like something that could be implemented with something called "predicat

Re: MMD vs. anonymous parameter types referencing earlier parameters

On Tue, Jun 14, 2005 at 03:43:42PM +0200, "TSa (Thomas Sandlaß)" wrote: > Chip Salzenberg wrote: > >This: > >multi sub is_equal(Integer $a, Integer where { $_ == $a } $b: ) { 1 } > >hurts. At least as I've been given to understand it[*], is impossible > >to implement, because the second parame

Re: MMD vs. anonymous parameter types referencing earlier parameters

Chip Salzenberg wrote: This: multi sub is_equal(Integer $a, Integer where { $_ == $a } $b: ) { 1 } hurts. At least as I've been given to understand it[*], is impossible to implement, because the second parameter's type can't be precalculated in order to prepare for MMD dispatching. Quite

Re: mmd

Jeff Horwitz wrote: [ mmd test code ] the pmc version of bar() is never called, even when passing a PMC. This is fixed now. A differing argument count had a too low distance penalty. But please note that the MMD system still has no clue what is an invocant and what a plain call argument bec

Re: mmd

[ cc'ed list ] Chip Salzenberg wrote: On Tue, May 24, 2005 at 02:42:47PM -0400, Jeff Horwitz wrote: .sub bar method, @MULTI(Foo, pmc) At first blush, I think mmd based on representation choice ($I vs. $P) is a mistake. Why should an integer in a $P0 be mmd'd differently from an integer in

Re: mmd

On Tue, 24 May 2005, Leopold Toetsch wrote: > Multi subs and especially multi methods are barely tested. 'pmc' or '_' > should match 'Any' PMC, so that's for sure a bug. Can you please provide > a test-like sample file to investigate, thanks. here you go. it should print "string PMC nothing", bu

Re: mmd

Jeff Horwitz wrote: for mod_parrot i want to support both passing both PMCs and native types to the apache API, depending on the HLL. MMD was doing a great job handling this for me until i ran into a problem. given the following methods: .sub bar method, @MULTI(Foo, string) .sub bar method, @M

Re: MMD leftover: logical_{or,and,xor}

Patrick R. Michaud wrote: On Wed, May 11, 2005 at 10:17:30AM +0200, Leopold Toetsch wrote: So the right thing for the logical functions seems to be, to just return the left or right side according to their boolean value (or return a new Boolean false in case of xor), i.e. you get a reference to o

Re: MMD leftover: logical_{or,and,xor}

On Wed, May 11, 2005 at 10:17:30AM +0200, Leopold Toetsch wrote: > > So the right thing for the logical functions seems to be, to just return > the left or right side according to their boolean value (or return a new > Boolean false in case of xor), i.e. you get a reference to one of the > PMCs

Re: MMD acting up...

Cory Spencer <[EMAIL PROTECTED]> wrote: > I've encountered some multimethod dispatch funnyness tonight. The > included code which one would expect to produce a value of 1 ends up > printing a value of 3. It wasn't really a MMD problem, but the already described problem of an Integer being either

Re: MMD roundup 2 - TODO and design items

Leopold Toetsch <[EMAIL PROTECTED]> wrote: > TODO items and design issues And some more: 6) stringish MMD infix operators: concatenate, repeat The implementation takes either two strings, or one string and an integer repeat count. Again not much multi to dispatch IMHO. Missing: PMC variants of

Re: MMD roundup 2 - TODO and design items

Leopold Toetsch <[EMAIL PROTECTED]> wrote: > 5) new opcodes that return a new result: > Px = n_add Py, Pz # new Px created > These opcodes will be done RSN. RSN is now. There is one basic test in t/pmc/integer.t. Overloading is tested in mmd.t. More tests are welcome for other PMCs. Cav

Re: MMD as an object.

Leopold Toetsch wrote: Rod Adams <[EMAIL PROTECTED]> wrote: If I were to need a different policy for a given method .bar, I would likely create something called .bar much like your "run_random_bar", which then dispatches amongst methods I name something like ._bar . I see some detractions t

Re: MMD as an object.

Rod Adams <[EMAIL PROTECTED]> wrote: > If I were to need a different policy for a given method .bar, I would > likely create something called .bar much like your "run_random_bar", > which then dispatches amongst methods I name something like ._bar . > I see some detractions to this approach: > 1)

Re: MMD as an object.

Leopold Toetsch wrote: Ok. If you'd really need such random dispatch, it could be done like this, when I interpret A12 correctly: sub run_random_bar($x) { my @meths = WALKMETH($x, :method('bar')); my $meth = @meths[rand(@meths.elems)]; $meth($x); } or even with my sub bar($x) {...} #

Re: MMD as an object.

[EMAIL PROTECTED] wrote: Ok. If you'd really need such random dispatch, it could be done like this, when I interpret A12 correctly: sub run_random_bar($x) { my @meths = WALKMETH($x, :method('bar')); my $meth = @meths[rand(@meths.elems)]; $meth($x); } or even with my sub bar($x) {...}

Re: MMD as an object.

Rod Adams <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >>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

Re: MMD as an object.

Bob Rogers <[EMAIL PROTECTED]> wrote: >From: Leopold Toetsch <[EMAIL PROTECTED]> >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

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 thi

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 int

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 particu

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

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 Ran

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

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 Rando

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

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 exa

Re: MMD as an object.

Larry Wall wrote: On Wed, Mar 09, 2005 at 06:19:25AM -0600, Rod Adams wrote: : I was thinking more along the lines of : : :use MMD::Pattern; : :our &func is MMD::Pattern; : :multi func (...) {...} :multi func (... ...) {...} :multi func (... ... ...) {...} : :multi func2

Re: MMD as an object.

On Wed, Mar 09, 2005 at 06:19:25AM -0600, Rod Adams wrote: : I was thinking more along the lines of : : :use MMD::Pattern; : :our &func is MMD::Pattern; : :multi func (...) {...} :multi func (... ...) {...} :multi func (... ... ...) {...} : :multi func2 (...) {...} :

Re: MMD as an object.

Luke Palmer wrote: Keep in mind that the two following definitions are equivalent: class A { method foo () {...} } multi sub foo (A $a) {...} Except for attribute access, I think. For public attrs the accessor is not used and private ones are available: class A { has $.pub = "pub"; ha

Re: MMD as an object.

Rod Adams writes: > I wasn't intending it to be junctive. I was just noting that you needed > separate holders for subs and methods, since you shouldn't be able to > stuff a method into a multi sub. Keep in mind that the two following definitions are equivalent: class A { method foo () {...

Re: MMD as an object.

Thomas Sandlaß wrote: Rod Adams 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. It doesn't hav

Re: MMD as an object.

Rod Adams 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. It doesn't have to be junctive becaus

Re: MMD and VTABLE_find_method

Sam Ruby wrote: I took your example code, almost word for word, and added approximately three, count them three, machine instructions (not Parrot instructions, not C statements, but machine instructions) to the path length, and now adjectives like "horribly slow and wierd" come out. It looks li

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: pmclass default abstract noinit { PMC* add (PMC* left, PMC* right) { PRESERVE_CONTEXT; add_func = mmd_find("__add"...) // via VTABLE_find_method and here it becomes horribly slow and weird. You are already in one "add". What do you want t

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: PyStringPyIntPyNum Integer ... -- PyString py_add_sadd_err add_err add_err PyInt add_err add_i add_n add_i PyNum add_err add_n add_n add_i

Re: MMD and VTABLE_find_method

Sam Ruby wrote: [ a lot - I'll split answers ] Leopold Toetsch wrote: Sam Ruby wrote: It seems obvious, but it leads to surprises. Example: '1' + '2' The result will depend on what the actual types are of the inputs perhaps even what the context is of the caller. Ehem, given that and ... (from

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: First, a few things to note: the semantics of "add" vary from language to language. In particular, add is not guaranteed to be commutative in Python (think string addition). Yes, of course. It seems obvious, but it leads to surprises. Example: '1' + '2'

Re: MMD and VTABLE_find_method

Sam Ruby writes: > In the general case, a call to a subroutine with three arguments can > have four possibilities: anywhere from zero to three arguments may be > involved in the dispatch. > > I also read this to say that whatever code is generated by a subroutine > call is independent of the nu

Re: MMD and VTABLE_find_method

Hi, a lurker here. Probably you forgot the braces: > + /* let's ignore the complexities of a distance_func for now... */ > + mmd_flag = 0; > + addsub = VTABLE_find_method(INTERP, $1, __add, 0, &mdd_flag); > + if (!addsub) { > + mmd_flag = 0; > + adds

Re: MMD and VTABLE_find_method

Sam Ruby wrote: First, a few things to note: the semantics of "add" vary from language to language. In particular, add is not guaranteed to be commutative in Python (think string addition). Yes, of course. As my proposal is primarily focused on where the logic is placed in the system, not how i

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: First, a direct quote from : Please let's stay at the basics. Please describe your counter proposal for a very elementary add Px, Py, Pz operation. There's really no need to procede to Perl6 objects,

Re: MMD and VTABLE_find_method

Sam Ruby wrote: First, a direct quote from : Please let's stay at the basics. Please describe your counter proposal for a very elementary add Px, Py, Pz operation. There's really no need to procede to Perl6 objects, if we can't even find

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: A "foo" PMC could represent an entire row in a two dimensional MMD, or an entire plane in a three dimensional MMD, ... etc. What does it mean: "represent a row..."? What about the namespace pollution? Again: where does this hypothetica

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: A "foo" PMC could represent an entire row in a two dimensional MMD, or an entire plane in a three dimensional MMD, ... etc. What does it mean: "represent a row..."? What about the namespace pollution? Again: where does this hypothetical MMD PMC come from? A

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: A few things to note: "foo" is a PMC. It therefore is an object. It can have state (properties, attributes, etc). It can "know" how many arguments are involved in multiple dispatch. The MMD information can't hang off the Sub PMCs.

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: A few things to note: "foo" is a PMC. It therefore is an object. It can have state (properties, attributes, etc). It can "know" how many arguments are involved in multiple dispatch. The MMD information can't hang off the Sub PMCs. How do you find the co

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: However, from : Whenever you make a call using subroutine call syntax, it's a candidate for multiple dispatch. I read this to mean that the *caller* does nothing to distingu

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: However, from : Whenever you make a call using subroutine call syntax, it's a candidate for multiple dispatch. I read this to mean that the *caller* does nothing to distinguish between calls to si

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: The caller sets: mmd_flag := NULL ... no MMD, plain method lookup mmd_flag := &depth ... return the next matching method starting at the given parent search depth In the general case, how does the ca

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: The caller sets: mmd_flag := NULL ... no MMD, plain method lookup mmd_flag := &depth ... return the next matching method starting at the given parent search depth In the general case, how does the caller know that MMD is i

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: 2) n-dimensional MMD Perl6 supports a more general form of MMD: multi sub foo(ClassA $a, ClassB $b, ClassC $c : ...) { ... } [snip] 4) Proposed changes: a) All method lookup goes through VTABLE_find_method. To achieve MMD functionality, two arguments are added to the find_

Re: MMD problem with mmd_dispatch_v_pnp

Jens Rieks <[EMAIL PROTECTED]> wrote: > Hi! > I have found a problem with with mmd_dispatch_v_pnp. > The function calls (for an Integer-PMC) Parrot_Integer_multiply_int, which > expects an INTVAL, but a FLOATVAL is passed to it. I can't reproduce that. new P1, .Integer set P1, 2 new P2, .U

Re: MMD: more implications

Sam Ruby <[EMAIL PROTECTED]> wrote: > General thoughts on the proposal to replace VTABLES with methods: > 1) Anything that is unary (i.e., contains exactly or one argument) is > not affected by MMD. That's not quite true. We currently have just infix MMD dispatching on left and right. That's just

Re: MMD: more implications

General thoughts on the proposal to replace VTABLES with methods: 1) Anything that is unary (i.e., contains exactly or one argument) is not affected by MMD. There is no need to replace any such methods. 2) While I don't see Python translators using a "sin" opcode, I can see the implementation o

Re: MMD dispatch

Leopold Toetsch <[EMAIL PROTECTED]> wrote: > ... We can deal > with performance implications later. I've googled for »MMD "polymorphic inline cache"«: 1-2 of about 3 on perl6-internals archives. You might guess the author of these mail ;) leo

Re: MMD table setup semantics

At 3:35 PM +0100 5/27/04, Nicholas Clark wrote: On Wed, Apr 28, 2004 at 06:36:34PM -0400, Dan Sugalski wrote: At 2:56 PM -0700 4/28/04, Larry Wall wrote: >On Wed, Apr 28, 2004 at 05:20:53PM -0400, Dan Sugalski wrote: >: The second question is "if we do, how do we figure which method is >: clos

Re: MMD table setup semantics

On Wed, Apr 28, 2004 at 06:36:34PM -0400, Dan Sugalski wrote: > At 2:56 PM -0700 4/28/04, Larry Wall wrote: > >On Wed, Apr 28, 2004 at 05:20:53PM -0400, Dan Sugalski wrote: > >: The second question is "if we do, how do we figure which method is > >: closest?" > >: > >: Personally I'm of the geomet

Re: MMD & objects

Dan Sugalski <[EMAIL PROTECTED]> wrote: > If we do that it means every PMC class is essentially a base type as > far as Parrot's concerned. Basically yes. We just borrow some functions from parents to avoid reimplementation and to reduce code size. I don't think that we need much more inside the

Re: MMD & objects

At 9:39 AM +0200 5/18/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: The question isn't whether they *do*--rather it's whether they *should*. The current implementation's not all that relevant except as a demonstration of one set of semantics. What I want to do is work out w

Re: MMD & objects

Dan Sugalski <[EMAIL PROTECTED]> wrote: > The question isn't whether they *do*--rather it's whether they > *should*. The current implementation's not all that relevant except > as a demonstration of one set of semantics. What I want to do is work > out what the 'proper' semantics ultimately should

Re: MMD & objects

At 5:54 PM +0200 5/17/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: The basics of MMD are almost done. The two things we still need to deal with are: *) Inherited methods *) Objects ... Either way we need to build up the tables so inherited MMD methods actually get inhe

Re: MMD & objects

Dan Sugalski <[EMAIL PROTECTED]> wrote: > The basics of MMD are almost done. The two things we still need to > deal with are: > *) Inherited methods > *) Objects > ... Either way we need to build up > the tables so inherited MMD methods actually get inherited. MMD registration "inherits" as much

Re: MMD stuff

At 10:48 AM -0700 5/14/04, Jeff Clites wrote: On May 14, 2004, at 9:04 AM, Dan Sugalski wrote: Today's project is to get all the MMD things actually using MMD. I've put in the first wave of changes (well, OK, second if you consider Leo's BXOR test as the first) and should get the rest of the stu

Re: MMD stuff

On May 14, 2004, at 9:04 AM, Dan Sugalski wrote: Today's project is to get all the MMD things actually using MMD. I've put in the first wave of changes (well, OK, second if you consider Leo's BXOR test as the first) and should get the rest of the stuff in today. This part's a bit hackish but, w

Re: MMD performance

Leopold Toetsch <[EMAIL PROTECTED]> wrote: [ another MMD performance compare ] Just an update. Last benchmark still called MMD via the vtable. Here is now a compare of calling MMD from the run loop: $ parrot -C mmd-bench.imc vtbl add PerlInt PerlInt 1.072931 vtbl add PerlInt Integer 1.085116 M

Re: MMD and/or vtable inconsistencies

At 10:39 AM +0200 4/30/04, Leopold Toetsch wrote: - There is only an is_equal vtable but an MMD_STREQ define and default function - {eq,ne}_{str,num} opcodes are using VTABLE_cmp, which is fine but could be inefficient especially for strings - cmp/cmp_num is handled by the same MMD slot Yeah, we

Re: MMD table setup semantics

At 9:37 AM -0400 4/29/04, William Coleda wrote: Leopold Toetsch wrote: - TclInt - TclFloat - TclObject - TclString This is a small subset of PMCs enumerating *current* scalars. I can't imagine that e.g. tcl is happy, when a tcl scalar falls back to a morphing variant of a Perl scalar. OTOH just doi

Re: MMD table setup semantics

Leopold Toetsch wrote: - TclInt - TclFloat - TclObject - TclString This is a small subset of PMCs enumerating *current* scalars. I can't imagine that e.g. tcl is happy, when a tcl scalar falls back to a morphing variant of a Perl scalar. OTOH just doing the math operations would be fine. So what'

Re: MMD performance

Aaron Sherman <[EMAIL PROTECTED]> wrote: > Good stuff! One thing leaps to mind when you mention the cache though... > keep in mind that blowing L2 cache (which we might be in no danger of > doing at all, but I'm just bringing it up) might be WORSE than you would > think on P4 and beyond because of

Re: MMD performance (was: keyed vtables and mmd)

On Thu, 2004-04-29 at 03:33, Leopold Toetsch wrote: > As Dan already said there is no performance hit (at least if the MMD > tables don't blow the caches). Good stuff! One thing leaps to mind when you mention the cache though... keep in mind that blowing L2 cache (which we might be in no danger o

Re: MMD and PASM subs

Dan Sugalski <[EMAIL PROTECTED]> wrote: >>cc1: Invalid option `-falign-functions=8' > The manpage made it sound like it was an absolute thing, but I can > see it being a power-of-two number. GCC 3.3.3 likes the 8, so I > hadn't noticed. I've a =3 build going now--if it tests OK I'll commit > the

Re: MMD and PASM subs

At 7:12 PM +0200 4/29/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: And just to add extra evil, now it works. Seems that gcc does *not* align function pointers by default. Almost: $ perl Configure.pl --maintainer --floatval=double --verbose-step=Determ ... cc1: Invalid option

Re: MMD and PASM subs

At 7:08 PM +0200 4/29/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Oh, right, and... this is really, really evil. Which is why I just put it in. :) *g* Should I cleanup and implement the rest? And which opcode of the (duplicated? mm* ops? I'll go patch this up. I'm halfway t

  1   2   >