On Wednesday 25 October 2006 03:04, Trey Harris wrote:
I'll let @Larry speak for @Larry, but at one point I was told that when
CArray or CHash appear in signatures, those are roles, not classes; if
you examined a particular Array or Hash, the class would be some
implementation of the Array or
In a message dated Sat, 28 Oct 2006, chromatic writes:
When you specify a type to constrain some operation, you specify that
the target entity must perform that role.
That statement is very concise and direct. If the fuzziness I observed
about the identity of the basic building block of type
In a message dated Sat, 28 Oct 2006, Trey Harris writes:
In a message dated Sat, 28 Oct 2006, chromatic writes:
When you specify a type to constrain some operation, you specify that the
target entity must perform that role.
That statement is very concise and direct. If the fuzziness I
My initial inclination is to say that where clauses in a signature
are only there for pattern matching, and do not modify the official
type of the parameter within the function body. However, on a subset
the where clause is there precisely to contribute to the typing,
so if you want the extra
On Thu, Oct 26, 2006 at 03:17:27PM +0200, TSa wrote:
: HaloO,
:
: I wrote:
: 2) We have AB and the A B juxtaposition to mean $_ ~~ A $_ ~~ B
:which is an intersection (sub)type of A and B.
:
: Is the AB form a legal alternative for the juxtaposition?
Not in a signature. It's ambiguous
Trey Harris wrote:
Trey Harris writes:
chromatic writes:
When you specify a type to constrain some operation, you specify that the
target entity must perform that role.
That statement is very concise and direct. If the fuzziness I observed about
the identity of the basic building block of
Larry Wall wrote:
But I'm still somewhat set against the notion of using logical ops to
do set theory. (Even if you put parens around them.)
Understandably so. Perhaps (u) and (n) would be better ASCII
equivalents for the union and intersection operators...
--
Jonathan Dataweaver Lang
Author: jonathan
Date: Sat Oct 28 09:59:25 2006
New Revision: 15037
Modified:
trunk/docs/pdds/clip/pdd17_basic_types.pod
Log:
Add two new reference PMCs to the Basic Types PDD.
Modified: trunk/docs/pdds/clip/pdd17_basic_types.pod
Hi,
At the moment, if you have some ParrotObject instance, say foo, and do
something like:
$S0 = foo
Then $S0 will contain the name of the class. This is BAD because it
means you can't overload what a class stringifies too! In fact, there is
a comment in the code saying that:
/*
=item
On Sat, Oct 28, 2006 at 06:50:05PM +0100, Jonathan Worthington wrote:
So, I want to get rid of this and allow this v-table method to just
dispatch to a user implementation or a fallback. But before I do that, I
wanted to check if anyone is relying on the behavior? I'd really rather
not
On Saturday 28 October 2006 09:15, Larry Wall wrote:
My initial inclination is to say that where clauses in a signature
are only there for pattern matching, and do not modify the official
type of the parameter within the function body. However, on a subset
the where clause is there precisely
Hi,
As of r15039, :vtable and :vtable(...) are now both implemented. See
example code at the end of this email.
As of now, please use this new syntax. I have left in support for the
old __-prefix lookup as plenty of old code is using it; please note
that if you have a :vtable(xxx) and a
# New Ticket Created by Jonathan Worthington
# Please include the string: [perl #40608]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40608
The following program segfaults Parrot:
.sub main
$P0 = new .Key
Jonathan Worthington wrote:
Tests and some extra error checking code to come.
Also now done. If you write one of:
.sub not_a_vtable_method :method :vtable
.sub badger :method :vtable(not_a_vtable_method)
It's a compiler error.
I'll leave this ticket open a few more days for comments, then if
From: Jonathan Worthington (via RT) [EMAIL PROTECTED]
Date: Sat, 28 Oct 2006 13:32:25 -0700
The following program segfaults Parrot:
.sub main
$P0 = new .Key
push $P0, test
push $P0, test
print not reached
.end
Which sucks. :-(
I don't
On Sat Oct 28 15:30:49 2006, rgrjr wrote:
I don't see a segfault in r15040 on x86 GNU/Linux, but it seems to be
using push_string(). Same error on r15009. What are you running?
Windows. And sorry, I stuffed up the example. It shoulda been:
.sub main
$P0 = new .Key
$P1 = new .String
Almost two weeks ago, I had what I thought was a clever idea for
eliminating the continuation barrier from action invocation: Simply
call the action using the original continuation instead of creating a
new RetContinuation. The original continuation, I reasoned, should be
re-entrant after
Steffen: Sorry, Didnt see all correspondence immediately, and hence
responded twice.
But here is an effort using Gtk2. It works.
Can anyone explain why the lines with .can, whilst the other syntaxes
dont work?
file Gtk2Helper.pm
package Gtk2Helper;
use Gtk2;
sub new_Window {
return
Patrick R. Michaud wrote:
I propose this is removed in a week, please respond if you'd have an
issue with that or think that's too short.
I think it's too long. :-)
Does anything fail if you eliminate it (e.g., via make tests)?
If no, then I think it's okay to eliminate, and we'll see
Bob Rogers wrote:
Almost two weeks ago, I had what I thought was a clever idea for
eliminating the continuation barrier from action invocation: Simply
call the action using the original continuation instead of creating a
new RetContinuation. The original continuation, I reasoned, should be
20 matches
Mail list logo
