Nathan Wiger wrote:
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
def
All~
I am near boston so worst case senario I can take it. But I would
prefer not to if another option is there.
Matt
On 4/25/05, Bob Rogers <[EMAIL PROTECTED]> wrote:
>From: Nicholas Clark <[EMAIL PROTECTED]>
>Date: Mon, 25 Apr 2005 10:37:07 +0100
>
>On Sun, Apr 24, 2005 at 09:46:
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 25 Apr 2005 17:41:49 +0200
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> . . .
> Others relate to "this PMC is going away". And as morph involves changing
> the internal memory layout of a PMC without it actually going away, only
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 25 Apr 2005 08:59:05 +0200
Bob Rogers <[EMAIL PROTECTED]> wrote:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>It probably just depends on the implementation of Perl5 references.
> Hmm. I'm probably missing something (
The garbage collection issues that were stopping ParTcl's test suite (FYI,
*not* Tcl's test suite) from working seem to be gone now!
I've gotten passing reports on all tests (that aren't TODO'd) from OS X,
FreeBSD, and Linux.
ParTcl is part of the parrot svn repository. See:
http://www.parrotcode
And I just can't seem to get up the enthusiasm to do it. The primary
problem is its testing against a very old version of Date::ICal and a lot
of the examples no longer work. There's lots of secondary problems
resulting from it having been written almost four years ago.
So if anyone's feeling
From: Nicholas Clark <[EMAIL PROTECTED]>
Date: Mon, 25 Apr 2005 10:37:07 +0100
On Sun, Apr 24, 2005 at 09:46:03PM -0400, Bob Rogers wrote:
> available; if the money were forthcoming, it could even run Tru64. Is
> the Parrot project interested in using such a box? If so, under wha
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).
Then I su
On Mon, 25 Apr 2005, Ron Blaschke wrote:
> Monday, April 25, 2005, 5:52:42 PM, jerry gay via RT wrote:
> > On 4/23/05, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> >> IMHO, compilation and linkage feels quite messy as a whole. I am not
> >> sure how to get the current link command to look like the o
Nathan Wiger writes:
> Paul Seamons wrote:
> >>> meth foo {
> >>>$_.meth; # defaults to the invocant
> >>>.meth; # operates on $_ which defaults to the invocant
> >>>$^.meth; # is the invocant
> >>>$^1.meth; # is the first invocant
> >>>$^2.meth; # is the second invocant
> >>
>
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
> My point is simply that we pick one or the other, instead of
> both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).
Juerd
--
http:/
On Mon, 2005-04-25 at 08:43, Luke Palmer wrote:
> Nope. It seems that pugs is considering $tmp and the implicit usage of
> $_ to specify two different parameters to the block. In fact, there's
> only one: $tmp, and it is aliased to $_.
Ah, and this was my problem too. Thanks, Luke or whoever fi
On Mon, 2005-04-25 at 13:05, Aaron Sherman wrote:
> I'm encountering a bug in the execution of a for loop like so:
Mysteriously fixed by an update later in the day, thanks! ;-)
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get
Juerd writes:
> (While typing this, I realised that there may be, in English, a
> difference between subject and topic. If that's true, please educate
> me.)
Well, from a non-linguist's point of view, they are two very different
things.
My brother asked me to take out the trash. I asked him
Paul Seamons wrote:
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
I'm starting to get confused at the "need" for all these sp
Juerd writes:
> Which assumptions are wrong?
>
> foo (3) + 4;# foo(7)
> foo(3) + 4; # foo(3)
> foo.(3) + 4;# foo(3)
> foo .(3) + 4; # foo(3)
>
> $foo (3) + 4; # syntax error
> $foo(3) + 4;# $foo(3)
> $foo.(3) + 4; # $foo(3)
> $foo .(3) + 4
Juerd writes:
> Assuming the following are true:
>
> A: "if" is now a normal function
Almost. It's a statement-level form, which looks like a normal function
except for the statement: prepended on its name. Such constructs (which
include for, while, the whole gang) have a few special proper
On Tue, Apr 26, 2005 at 03:33:44AM +0800, Autrijus Tang wrote:
> Another quick check on expression context for indexed expressions.
> Please sanity-check the return value of want() below:
>
> @x[0] = want(); # scalar context
> @x[want()] = $_; # scalar context
> @x[want()] = @_; #
Rod Adams skribis 2005-04-25 14:37 (-0500):
> There will always be various control constructs that cannot be written
> as an equivalent function. Otherwise, there is no way to write the
> higher level ones.
Not a problem, because we're using something to bootstrap, and the perl
6 you'll be using
Juerd wrote:
Assuming the following are true:
A: "if" is now a normal function
B: "foo() + 3" is (foo) + 3, foo doesn't get 3.
Then does that mean we're stuck with:
C: "if($foo) { say 'foo' }" being a syntax error?
I currently think A is wrong. Am I right?
Juerd
There will always be var
Another quick check on expression context for indexed expressions.
Please sanity-check the return value of want() below:
@x[0] = want(); # scalar context
@x[want()] = $_; # scalar context
@x[want()] = @_; # scalar context
@x[0,] = want(); # list context
@x[want(),] = $_; #
Which assumptions are wrong?
foo (3) + 4;# foo(7)
foo(3) + 4; # foo(3)
foo.(3) + 4;# foo(3)
foo .(3) + 4; # foo(3)
$foo (3) + 4; # syntax error
$foo(3) + 4;# $foo(3)
$foo.(3) + 4; # $foo(3)
$foo .(3) + 4; # $foo(3)
$o.m (3) + 4; #
Paul Seamons skribis 2005-04-25 13:02 (-0600):
> method foo ($self:) {
>return grep { $self.is_ok( .value ) } $self.info_pairs;
># .value called on the topic $_
> }
I think that to be fair, you have to leave out the redundant $self
there.
return grep { $self.is_ok( .value ) } .info_pa
Assuming the following are true:
A: "if" is now a normal function
B: "foo() + 3" is (foo) + 3, foo doesn't get 3.
Then does that mean we're stuck with:
C: "if($foo) { say 'foo' }" being a syntax error?
I currently think A is wrong. Am I right?
Juerd
--
http://convolution.nl/maak
> > meth foo {
> > $_.meth; # defaults to the invocant
> > .meth; # operates on $_ which defaults to the invocant
> > $^.meth; # is the invocant
> > $^1.meth; # is the first invocant
> > $^2.meth; # is the second invocant
>
> I'm starting to get confused at the "need" fo
Paul Seamons wrote:
So then, to get back to the invocant... I can't say that I liked many of the
proposals. The one that seemed to have merit though was $^. I'd propose the
following.
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invo
I think it would be great to be able to use a junction with use:
use strict & warnings;
A disjunction could mean any of the listed modules suffices. This comes
in handy when you code something that will work with any of three XML
parsers. Although because ordering matters, the // operator is
Monday, April 25, 2005, 5:52:42 PM, jerry gay via RT wrote:
> On 4/23/05, Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> IMHO, compilation and linkage feels quite messy as a whole. I am not
>> sure how to get the current link command to look like the one above,
>> without doing something akin to F
>>
Thomas Sandlaß skribis 2005-04-25 19:13 (+0200):
> I think your basic error in perception is that $_ is a runtime variable
> while the invocant(s) are more a design time assumption of what the
> method is working on.
$_ is the *topic*. Its role in design and thinking is gigantic.
The funny thing
Thomas Sandlaß skribis 2005-04-25 19:30 (+0200):
> .method sqrt: # $?SELF.method( $_.sqrt() )
I don't like your solution simply because I don't like indirect object
calls. I avoid to and want to continue to avoid them, and do want a
short way for $_. Besides that, I think whatever default
Paul Seamons skribis 2005-04-25 11:12 (-0600):
> By this reasoning - why have a shortcut to any of the invocants at all? This
> thread has headed in the direction of finding a way to figure out how to call
> methods on the invocant without using the signatures name. On a method call
> without
Paul Seamons wrote:
method foo {
for 1 .. 10 {
$^.method(.sqrt);
}
}
I would make that:
method foo
{
for 1 .. 10
{
.method sqrt: # $?SELF.method( $_.sqrt() )
}
}
Then usage is:
my $x = "blubb";
$x.foo; # $x.method( sqrt(1) ) .. $x.method( sqrt(10) )
Iff "blubb" has go
Paul Seamons wrote:
> Yes, I know there "can be" a "way back." In this thread, none of the
> examples give one using existing Perl 6 syntax. They are all proposing new
> ways. This is one more.
Sorry if this sounded brash. I have a habit of not figuring out that there is
more of the message to
Juerd wrote:
However, the discussion is about changing these simple, clear, and
useful rules to a more complex situation of choosing a default based on
what the default will be used for, making the default for methods the
invocant rather than $_. I hate those plans and would love to see the
current
> What is this "way back" you repeatedly mention?
>
> If it is having a name for the invocant, then there has always been one:
>
> method foo ($self:) {
> for (1..10) {
> $self.method(.sqrt)
> }
> }
>
> Or, well, two:
>
> method foo {
> my $self := $_
David Storrs skribis 2005-04-25 10:00 (-0700):
> Cool. But that seems to turn off all warnings during the compilation
> of the expression--I only want to get rid of the (expected)
> 'uninitialized' warning. Will there be a way to do finer-grained
> control?
compile("no warnings :undef; $exp
I'm encountering a bug in the execution of a for loop like so:
$ ./pugs x.p6
Original array: 123456
Implicit assignment to $_:
1
2
3
4
5
6
Explicit assignment to $_:
1
3
5
$ cat
On Mon, Apr 25, 2005 at 05:18:11AM -0600, Luke Palmer wrote:
> David Storrs writes:
> > sub foo {
> > my ($x,$y) = @_;
> > note("Entering frobnitz(). params: '$x', '$y'");
> > ...
> > }
> > This, of course, throws an 'uninitialized value in concatenation or
> > string' warni
Steven Philip Schubiger skribis 2005-04-25 18:44 (+0200):
> I confess, it's likely a bad habit, to coin it "array context" on
> p6l, although it refers to Perl 5, where it I have seen it more than
> once - perhaps, overly abused too.
That's old Perl5-ese. There was a big jargon change when people
Paul Seamons skribis 2005-04-25 9:52 (-0600):
> a way back
What is this "way back" you repeatedly mention?
If it is having a name for the invocant, then there has always been one:
method foo ($self:) {
for (1..10) {
$self.method(.sqrt)
}
}
Or, well, two:
On 25 Apr, Juerd wrote:
: I don't know how it's called on other levels, but we're still calling
: that list|slurpy|plural context. "array context" looks too much like
: "Array context", which is something else.
I confess, it's likely a bad habit, to coin it "array context" on
p6l, although it ref
Larry Wall wrote:
Depends on whether the user is actually expecting equal MMD there,
or tie-breaking between multi methods within the particular class.
My gut-level feeling is that they expect the latter.
With combined .method and method: syntax we also could have a nice
top priority or innermost s
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 24, 2005 at 09:25:43AM +0200, Leopold Toetsch wrote:
>> Ok, that can be solved by calling A.destroy() first. But what happens,
>> if A has finalizers, which may depend on other finalizers?
> Doesn't this mean that there's a split here in "fi
I think the original (or the "latest original") reason for breaking .meth from
meaning $_.meth is that $_ is transitory and there was no way back to the
nameless invocant. In the absense of having a way back, I and others
strongly advocated breaking the link. I think we hated to do it.
Now i
On 4/23/05, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> 1) F uses C, which is named C<_vsnprintf> on
> MSWin32. A simple hack would be to add the following to F.
>
>#ifdef WIN32
># define vsnprintf _vsnprintf
>#endif
confirmed here on VS.NET 2003 (aka MSVC 7.1), although this is not
n
Brad Bowman wrote:
my $a = rand(); # runtime variable
my $result = one(any( sub { $a+1}, sub { $a-1} ),sub { $a+3 }).();
say $result.perl;
If $a was 0.5 I'd guess
$result = one(any(1.5, 0.5), 3.5)
is this the case?
IIRC the .perl method produces a string from which an equal value
can be re
Sorry, I think I had been prematurely excited by all the "make test"
OK's I had seen while installing...
I'm now going through the test suite and seeing all the ":todo(1)"s !
I'll check the test suite first next time, before I ask a question
about unimplemented features.
Carl
running pugs 6.2.1
If I run the code below in a file "test.pugs" as
> pugs -c test.pugs
I get "test.pugs syntax OK", which is fine.
### CODE ###
module MyFoo-0.01;
class MyFoo;
multi method new (Class $class: $date) {
return $class.new({date => $date})
};
method foo {
#whatever
On Sun, Apr 24, 2005 at 09:25:43AM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > When writing morph methods for PMC classes, am I right in thinking that if
> > In effect morph has to be friends of both A and B, because it needs to break
> > encapsulation?
>
> Yep.
Larry Wall wrote:
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo(). I wish there were more keys on my keyboard...
What is the status of my proposal to reserve the indirect object syntax
for calls on $_ and the .method form for the invocant in (single
Kiran Kumar writes:
> Hi ,
> Is this behaviour correct when i print $_ ? ..
>
>
> #!/usr/bin/pugs
> use v6;
>
> for (0 .. 8) -> $tmp
> {
> say " tmp is $tmp Spcl is $_ \n";
> }
>
> tmp is 0 Spcl is 1
>
> tmp is 2 Spcl is 3
>
> tmp is 4 Spcl is 5
>
> tmp is 6 Spcl is 7
>
> tm
I forwarded the Common LISP notice to a friend of mine who works on
CMUCL internals, and he suggested:
"[they should think about starting with] CMUCL and retarget
[sic] it for the new VM. That way he gets all the type inference
for free [which would increase performance]"
Hi ,
Is this behaviour correct when i print $_ ? ..
#!/usr/bin/pugs
use v6;
for (0 .. 8) -> $tmp
{
say "tmp is $tmp \n";
}
for (0 .. 8) -> $tmp
{
say " tmp is $tmp Spcl is $_ \n";
}
Output is
tmp is 0
tmp is 1
tmp is 2
tmp is 3
tmp is 4
tmp is 5
tmp is 6
tmp is 7
David Storrs writes:
> I image we've all written logging code that looks something like this
> (Perl5 syntax):
>
> sub foo {
> my ($x,$y) = @_;
> note("Entering frobnitz(). params: '$x', '$y'");
> ...
> }
>
> This, of course, throws an 'uninitialized value in concatenation
Running winXP sp2, ghc 6.4, MS nmake 1.50
The main pugs tests passed ok, but a further test (I think in CGI)
hung indefinitely.
(Well, I say indefinitely, but I ctrl-c'd it after about 5 minutes at test 3/21.
Below is the relevant output.
-
t/var/type..ok
All
On Sun, Apr 24, 2005 at 09:46:03PM -0400, Bob Rogers wrote:
> available; if the money were forthcoming, it could even run Tru64. Is
> the Parrot project interested in using such a box? If so, under what
> OS? And where/how should such a box be hosted/administered?
Quite possibly, although I pe
On Sun, Apr 24, 2005 at 08:52:55AM +0200, Leopold Toetsch wrote:
> Yep. That's true. Fixed. BTW did you come along that by using this
> function or just by reading the code?
Just reading the code, although not very systematically. I was trying to
figure out how morph worked.
Nicholas Clark
Steven Philip Schubiger skribis 2005-04-25 5:41 (+0200):
> That was to be expected, as it's no language-design specific issue,
> and therefore, unsuitable for p6l.
> : print ++$i, $i++; # 3 2
> You're misleaded here, by thinking, scalar context is being enforced,
> which is not the case; the resul
On Sun, Apr 24, 2005 at 04:39:04PM -0700, Larry Wall wrote:
> : Larry suggested that to keep it from being collapsed, we somehow
> : augment toplevel AST:
> :
> : map { $_ => $_; } @foo;
> : map { +($_ => $_) } @foo;
>
> Uh, I'm not sure what + would return for a Pair, but I'm pretty sure
That puts my mind at ease!
Many thanks,
Carl
On 4/25/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Carl Franks writes:
> > Will it be valid to pass a hash to a subroutine expecting named
> > params, if the hash keys match the names?
> >
> > sub do_this (+$foo, +$bar) {
> > # whatever
> > }
> >
Carl Franks writes:
> Will it be valid to pass a hash to a subroutine expecting named
> params, if the hash keys match the names?
>
> sub do_this (+$foo, +$bar) {
> # whatever
> }
>
> %arg = (
> :foo,
> :bar,
> );
>
> do_this(*%arg);
Yep, and that's exactly how you do it, too. I believe
Christoph Otto <[EMAIL PROTECTED]> wrote:
> This patch fills in two holes in pdd04 (internal data types). The
> information came from include/parrot/pobj.h.
> Christoph Otto
Thanks, applied.
leo
François" PERRAD <[EMAIL PROTECTED]> wrote:
> This patch allows the inclusion of ICU DLL in the installer.
Thanks, applied.
leo
Will it be valid to pass a hash to a subroutine expecting named
params, if the hash keys match the names?
sub do_this (+$foo, +$bar) {
# whatever
}
%arg = (
:foo,
:bar,
);
do_this(*%arg);
I use this technique a lot, and it would be unfortunate to miss out on
the advantages of subroutine s
On 21 Apr, fayland wrote:
: It has been published at perl6.language, but have no reply.
That was to be expected, as it's no language-design specific issue,
and therefore, unsuitable for p6l.
: In perl v5.8.6 built for MSWin32-x86-multi-thread:
:
: my $i = 1;
: print $i++, ++$i; # 1 3
: my $i =
Bob Rogers <[EMAIL PROTECTED]> wrote:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>It probably just depends on the implementation of Perl5 references.
> Hmm. I'm probably missing something (it wouldn't be a first), but if
> the reference points to $a itself rather than the PMC to which $a
66 matches
Mail list logo
