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 nomenclature
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 the
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,
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
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
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
--- 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.
As a
--- 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 nomenclature here?
--- 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 everywhere
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
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.
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
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
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'?.
Sorry,
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 say
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
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
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 as
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?
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:
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
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
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
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
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 latter would be
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
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
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
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
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 all
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
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 the
-- 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 declared
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 a role,
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 {
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
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
:
:
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
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
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 really
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 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 so
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
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 maybe
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
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
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 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 from a
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 whatever the compare class operater is $y
is not true? Or would there be a way to tell them apart, on a class (?)
level.
The actual dynamic type at run
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...
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
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
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 whatever the compare class operater is $y
is not true? Or would there be a way to tell them apart, on a class
(?) level.
The actual
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 whether
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
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
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
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 you
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
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]
Voice:
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 around. The
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
62 matches
Mail list logo
