Larry Wall wrote:
Roles cannot be derived from, so they're always final in that sense.
We should probably consider them closed by default as well, or at least
closed after first use. If a role specifies implementation, it's always
default implementation, so overriding implementation always occurs
HaloO Larry,
you wrote:
On Thu, Mar 31, 2005 at 06:35:06PM +0200, Thomas Sandlaß wrote:
: Is typing optional in the sense that it is no syntax error but
: otherwise ignored? To me this is pain but no gain :(
Well, you guys keep ignoring the answer. Let me put it a bit more
mathematically. The
On Tue, Apr 05, 2005 at 04:00:09PM +0200, Thomas Sandlaß wrote:
: Larry Wall wrote:
: Roles cannot be derived from, so they're always final in that sense.
: We should probably consider them closed by default as well, or at least
: closed after first use. If a role specifies implementation, it's
On Thu, Mar 31, 2005 at 01:11:37PM -0500, Aaron Sherman wrote:
: If you declare a variable to be of a type (let's even say a class to be
: specific), then you have hinted to the compiler as to the nature of that
: variable, but nothing is certain.
:
: That is to say that the compiler cannot:
:
:
Thomas Sandla wrote:
Int|Str : Str Str : Int|Str Int|Str : Int Int : Int|Str
holds.
Uhh, I hardly believe that it was me writing that last night!
Int|Str is of course a proper supertype of Int and Str respectively.
So we really have: Str : Str|Int Int : Str|Int, which warps us
back to the
[EMAIL PROTECTED] wrote:
Er, isn't that not just the wrong way around? The point is to do the
bookkeeping that an object is needed that does .meth() and that it
is stored in $a, and to complain when that is not the case when it
should be. The earlier the better.
I don't understand why writing 'my
Miroslav Silovic wrote:
Remember, you can even change the class of instanced objects using
'does' (or 'but', but it'll at least copy the object). And as the
example above shows, this is statically intractable - it can happen in a
sub in a different autoloaded module.
Sorry this is a well
On Thu, Mar 31, 2005 at 06:35:06PM +0200, Thomas Sandlaß wrote:
: Is typing optional in the sense that it is no syntax error but
: otherwise ignored? To me this is pain but no gain :(
Well, you guys keep ignoring the answer. Let me put it a bit more
mathematically. The information in
my X
On Thu, 2005-03-31 at 11:51, Larry Wall wrote:
my X $a;
is *necessary* but not *sufficient* to do method existence testing in
standard Perl 6 at compile time. You can do it IFF you have the class
information AND the classes are willing to cooperate in your scheme.
In the current
On Thu, 2005-03-31 at 13:11 -0500, Aaron Sherman wrote:
I can't answer most of these well. However...
One additional wrinkle is that *anyone* is allowed to declare a
class non-cooperative (open or non-final) during *any* part of the
compilation
... even after it is declared final?
I
I'm no expert, but here's my take:
On Thu, Mar 31, 2005 at 01:11:37PM -0500, Aaron Sherman wrote:
If you declare a variable to be of a type (let's even say a class to be
specific), then you have hinted to the compiler as to the nature of that
variable, but nothing is certain.
That is to say
On Thu, 2005-03-31 at 15:25, chromatic wrote:
On Thu, 2005-03-31 at 13:11 -0500, Aaron Sherman wrote:
I can't answer most of these well. However...
Open-Closed is a great idea until the most natural and easiest way to do
something is to to redefine a little bit of the world.
You seemed
Luke Palmer wrote:
Unless the caller can't see the signature, as is the case with methods.
[..]
Again, this can't be done unless you know the signature. And in fact,
we can't do type inference on methods unless we do type inference
everywhere, which we can't do if we want an autoloader.
This
On Tue, 2005-03-29 at 16:00 -0700, Luke Palmer wrote:
Unless the caller can't see the signature, as is the case with methods.
I need to understand this piece.
In this code:
class X {
method meth() {...}
}
class Y is X {
method meth() is
Aaron Sherman writes:
On Tue, 2005-03-29 at 16:00 -0700, Luke Palmer wrote:
Unless the caller can't see the signature, as is the case with methods.
I need to understand this piece.
In this code:
class X {
method meth() {...}
}
class Y is X {
On Wed, Mar 30, 2005 at 09:40:26AM -0700, Luke Palmer wrote:
: There _is_ a way to do it, actually, but we need to really screw around
: with what kinds of things are inferred. In the case:
:
: my $a;
: $a.m(1);
:
: We assign the type objects with an 'm' method that can take a single
:
HaloO Luke,
you wrote:
No, I think I agree with you here. But what happens if you change
you're second-to-last line to:
my $a = foo();
$a.meth() = 8;
Perl 6 is both a statically typed language and a dynamically typed
language, and the problems that I am addressing are mostly about the
On Wed, 2005-03-30 at 11:40, Luke Palmer wrote:
No, I think I agree with you here. But what happens if you change
you're second-to-last line to:
my $a = foo();
$a.meth() = 8;
Perl 6 is both a statically typed language and a dynamically typed
language, and the problems that I am
Thomas Sandla writes:
And of course the builtin functionality and the packages available
from CPAN save the typical small scale programmer from extensive
declarations. But to use a complex module you have to read
documentation to get the idea to call .meth() in the first place.
And then I
Larry Wall wrote:
I think it's perfectly fine for the compiler to make use of whatever
information it has. The trick is to never make any unwarranted
assumptions, such as Nobody will ever add another class with an 'm'
method.
Er, isn't that not just the wrong way around? The point is to do the
On Wed, 2005-03-30 at 13:53, Luke Palmer wrote:
class CodeProxy {
has Code $.code is rw;
sub call ($a) {
$.code($a);
}
}
This is valid Perl 6, and anyone who says otherwise (because of type
signatures) is changing the Perl philosophy too much
On Wed, Mar 30, 2005 at 12:05:12PM +0200, Thomas Sandlaß wrote:
: If I understand you correctly the use statement is more like a
: linker/loader directive than a compile time interface include?
That is up to the module being used. use is a linker, but it's
only required to link enough
On Wed, 2005-03-30 at 14:29 -0500, Aaron Sherman wrote:
What I do not think should be allowed (and I may be contradicting Larry
here, which I realize is taking my life in my hands ;) is violating the
compile-time view of the static type tree. That is, you can load an
object foo at run-time,
On Wed, 2005-03-30 at 14:57, chromatic wrote:
I certainly plan to continue to instrument code at runtime (and not just
really slushy, partially slushy, and permafrost compile time).
That's FINE, and no one should stop you!
What I was referring to was only the items that an interface
On Wed, 2005-03-30 at 15:27 -0500, Aaron Sherman wrote:
Like I said, if you allow run-time munging of the type interfaces, then
you can't tell if this is valid or invalid:
my X $a;
$a.m(1);
you have to allow it always, regardless of the definition of X. In fact,
you can
Luke Palmer wrote:
class CodeProxy {
has Code $.code is rw;
sub call ($a) {
$.code($a);
}
}
This is valid Perl 6,
Hmm, a sub in a class? I guess that should be a method. OTOH a
class is just a funny module, so might be OK. But that is the
syntax realm.
chromatic wrote:
A compiler that assumes incorrectly and disallows programmers to do
useful things because its holds those assumptions as precious is wrong
-- especially in cases where even the programmer can't tell if code is
valid or invalid until the program actually runs.
Me neither. One
Aaron Sherman wrote:
No, that was most of the point. foo did not declare a return type, and
while my code was simplistic, we obviously cannot be certain what foo
might return in the general case.
Sorry that I've spoiled that. But I wonder if it's just in the examples
here on the list or a general
Thomas Sandla writes:
Aaron Sherman wrote:
No, that was most of the point. foo did not declare a return type, and
while my code was simplistic, we obviously cannot be certain what foo
might return in the general case.
Sorry that I've spoiled that. But I wonder if it's just in the
examples
Thomas Sandla writes:
Luke Palmer wrote:
class CodeProxy {
has Code $.code is rw;
sub call ($a) {
$.code($a);
}
}
This is valid Perl 6,
Hmm, a sub in a class? I guess that should be a method. OTOH a
class is just a funny module, so might be
Aaron Sherman writes:
What I do not think should be allowed (and I may be contradicting
Larry here, which I realize is taking my life in my hands ;) is
violating the compile-time view of the static type tree.
That sentence is getting pretty C++-derived-like, which Perl is hardly
anymore. We
Aaron Sherman writes:
On Wed, 2005-03-30 at 13:53, Luke Palmer wrote:
class CodeProxy {
has Code $.code is rw;
sub call ($a) {
$.code($a);
}
}
This is valid Perl 6, and anyone who says otherwise (because of type
signatures) is
Aaron Sherman writes:
Please think carefully about how dynamic you want Perl 6 to be
Dynamic is good, but there's such a thing as too much of a good thing.
We'd like Perl 6 to be as dynamic as Perl 5.
We'd think that is impossible. Perl 5 had full control of the
run-time, Perl 6
According to Luke Palmer:
[Perl 5] had to construct lvalues out of all arguments (for which
that made sense) because the sub might modify them.
No, actually, that wasn't the reason. Perl 5 passes all values by
implicit mutable reference because it's faster, not because it's
better. I suspect
Luke Palmer wrote:
Okay, now we're starting to talk past each other. I /think/ Thomas
orignially suggested that we use type inference to determine whether to
lvalue cast an argument or not, which is what I got all worked up about.
Actually I was returning to the subject of co- or contravariance
On Wed, 2005-03-30 at 17:09, Luke Palmer wrote:
Aaron Sherman writes:
What I do not think should be allowed (and I may be contradicting
Larry here, which I realize is taking my life in my hands ;) is
violating the compile-time view of the static type tree.
That sentence is getting
On Wed, 2005-03-30 at 18:35 -0500, Aaron Sherman wrote:
When the Perl 6 compiler sees:
my X $a;
$a.m(1);
What should it do?
Options:
* Accept the method call regardless of the definition of X
* Accept the method call if it matches the signature from X
Luke Palmer wrote:
So if you want things modified, you'd have to pass in a reference.
Arrays and hashes would not generally have this restriction, since we
pass references of those guys anyway.
But I would really like to see a declaration of any possible modification
in the interface of a sub.
Thomas Sandla writes:
Luke Palmer wrote:
So if you want things modified, you'd have to pass in a reference.
Arrays and hashes would not generally have this restriction, since we
pass references of those guys anyway.
But I would really like to see a declaration of any possible modification
I'm working on enhancing Perl6::Subs[*] to support more parameter
traits than just Cis required. I have some questions about
parameters and traits. (These questions all apply to pure Perl 6,
which I know I won't be able to translate completely, but I want to
know which target I'm missing.)
*
Chip Salzenberg writes:
I'm working on enhancing Perl6::Subs[*] to support more parameter
traits than just Cis required. I have some questions about
parameters and traits. (These questions all apply to pure Perl 6,
which I know I won't be able to translate completely, but I want to
know
Chip Salzenberg wrote:
* As far as I can tell, the choice of spelling an array parameter
CArray @a or CArray $a is entirely cosmetic: both @a and
$a are capable of holding an Array reference. Is there actually
a difference, e.g. in how they handle an undefined value?
Uhm... It was my
According to Rod Adams:
Chip Salzenberg wrote:
* As far as I can tell, the choice of spelling an array parameter
CArray @a or CArray $a is entirely cosmetic: both @a and
$a are capable of holding an Array reference. Is there actually
a difference, e.g. in how they handle an undefined
On Sat, Mar 26, 2005 at 03:45:30PM -0500, Chip Salzenberg wrote:
: According to Rod Adams:
: Chip Salzenberg wrote:
: * As far as I can tell, the choice of spelling an array parameter
:CArray @a or CArray $a is entirely cosmetic: both @a and
:$a are capable of holding an Array reference.
On Sat, Mar 26, 2005 at 03:13:07AM -0700, Luke Palmer wrote:
: Chip Salzenberg writes:
: I'm working on enhancing Perl6::Subs[*] to support more parameter
: traits than just Cis required. I have some questions about
: parameters and traits. (These questions all apply to pure Perl 6,
: which
LW == Larry Wall [EMAIL PROTECTED] writes:
LW That being said, in Perl 5, if you say
LW @a = undef;
LW you don't get an undefined array. I'd like to make undef smart enough
LW about list contexts that @a actually does end up undefined in Perl 6.
LW That is, in scalar context,
LW == Larry Wall [EMAIL PROTECTED] writes:
LW As I mentioned in my other message, I think we should not assume that
LW Perl 6 works the same in this regard as Perl 5 does. There needs to be
LW something we can return that not only means (), but means also means
LW You're hosed! (And
On Sun, Mar 27, 2005 at 12:04:39AM -0500, Uri Guttman wrote:
: LW == Larry Wall [EMAIL PROTECTED] writes:
:
: LW As I mentioned in my other message, I think we should not assume that
: LW Perl 6 works the same in this regard as Perl 5 does. There needs to be
: LW something we can return
On Sat, Mar 26, 2005 at 11:57:48PM -0500, Uri Guttman wrote:
: LW == Larry Wall [EMAIL PROTECTED] writes:
:
: LW That being said, in Perl 5, if you say
:
: LW @a = undef;
:
: LW you don't get an undefined array. I'd like to make undef smart enough
: LW about list contexts that @a
LW == Larry Wall [EMAIL PROTECTED] writes:
LW : then how would you assign undef to the only element of the
LW array? would this : be needed:
LW :
LW : @a = ( undef ) ;# same as p5?
LW :
LW : vs.
LW : @a = undef ;# like undef @a in p5?
LW
50 matches
Mail list logo
