Jonathan Worthington jonathan-at-jnthn.net |Perl 6| wrote:
$x.nosuchmethod;
will give a compile-time error if nosuchmethod is not declared as
part of CGI::Simple.
Is this spec'd somewhere? I don't think we can statically know what
methods CGI::Simple will have at compile time. What if I do a "
John M. Dlugosz wrote:
> Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:
>
> > IIRC, the supertyping proposal involved being able to "anti-derive"
> > roles from existing roles or classes, working from subtypes to
> > supertypes (or from derived roles to base roles) instead of the other
> > way ar
Please review/apply patch attached.
Index: MANIFEST
===
--- MANIFEST(revision 27299)
+++ MANIFEST(working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools/dev/mk_manifest_and_skip.pl Fri May 2 18:05:05 200
> What's the point of omnipotence if you can't swoop down from the rafters
once
in a while and save your hero from almost certain peril?
To quote *Larry from "Time Bandits" - "er, something to do with free
will."
a
---
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voic
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:
IIRC, the supertyping proposal involved being able to "anti-derive"
roles from existing roles or classes, working from subtypes to
supertypes (or from derived roles to base roles) instead of the other
way around. The proposal got hung up on termin
On Friday 02 May 2008 16:07:56 John M. Dlugosz wrote:
> chromatic chromatic-at-wgz.org |Perl 6| wrote:
> Why is there any difference in declaring classes and roles if a class
> can be used as the target of either 'is' or 'does'?
You can't instantiate a role. You can instantiate a class.
When y
chromatic chromatic-at-wgz.org |Perl 6| wrote:
Do we face a similar rug-yanking situation with delegatee classes being
modified after delegate instantiation? I know there are some types of
auto-handling, but are they all automatic?
-- c
In the sense that the more detailed formal documen
Larry Wall larry-at-wall.org |Perl 6| wrote:
On Fri, May 02, 2008 at 12:22:00PM -0700, chromatic wrote:
: On Friday 02 May 2008 11:44:40 John M. Dlugosz wrote:
:
: > chromatic chromatic-at-wgz.org |Perl 6| wrote:
:
: > > All classes imply the existence of a role of the same name.
:
: > Please
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Would you be so kind to enlighten me what the type system is, if
not a type calculation overlaid over a value calculation?
Regards, TSa.
The other day I put it for those not following the scholarly stuff: The
questions of “can this substitute
Sex, 2008-05-02 às 15:32 +0200, TSa escreveu:
> Daniel Ruoso wrote:
> > I don't really see what this "is :strict" means in the runtime
> > environment. Perl 6 takes OO so deeply that even the type checking is
> > implemented as a cal to the object. There isn't really a way of asking
> > "are you tr
Larry Wall larry-at-wall.org |Perl 6| wrote:
If a role is derived from a class,
According to S12:
"A role may not inherit from a class..."
it must of necessity be a snapshot
of the class, because roles are immutable, while classes are not.
The only interesting question in my mind is whethe
John M. Dlugosz wrote:
Andy_Bach-at-wiwb.uscourts.gov |Perl 6| wrote:
in. Er, so would:
my CGI::Simple $x .= new;
my $y = CGI::Simple.new;
mean that:
$x $y
is not true? Or would there be a way to tell them apart, on a class
(?) level.
The actual dynamic type at run time of the values i
chromatic chromatic-at-wgz.org |Perl 6| wrote:
http://www.perlfoundation.org/perl6/index.cgi?perl_6_people
I could edit it into a Synopsis if you really want.
-- c
Or just explain the reasoning that's missing now.
Why is there any difference in declaring classes and roles if a class
can
Sex, 2008-05-02 às 21:22 +0200, TSa escreveu:
> Or do you mean backwards in the sense that the priority is with the
> object somehow?
In fact, it simply means that it's up to that object's metaobject to
answer that, and not to a supra-meta-model to be able to answer to all
of the possible metamod
Andy_Bach-at-wiwb.uscourts.gov |Perl 6| wrote:
in. Er, so would:
my CGI::Simple $x .= new;
my $y = CGI::Simple.new;
mean that:
$x $y
is not true? Or would there be a way to tell them apart, on a class (?)
level.
The actual dynamic type at run time of the values in $x and $y are both
Sex, 2008-05-02 às 21:49 +0200, TSa escreveu:
> Daniel Ruoso wrote:
> > In fact, it simply means that it's up to that object's metaobject to
> > answer that, and not to a supra-meta-model to be able to answer to all
> > of the possible metamodel implementations.
> Since all three forms are derived
Sex, 2008-05-02 às 18:55 +0200, TSa escreveu:
> For me, too. But note that we should keep does the ultimate
> type checker that first checks the declared presence of a role,
> then falls back to a declared class inheritance and then falls
> back to a declared emulation. What else should be in this
Sex, 2008-05-02 às 09:08 -0500, John M. Dlugosz escreveu:
> A syntax is needed for this express concept: "accept B as a substitute
> for A", without changing A.
Which I'm advocating as
class CGI::Simple realises CGI { ... }
or
CGI::Simple is also { realises CGI }
or even...
$c
John M. Dlugosz wrote:
> TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
> > Take e.g. my supertyping proposal. I guess it was regarded as
> > a curiosity rather than an innovative feature.
>
> Which idea was that? Maybe I already took the wind into account when I
> rounded up the ideas in need
John M. Dlugosz wrote:
chromatic chromatic-at-wgz.org |Perl 6| wrote:
All classes imply the existence of a role of the same name.
Please justify that.
A class is an defined, referenceable entity with a "signature" composed
of the bits visible to a particular caller. It is possible, by
d
On Friday 02 May 2008 13:11:55 Larry Wall wrote:
> On Fri, May 02, 2008 at 12:22:00PM -0700, chromatic wrote:
> : I could edit it into a Synopsis if you really want.
> Tweet! Foul on #17. Two shots!
What's the point of omnipotence if you can't swoop down from the rafters once
in a while and
On Friday 02 May 2008 12:48:43 Larry Wall wrote:
> On Fri, May 02, 2008 at 12:21:27PM -0700, chromatic wrote:
> : I'm not sure which is best. Snapshotting at the time of first
> : composition (or the first time someone says "Hey, I provide that other
> : class's role!") seems right though.
> Or
On Fri, May 02, 2008 at 12:22:00PM -0700, chromatic wrote:
: On Friday 02 May 2008 11:44:40 John M. Dlugosz wrote:
:
: > chromatic chromatic-at-wgz.org |Perl 6| wrote:
:
: > > All classes imply the existence of a role of the same name.
:
: > Please justify that.
:
: http://www.perlfoundation.or
HaloO,
Daniel Ruoso wrote:
In fact, it simply means that it's up to that object's metaobject to
answer that, and not to a supra-meta-model to be able to answer to all
of the possible metamodel implementations.
Since all three forms are derived from a programmer's declaration
involving names th
On Fri, May 02, 2008 at 12:21:27PM -0700, chromatic wrote:
: On Friday 02 May 2008 11:55:54 Larry Wall wrote:
: > The only interesting question in my mind is whether you can take
: > another snapshot and override the previous one somehow, or whether
: > such derived roles should version themselves
HaloO,
Daniel Ruoso wrote:
You're taking it backwards, it's not the type checker that is aware of
that, but each object's metamodel. The metamodel protocol is just the
"do you 'Dog'?" thing.
Backwards in the sequence of checks? That is we check emulation first,
then class inheritance and then
On Friday 02 May 2008 11:44:40 John M. Dlugosz wrote:
> chromatic chromatic-at-wgz.org |Perl 6| wrote:
> > All classes imply the existence of a role of the same name.
> Please justify that.
http://www.perlfoundation.org/perl6/index.cgi?perl_6_people
I could edit it into a Synopsis if you reall
On Friday 02 May 2008 11:55:54 Larry Wall wrote:
> On Fri, May 02, 2008 at 11:15:34AM -0700, chromatic wrote:
> : All classes imply the existence of a role of the same name.
> If a role is derived from a class, it must of necessity be a snapshot
> of the class, because roles are immutable, while
HaloO,
Larry Wall wrote:
I don't think most people want to think of functions as types--it just
clutters up the type namespace.
Which contradicts their first-class status.
They can already say:
sub mysubuser ( &f where &mysub.sig ) {...}
or some such to do explicit smartmatching agai
On Fri, May 02, 2008 at 11:15:34AM -0700, chromatic wrote:
: On Friday 02 May 2008 07:08:21 John M. Dlugosz wrote:
:
: > TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
:
: > > Then, since classes are open, the programmer can easily say
: > >
: > > CGI does CGI::Simple;
: >
: > That would be
:
mark.a.biggar-at-comcast.net |Perl 6| wrote:
For me, too. But note that we should keep does the ultimate
type checker that first checks the declared presence of a role,
then falls back to a declared class inheritance and then falls
back to a declared emulation. What else should be in this check
chromatic chromatic-at-wgz.org |Perl 6| wrote:
On Friday 02 May 2008 07:08:21 John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Then, since classes are open, the programmer can easily say
CGI does CGI::Simple;
That would be
class CGI is also { d
On Friday 02 May 2008 07:08:21 John M. Dlugosz wrote:
> TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
> > Then, since classes are open, the programmer can easily say
> >
> > CGI does CGI::Simple;
>
> That would be
>
> class CGI is also { does CGI::Simple }
>
> and means that CGI::Simple is
On Thu May 01 15:34:17 2008, [EMAIL PROTECTED] wrote:
> Coke,
>
> This has been come up a couple of times either on list or on #parrot.
> And the same question has been raised about config/auto/m4.pm.
>
> Other things being equal, I'm in favor of this. Hey! Two fewer config
> steps to have to
On Sun Aug 15 13:35:26 2004, coke wrote:
> Automate string vtable generation
>
> (From the TODO file)
This is a very old TODO with no information cut and pasted by yours
truly from the TODO file we used to have.
Anyone thinks it's worth doing (and can actually explain what it meant),
please spea
-- Original message --
From: TSa <[EMAIL PROTECTED]>
> HaloO,
>
> John M. Dlugosz wrote:
> >> Maybe we already have this--see "emulates" in S11.
> > Works for me.
>
> For me, too. But note that we should keep does the ultimate
> type checker that first checks the
On Fri, May 02, 2008 at 11:34:33AM +0200, TSa wrote:
> My idea is that foo:( Foo &f ) should mean the same as
> foo:( Foo $x ), that is the variables have to contain a
> value that does Foo.
No, I think &f should be treated more like @f and %f as a composite
object with a normal return type for th
HaloO,
John M. Dlugosz wrote:
C++ worked on that issue for years in committee. CLOS has decades of
hindsight. Proposing ranking rules is a challenge for another day, but
those are my source material thus far.
Hmm, C++ dispatch rules are rather trivial. From the static type of the
pointer an
HaloO,
John M. Dlugosz wrote:
Maybe we already have this--see "emulates" in S11.
Works for me.
For me, too. But note that we should keep does the ultimate
type checker that first checks the declared presence of a role,
then falls back to a declared class inheritance and then falls
back to a d
HaloO,
I wrote:
I'm actually not sure that you can have 'CGI does CGI::Simple', since
CGI::Simple is not a role...
An intermediate, anonymous class is a mere implementation detail ;)
Sorry I meant an anonymous role created from the definition of
CGI::simple. Assuming compatibility of CGI wit
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Where do you get the information from that the second is more
specific than the former? Consider
constant Num $c = 3; # Num here is funny
my Num $n = 3;
my Int $i = 3;
my Any $a = 3;
And now $i is more specific than
Larry Wall larry-at-wall.org |Perl 6| wrote:
On Fri, May 02, 2008 at 08:30:25AM -0500, John M. Dlugosz wrote:
I agree. If typing is turned on, you want errors if you pass the wrong
type. You have to explicitly declare that Bar is an acceptable substitute
for Foo.
Maybe we already ha
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:
Sex, 2008-05-02 às 09:08 -0500, John M. Dlugosz escreveu:
A syntax is needed for this express concept: "accept B as a substitute
for A", without changing A.
Which I'm advocating as
class CGI::Simple realises CGI { ... }
or
HaloO,
John M. Dlugosz wrote:
Larry Wall larry-at-wall.org |Perl 6| wrote:
I don't like using ::?CLASS for something that is not a compile-time
constant. ... we don't use ::?SELF anymore, but "self", because that
can vary in
meaning dynamically
OK, for some meaning of "constant". After al
On Fri, May 02, 2008 at 08:47:28AM -0500, John M. Dlugosz wrote:
> In Perl 6, within a signature
>
>sub foo ( &f:(Int-->Int) )
>sub foo ( Continuous &f )
>
> The latter says that &f is of type Continuous, not that the return type is
> Continuous. That is what you want, right? The latte
HaloO,
John M. Dlugosz wrote:
You want a way to declare the function to accept both lvalue and
non-lvalue items, and determine at run-time whether it can write back to
it.
Yes, but as a general feature. Any assignment checks the constraint
of the lvalue. A non-writeable lvalue is simply havin
On Fri, May 02, 2008 at 08:30:25AM -0500, John M. Dlugosz wrote:
> I agree. If typing is turned on, you want errors if you pass the wrong
> type. You have to explicitly declare that Bar is an acceptable substitute
> for Foo.
Maybe we already have this--see "emulates" in S11.
Larry
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Then, since classes are open, the programmer can easily say
CGI does CGI::Simple;
That would be
class CGI is also { does CGI::Simple }
and means that CGI::Simple is a role, meant to serve as an interface
specification. It's not, it is a
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Ohh, conceptually we should split the 'r' and 'w' in 'rw'.
The r part is for the value going in. The w part is conceptually
part of the *return* type of the function. The convenience for the
caller lies in the fact that she doesn't have to extract
Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote:
Implemented as:
method read ( --> Boolean ) { ... }
(How do I specify no args and a Boolean return type?)
Take your pick:
our Bool method read () { ... }
method read (-->Bool) { ... }
method read () of Bool { ... }
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
John M. Dlugosz wrote:
Hmm, I always had the impression of strong headwind.
How so?
Take e.g. my supertyping proposal. I guess it was regarded as
a curiosity rather than an innovative feature.
Regards, TSa.
Which idea was that? Mayb
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
sub graph ( &func where {.does: Continuous}, Num $from, Num $to )
{...}
sub square ( Num $x --> Num ) does Continuous { return $x * $x }
graph( &square, -10.0, 10.0 ); # type correct
The odd thing to me is that graph cannot be defined a
HaloO,
Daniel Ruoso wrote:
Not really... 'does' will try to compose the CGI::Simple methods to the
CGI class (although I think your example was supposed to be CGI::Simple
does CGI, but anyway).
Hardly. Ovid said that CGI has more functionality than CGI::Simple.
So the hope for CGI.does(CGI::Si
Qua, 2008-04-30 às 12:53 -0400, Brandon S. Allbery KF8NH escreveu:
> It occurs to me that this shouldn't be new keywords, but adverbs, i.e.
> ``is :strict Dog''.
I don't really see what this "is :strict" means in the runtime
environment. Perl 6 takes OO so deeply that even the type checking is
Sex, 2008-05-02 às 14:38 +0200, TSa escreveu:
> Ovid wrote:
> > However, the CGI/CGI::Simple example I posted earlier doesn't fulfill
> > this. CGI::Simple offers a subset of CGI.pm's functionality and it's
> > guaranteed to be identical
> Then, since classes are open, the programmer can easily s
HaloO,
Daniel Ruoso wrote:
I don't really see what this "is :strict" means in the runtime
environment. Perl 6 takes OO so deeply that even the type checking is
implemented as a cal to the object. There isn't really a way of asking
"are you trully really a Dog?", there's only "do you 'Dog'?".
S
chromatic chromatic-at-wgz.org |Perl 6| wrote:
If I tell the type system that Foo and Bar are equivalent, then they're
equivalent even if they have different internal structures and no other
relationship in an inheritance sense.
I agree. If typing is turned on, you want errors if you pa
Makefile dependencies were given an overhaul in the past few months;
this ticket appears to be resolved.
Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote:
However, the CGI/CGI::Simple example I posted earlier doesn't fulfill
this. CGI::Simple offers a subset of CGI.pm's functionality and it's
guaranteed to be identical (it doesn't have HTML generation
functionality and the procedural/OO
TSa schreef:
> Brandon S. Allbery:
>> It occurs to me that this shouldn't be new keywords, but adverbs,
>> i.e. ``is :strict Dog''.
>
> Great idea!
And it leaves room for ':stricter' and ':strictest'.
;)
--
Affijn, Ruud
"Gewoon is een tijger."
HaloO,
Ovid wrote:
However, the CGI/CGI::Simple example I posted earlier doesn't fulfill
this. CGI::Simple offers a subset of CGI.pm's functionality and it's
guaranteed to be identical
Then, since classes are open, the programmer can easily say
CGI does CGI::Simple;
and let go CGI instanc
HaloO,
John M. Dlugosz wrote:
But, I'm thinking along the lines of Pascal and C++. You can't pass a
non-lvalue "by reference", period. (5)++ is just plain wrong.
Hmm, I would like the error to show up *within* the body of ++. Your
idea is to statically derive the error from the 'is rw' trait
Got some off-line feedback from Alberto, resolved a small conflict, and
applied patch with minor revision in r27289.
--- "Brandon S. Allbery KF8NH" <[EMAIL PROTECTED]> wrote:
> > On a side note, I'd like to make a request of the Perl 6 community
> > with regard to coding style: could we please have adverbal names
> that
> > are, well, adverbs? "is :strict Dog" brings to my mind the English
>
> -ly suffixes eve
--- "John M. Dlugosz" <[EMAIL PROTECTED]> wrote:
> chromatic chromatic-at-wgz.org |Perl 6| wrote:
> > This is why roles-as-types is so important: type inferencers can't
> infer
> > allomorphism because allomorphism relies on explicitly-marked
> semantic
> > meanings.
> >
>
> What is your nom
--- chromatic <[EMAIL PROTECTED]> wrote:
> Given:
>
> my $result = $thingie.bark;
>
> ... where $thingie may be a Dog or $thingie may be a Tree, is "bark"
> a noun or a verb?
>
> Sure, it's a lousy example, but remember the immutable law of OO
> didactics:
> all examples must be terrible
HaloO,
Brandon S. Allbery KF8NH wrote:
I was guessing, I still haven't had a chance to mindmeld with all the
synopses. The point remains that this is not a new keyword but an
adverb modifying the existing keyword.
I fully agree. As an add on 'strict' is a very well established
concept elsewh
On 2008 May 2, at 5:50, TSa wrote:
Brandon S. Allbery KF8NH wrote:
It occurs to me that this shouldn't be new keywords, but adverbs,
i.e. ``is :strict Dog''.
Great idea! But aren't named args required to be after required ones?
I was guessing, I still haven't had a chance to mindmeld with
HaloO,
Brandon S. Allbery KF8NH wrote:
It occurs to me that this shouldn't be new keywords, but adverbs, i.e.
``is :strict Dog''.
Great idea! But aren't named args required to be after required ones?
That is we have "is Dog :strict"? I would actually like to relax the
syntax if that were possi
HaloO,
John M. Dlugosz wrote:
Hmm, I always had the impression of strong headwind.
How so?
Take e.g. my supertyping proposal. I guess it was regarded as
a curiosity rather than an innovative feature.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1
HaloO,
chromatic wrote:
What are marked semantic meanings?
Types. That is, in the context of "Dog", "bark" means "emit a sound". In the
context of "Tree", "bark" means "the outer skin".
Note that the only things that carry meaning in your other example
my $result = $thingie.bark;
are
# New Ticket Created by Alberto Simoes
# Please include the string: [perl #53610]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53610 >
---
osname= darwin
osvers= 9.1.0
arch= darwin-2level
cc= cc
---
Flags:
cate
On Thu, May 01, 2008 at 11:40:43PM -0700, chromatic wrote:
> When you try to invoke a sub that doesn't exist, Parrot currently gives the
> unhelpful error message "Null PMC access in invoke()". Sometimes you can
> figure out what's wrong given the backtrace. Often you can't.
Just a quick note
On Thursday 01 May 2008 06:35:12 John M. Dlugosz wrote:
> chromatic chromatic-at-wgz.org |Perl 6| wrote:
> > This is why roles-as-types is so important: type inferencers can't infer
> > allomorphism because allomorphism relies on explicitly-marked semantic
> > meanings.
> What is your nomenclatu
74 matches
Mail list logo
