Trey Harris wrote:
One thing that occurs to me: following this "contract" or "promise"
analogy, what does C<...> mean in a role or class?
Unless I've missed somewhere in the Synopses that explicates C<...>
differently in this context, yada-yada-yada is just code that "complains
bitterly (by call
In a message dated Thu, 28 Sep 2006, Aaron Sherman writes:
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate fil
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate file - quite likely one heavily laced with
> POD).
That's a fi
Author: jonathan
Date: Thu Sep 28 14:23:15 2006
New Revision: 14784
Modified:
trunk/docs/pdds/clip/pdd13_bytecode.pod
Log:
Add draft of the bytecode PDD. This is still missing some changes that need to
be made following discussion with Allison, but gives the big picture of what is
proposed.
Author: larry
Date: Thu Sep 28 18:53:32 2006
New Revision: 12485
Modified:
doc/trunk/design/syn/S03.pod
Log:
Extirpated machine-dependent definition of bit complement, noticed by audreyt++.
Modified: doc/trunk/design/syn/S03.pod
===
Author: jonathan
Date: Thu Sep 28 15:55:52 2006
New Revision: 14785
Modified:
trunk/docs/pdds/clip/pdd13_bytecode.pod
Log:
Add most of the changes resulting from discussion with Allison.
Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod
On Thursday 28 September 2006 17:57, Matt Diephouse wrote:
> Why not handle this like we handle subroutines? That is, why don't we
> have a find_method opcode that returns a bound method? That simplifies
> parsing for IMCC and makes PIR a little simpler.
> obj.'abc'() # call 'abc' method of ob
Allison Randal <[EMAIL PROTECTED]> wrote:
> .local string abc
>
> obj.'abc'() # call 'abc' method of obj
> obj.abc()# always the same as above
> obj.{abc}() # call method indicated by abc symbol
> obj.{S0}() # call metho
Hi,
I've checked in the proposed bytecode PDD and also most of the changes
that I discussed with Allison earlier today. Feedback on it would be
greatly appreciated.
One of the areas that it would good to have some input on, even if it's
just a "yes, that's sane", is versioning. The current i
On Thursday 28 September 2006 14:51, Markus Triska wrote:
> Allison Randal writes:
> > mini transformation language to use in the compiler tools.
>
> For what purpose, roughly? I've some experience with rule-based
> peep-hole optimisations. If it's in that area, I volunteer.
That's part of it, bu
METHOD INTVAL get_allocated_size() {
return PMC_int_val2(SELF); /* or whatever */
}
great, exactly what I needed
thanks
karl
Allison Randal writes:
> mini transformation language to use in the compiler tools.
For what purpose, roughly? I've some experience with rule-based
peep-hole optimisations. If it's in that area, I volunteer.
Best wishes,
Markus Triska
Am Donnerstag, 28. September 2006 22:53 schrieb Allison Randal:
> Leopold Toetsch wrote:
> > Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud:
> >> obj.'abc'() # call 'abc' method of obj
> >> obj.abc()# always the same as above
> >> obj.{ab
I need a volunteer write up the requirements for a mini transformation
language to use in the compiler tools. You wouldn't have to write up the
specification for the language, just what features we need. This will
help us plan what it's going to take to get from here to there, and give
us a way
I just got off the phone with Jonathan Worthington. At YAPC::EU he
agreed to draft a PDD for Parrot's bytecode file format. He has done a
fantastic job. He's checking it in now, so everyone will have a chance
to comment. The PDD incorporates a handful of important changes that
have been discuss
Leopold Toetsch wrote:
Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud:
obj.'abc'() # call 'abc' method of obj
obj.abc()# always the same as above
obj.{abc}() # call method indicated by abc symbol
This makes a lot of sen
Patrick R. Michaud wrote:
On Thu, Sep 28, 2006 at 11:59:52AM -0700, chromatic wrote:
On Thursday 28 September 2006 11:25, Allison Randal wrote:
obj.{bar}() # a string method name
obj.{$S1}()
I'm not sure what's meant by "a string method name" above, but
I'd look at it a
Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud:
I'm just quoting the relevant pieces here and add some comments below:
> obj.'abc'() # call 'abc' method of obj
> obj.abc() # always the same as above
> obj.{abc}() # call meth
On Thursday 28 September 2006 12:42, Patrick R. Michaud wrote:
> > To push a little more the other direction, is it possible for the
> > compiler to detect symbol and method name conflicts?
> > It's only the collision that makes a case ambiguous, right?
> I don't think that the compiler always
On Thu, Sep 28, 2006 at 11:59:52AM -0700, chromatic wrote:
> On Thursday 28 September 2006 11:25, Allison Randal wrote:
> > obj.{bar}() # a string method name
> > obj.{$S1}()
I'm not sure what's meant by "a string method name" above, but
I'd look at it as:
.local string
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate file - quite likely one heavily laced with
> POD).
That's a fine thing to want to do
Jonathan Lang wrote:
Aaron Sherman wrote:
TSa wrote:
> Miroslav Silovic wrote:
>> package Foo does FooMultiPrototypes {
>> ...
>> }
>
> I like this idea because it makes roles the central bearer of type
> information.
Type information is secondary to the proposal, but I'll run with what
you sai
On Thursday 28 September 2006 11:25, Allison Randal wrote:
> Exactly, change the most common case (of a method call by bare name) to
> be the unmarked case, and use some additional marking on the less common
> case of calling a method by a string name or method object. I wouldn't
> use '$' to mark
Aaron Sherman wrote:
TSa wrote:
> Miroslav Silovic wrote:
>> package Foo does FooMultiPrototypes {
>> ...
>> }
>
> I like this idea because it makes roles the central bearer of type
> information.
Type information is secondary to the proposal, but I'll run with what
you said.
This (the example,
Jonathan Scott Duff wrote:
To be on the safe side, method (and function) names *should* be quoted. I
don't think that this is inconsistent.
Is there a reason that you would want to conflate method names and
variables used as a method name? If not, why not change the syntax
slightly so that me
TSa wrote:
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe
that declarative requirements should go on roles. And then packages
could do them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the
A. Pagaltzis wrote:
I have the following code:
class MyStupidString {
method repeatit(Str $string, Int $repeat) {
say $string xx $repeat;
my $add = $string xx $repeat;
say $add;
}
};
my $obj = MyStupidString.new;
$obj.repeatit("---",1
Fagyal Csongor skribis 2006-09-28 15:11 (+0200):
>say $string xx $repeat;
List context.
>my $add = $string xx $repeat;
Item context, for a list repetition operator. Doesn't really make sense,
and I think a warning or error message would be more appropriate.
I thi
> I have the following code:
>
> class MyStupidString {
> method repeatit(Str $string, Int $repeat) {
> say $string xx $repeat;
> my $add = $string xx $repeat;
> say $add;
> }
>
> };
>
> my $obj = MyStupidString.new;
> $obj.repeatit
Hi,
I have the following code:
class MyStupidString {
method repeatit(Str $string, Int $repeat) {
say $string xx $repeat;
my $add = $string xx $repeat;
say $add;
}
};
my $obj = MyStupidString.new;
$obj.repeatit("---",10);
Interestin
HaloO,
Trey Harris wrote:
I would hate for Perl 6 to start using C or C in the
sort of ways that many languages abuse "Object" to get around the
restrictions of their type systems. I think that, as a rule, any
prototype encompassing all variants of a multi should not only
specify types big e
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe that
declarative requirements should go on roles. And then packages could do
them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bea
On Thu, Sep 28, 2006 at 09:36:13AM +0100, Nicholas Clark wrote:
>
> However, step 2 is easier for Perl because we're not trying to do portable
> bytecode. Some constants, (such as *most* of the socket constants, but I think
> not all) are defined in RFCs, so can be baked into bytecode at compile t
Am Donnerstag, 28. September 2006 12:47 schrieb Karl Forner:
> I suppose that again it is a trivial question, but I did not manage to find
> the answer by myself in the documentation.
> So I want for example to call diretly the "elements" method on a
> FixedBooleanArray
>
> I tried
>
>pmc.eleme
Aaron Sherman wrote:
I certainly hope not, as I agree with you! That's not the goal at all,
and in fact if that were a side effect, I would not want this to be
implemented. The idea of having types AT ALL for protos was something
that I threw in because it seemed to make sense at the end. The re
I suppose that again it is a trivial question, but I did not manage to find
the answer by myself in the documentation.
So I want for example to call diretly the "elements" method on a
FixedBooleanArray
I tried
pmc.elements()
pmc."elements"()
pmc._elements()
pmc.__elements()
But it did n
Am Donnerstag, 28. September 2006 01:30 schrieb Jonathan Worthington:
> Hi,
>
> Some first thoughts that come to mind after reading leo's two proposals.
> > +with new variants of the C opcode:
> > +
> > + addattribute cs, 'a', .DATATYPE_INT
> > + addattribute cs, 'b', .DATATYPE_CHAR
>
> Certainl
Author: leo
Date: Thu Sep 28 01:39:18 2006
New Revision: 14781
Modified:
trunk/docs/pdds/clip/pddXX_cstruct.pod
Log:
pddXX_cstruct - clarify a few items
Modified: trunk/docs/pdds/clip/pddXX_cstruct.pod
==
--- trunk/do
On Fri, Sep 08, 2006 at 12:38:39PM +0200, Leopold Toetsch wrote:
> Hi,
>
> typical socket ocde currently looks a bit unfriendly due to magic constants,
> e.g.
>
> socket sock, 2, 1, 6 # PF_INET, SOCK_STREAM, tcp
>
> I'd like to have symbolic constants for all that stuff:
>
> socke
39 matches
Mail list logo
