So what's the rationale behind the latest changes? I thought p6
consistently regarded the sigil as part of the name; seems like that
should go for named parameters, too. In fact, sigils would seem to be
a good way to distinguish named parameters from pairs.
Alternatively, reserve either :k(v) or
I noticed that tr/// doesn't currently exist in pugs. I want to add a
test, but I'm not sure where it goes. My first instinct is to create
a new tr.t in operators/, but I could also see adding it to builtins,
or even to the trans test in string. So I thought I'd solicit
opinions before diving i
Perl6::Spec::Documentation is a draft spec for documentation formats for
use with Perl6.
My own reading of it is that POD still exists and is supported, while a
new wiki-like format "kwid" is added, and a framework for various
dialects is supported.
POD was successful for its simplicity. It was
From: Gerd Pokorra <[EMAIL PROTECTED]>
Date: Fri, 25 Aug 2006 20:06:17 +0200
Hello!
In my program code I have the following lines:
/* get properties */
PMC *context_pmc = $3->vtable->getprop(interpreter, $3,
string_from_cstring(interpreter, "context"
On 8/25/06, Michael Snoyman <[EMAIL PROTECTED]> wrote:
I asked this same question on perl6-users, but no one really seemed to have
a definitive answer, so please forgive me for reasking.
I was wondering how named arguments would work when parameters of different
types had the same name, ie sub f
On 8/25/06, Daniel Hulme <[EMAIL PROTECTED]> wrote:
That's because you're used to one way of thinking about class
inheritance: that the subclass can do everything that the superclass can
do, and more. In this scheme, you might have a Square class, with a
field representing its corner and another
On 8/25/06, Mark J. Reed <[EMAIL PROTECTED]> wrote:
Why not? Is it any weirder than simply changing that functionality
beyond recognition?
You can always fake removing functionality even if the language
doesn't actually support it.
Yes, yes, of course. That is not the issue. We are trying t
Done as dump_str() method to Match objects, r14306.
Thanks!
Pm
On Fri, Aug 25, 2006 at 01:25:23PM -0700, Trey Harris wrote:
: I think Larry nailed it with his observation about the difference between
: class and role and trait. 'Constant' is a trait of another type, not a
: type into itself.
Hmm, well, there are several hands to be waved here. First, ther
On Fri, Aug 25, 2006 at 02:04:01PM -0700, Trey Harris wrote:
: In any case, Larry's settled this issue.
Nah, I just handwaved it harder. :)
Larry
In a message dated Fri, 25 Aug 2006, Juerd writes:
Trey Harris skribis 2006-08-25 13:26 (-0700):
Explain to me how "nontraditional" DBC might work in an internally
consistent way. Otherwise, this is hand-waving. :-)
Perl *is* hand-waving.
Yeah, but hand-waving on how it manages the behavio
In a message dated Fri, 25 Aug 2006, Daniel Hulme writes:
If "changing that functionality beyond recognition" means changing its
external behavior (as opposed to its internal behavior) so that it
acts differently from what the superclass had promised to do, then
no, it's not any weirder--but I
Trey Harris skribis 2006-08-25 13:26 (-0700):
> Explain to me how "nontraditional" DBC might work in an internally
> consistent way. Otherwise, this is hand-waving. :-)
Perl *is* hand-waving.
In a message dated Fri, 25 Aug 2006, Juerd writes:
Trey Harris skribis 2006-08-25 11:33 (-0700):
Ok... same thing from a DBC perspective. Subclasses can add functionality
(by AND'ing postconditions), or remove constraints (by OR'ing
preconditions), but they can't traditionally remove functiona
In a message dated Fri, 25 Aug 2006, Mark J. Reed writes:
OK, I admit I wasn't thinking about things from a DBC perspective, and
misunderstood "DBC" to be a reference to some database module. I here
am new and I didn't have context. My bad.
But if we're talking design-by-contract, I don't see
Trey Harris skribis 2006-08-25 11:33 (-0700):
> Ok... same thing from a DBC perspective. Subclasses can add functionality
> (by AND'ing postconditions), or remove constraints (by OR'ing
> preconditions), but they can't traditionally remove functionality or add
> constraints. I just want to rea
On Fri, Aug 25, 2006 at 03:32:12PM -0400, Will Coleda wrote:
> What about 'say'? It's a method, not an opcode, and:
> say $S0
> works just fine.
Well, 'say' is a parrotio METHOD, not a String METHOD:
METHOD INTVAL say(STRING *s)
so the SELF is an io PMC and nothing is hard. Expressing to_
> If "changing that functionality beyond recognition" means changing its
> external behavior (as opposed to its internal behavior) so that it
> acts differently from what the superclass had promised to do, then
> no, it's not any weirder--but I can't figure out how the contract
> would work, eith
On 8/25/06, Mark J. Reed <[EMAIL PROTECTED]> wrote:
I here am new and I didn't have context.
Well, technically, I here am not new; I've been here since before Apoc
1. But I hadn't been paying close attention for a while until
recently. :) Either way, I didn't get the ref.
--
Mark J. Reed <[
OK, I admit I wasn't thinking about things from a DBC perspective, and
misunderstood "DBC" to be a reference to some database module. I here
am new and I didn't have context. My bad.
But if we're talking design-by-contract, I don't see how "Array is
Array::Const" can work, either, since I consi
On Fri, Aug 25, 2006 at 12:38:33PM -0700, Trey Harris wrote:
: But in order to allow that choice, the language has to impose some
: groundrules for everyone. strict couldn't exist in Perl 5 if lexicals
: could autovivify. And--*by my understanding of DBC*--subclasses can't
: remove promised fu
On 8/25/06, Will Coleda <[EMAIL PROTECTED]> wrote:
What about 'say'? It's a method, not an opcode, and:
say $S0
works just fine.
but C does *not* work.
i find that annoying.
either make the syntax for methods different than ops (eg C<$S0.say()>)
or make C an opcode,
or dodge the syntax issue
On 8/24/06, Audrey Tang <[EMAIL PROTECTED]> wrote:
Mark, can you add a test to t/statements/for.t? A commit bit is on
its way to your inbox. :-)
Done. Tests 37 (implicit "rw $_") and 38 (explicit "-> $x is rw")
add to for.t as of r12968.
--
Mark J. Reed <[EMAIL PROTECTED]>
In a message dated Fri, 25 Aug 2006, Mark J. Reed writes:
On 8/25/06, Trey Harris <[EMAIL PROTECTED]> wrote:
> subclasses can remove functionality as well as adding it
Can someone suggest some reading I can do to understand how that works?
I can't wrap my head around the idea of subclasses r
What about 'say'? It's a method, not an opcode, and:
say $S0
works just fine.
I don't think there's *a priori* a problem to implicitly upgrade
something to a PMC to perform a non JIT-able task on it. I do think
pulling too hard at this thread might require a closer look at what's
current
Author: larry
Date: Fri Aug 25 12:28:00 2006
New Revision: 11421
Modified:
doc/trunk/design/syn/S06.pod
Log:
Discussed relationship of "is" syntax to adverb syntax and type syntax.
Nailed down some (hopefully) sane default behaviors for equiv and assoc.
Modified: doc/trunk/design/syn/S06.pod
(For those not watching CVS, Leo's just added a METHOD to_int() to String.)
Seems like this is the kind of thing that needs to have a common subroutine
in the C source so it can be used elsewhere, and an opcode so it's usable
with an S register. And once you've done that, the METHOD becomes redun
Hello!
In my program code I have the following lines:
/* get properties */
PMC *context_pmc = $3->vtable->getprop(interpreter, $3,
string_from_cstring(interpreter, "context", 7));
INTVAL i_type = context_pmc->vtable->type(interpreter, context_pmc);
This works fine, i
> Does this mean you can't write
>
>class Super { method something { ... } }
>
>sub foo (Super $bar) { $bar.something() }
>
> and expect foo($obj) to work, because $obj might be:
>
>class Sub is Super { # remove .something--how does that happen? }
>
>foo($obj); # Boom!?
>
> So what
On 8/25/06, Trey Harris <[EMAIL PROTECTED]> wrote:
> subclasses can remove functionality as well as adding it
Can someone suggest some reading I can do to understand how that works?
I can't wrap my head around the idea of subclasses removing functionality.
Why not? Is it any weirder than si
In a message dated Fri, 25 Aug 2006, jerry gay writes:
perhaps trey meant "subclasses can add constraints as well as
functionality" instead of "subclasses can remove functionality as well
as adding it."
just a guess.
~jerry
Ok... same thing from a DBC perspective. Subclasses can add functiona
On 8/25/06, Trey Harris <[EMAIL PROTECTED]> wrote:
In a message dated Fri, 25 Aug 2006, Mark J. Reed writes:
> I think the justification for Luke's POV is the number of operations
> each class provides. But my perspective agrees with Juerd -
> subclasses can remove functionality as well as addi
In a message dated Fri, 25 Aug 2006, Mark J. Reed writes:
I think the justification for Luke's POV is the number of operations
each class provides. But my perspective agrees with Juerd -
subclasses can remove functionality as well as adding it, and I
definitely view "constant" as an add-on modi
I asked this same question on perl6-users, but no one really seemed to have
a definitive answer, so please forgive me for reasking.
I was wondering how named arguments would work when parameters of different
types had the same name, ie sub foo($bar, @bar, &bar) {...}. I wrote a
little script to
On Fri, Aug 25, 2006 at 08:40:59AM -0400, Mark J. Reed wrote:
: On 8/25/06, Juerd <[EMAIL PROTECTED]> wrote:
: >You define in terms of functionality, but don't provide an explanation
: >for the chosen point of view. One could say that constant arrays protect
: >against
: >modifications, which nor
Thanks!
On 8/25/06, Will Coleda <[EMAIL PROTECTED]> wrote:
I know C++ is needed for linking because of ICU. I can't address your
concerns about using it "for all the linking" though.
Whatever the actual program doing the linking is should still respect
whatever env vars control its behavior, bu
I know C++ is needed for linking because of ICU. I can't address your
concerns about using it "for all the linking" though.
Whatever the actual program doing the linking is should still respect
whatever env vars control its behavior, but you can override all
these settings via arguments to
I'm trying to build parrot on OS X 10.3. It gets as afar as
"Determining if your C compiler is actually gcc..." and then fails a
link test. It turns out that it's failing because it is trying to use
"c++" to do the linking.
Any idea why? It's using $link, not $cxx, and I haven't found an
assig
On Wed, Aug 23, 2006 at 04:10:32PM -0700, Larry Wall wrote:
> Yes, that should work eventually, given that hypers are supposed to stop
> after the longest *finite* sequence. In theory you could even say
>
> my %trans = ('a'..*) »=>« ('?' xx *);
>
> but we haven't tried to define what the sem
On 8/25/06, Juerd <[EMAIL PROTECTED]> wrote:
You define in terms of functionality, but don't provide an explanation
for the chosen point of view. One could say that constant arrays protect
against
modifications, which normal arrays don't. Hence, constant arrays do *more*.
I think the justific
Luke Palmer skribis 2006-08-24 23:57 (-0600):
> Let's say our arrays are simple, for argument's sake: With a constant
> array, you can:
> * get its length
> * get the value of an element at an index
> With an array, you can:
> * get its length
> * get the value of an element at an index
>
41 matches
Mail list logo
