--
On Fri, 14 Mar 2003 10:08:15
Larry Wall wrote:
>On Thu, Mar 13, 2003 at 07:36:00PM -0800, Brent Dax wrote:
>: I think that there should be two types of arg typing[1]: 'strict' and
>: 'loose'. Strict arg typing doesn't coerce, except to turn subclasses
>: into superclasses; loose arg typin
Michael Lazzaro wrote:
3) If an "untyped" var is used for a typed parameter, a simple dataflow
analysis is used to determine whether the compiler can guarantee that,
at that point, an "untyped" var will _always_ contain values of a known,
specific type. If so, the type is inferred (silently or
Friday 14 March 2003 20:06, Michael Lazzaro wrote:
> 3) If an "untyped" var is used for a typed parameter, a simple
> dataflow analysis is used to determine whether the compiler can
> guarantee that, at that point, an "untyped" var will _always_
> contain values of a known, specific type. If so, t
OK, divide & conquer. We seem to be spasming about this and trying to
talk about N things at once, so here's an issue summary. We're talking
about at least two separate cases, (1) "inferring" type where none has
been specified, and (2) "coercing" a typed value into another type.
Let's take t
On Thu, Mar 13, 2003 at 07:36:00PM -0800, Brent Dax wrote:
: I think that there should be two types of arg typing[1]: 'strict' and
: 'loose'. Strict arg typing doesn't coerce, except to turn subclasses
: into superclasses; loose arg typing, on the other hand, coerces whenever
: possible. The mech
On Thu, Mar 13, 2003 at 10:52:04PM +0100, Anton Berezin wrote:
: On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
:
: > By distinguishing a parameter that *requires* a particular type, from
: > a parameter that *ensures* a particular type (by coercion if
: > necessary). I've suggeste
On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
> By distinguishing a parameter that *requires* a particular type, from
> a parameter that *ensures* a particular type (by coercion if
> necessary). I've suggested that using C semantics should
> indicate "make whatever I'm actually gi
Damian Conway wrote:
b) The argument passed here must be something that will definitely
not cause the program to crash and burn, and we'll verify
that at
compile-time.
I'm arguing that the former is well-nigh useless, and that the latter is
what large systems developers and
Damian Conway:
# a) The argument passed here must be something that
# could conceivably
# not cause the program to crash and burn, and
# we'll verify that at
# run-time if necessary.
#
# or:
#
# b) The argument passed here must be something that will
# definite
Larry Wall wrote:
On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
: But if I say:
:
: sub foo(@a is Array of Int) {...}
: ...
: foo(@x);
:
: then I'm saying: "within &foo, @a is just another name for @x". So they are
: (temporarily) the same thing. That can only (be allowed to
> I don't see a problem. Scalar == Int|Num|Str|Ref, so
> Scalar.isa("Int").
Scalar.isa("Int") && Int.isa("Scalar")
__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
On Thu, Mar 13, 2003 at 11:31:30AM -0800, Austin Hastings wrote:
: "Everyone Knows" that an Int is a Scalar, and therefore a sub that has
: a Scalar parameter can safely be passed an Int. This is normal.
:
: What I want is the ability to do the opposite: Silence the warning that
: occurs when I pa
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> > But what's the vision for p6?
> >
> > My expectation is that the type-checking stuff will be heavily used
> > for:
> >
> > 1- Large scale projects.
> >
> > 2- CPAN modules.
> >
> > I expect that the folks who want to
On Thu, Mar 13, 2003 at 06:28:00PM +0100, Angel Faus wrote:
:
: Damian Conway wrote:
: > But large projects -- where typing will be most important --
: > *can't* deal with that. That's the point of typing: to specify and
: > enforce interface contracts. At compile-time if at all possible.
:
: One
On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
: But if I say:
:
: sub foo(@a is Array of Int) {...}
: ...
: foo(@x);
:
: then I'm saying: "within &foo, @a is just another name for @x". So they are
: (temporarily) the same thing. That can only (be allowed to) ha
Damian Conway wrote:
> But large projects -- where typing will be most important --
> *can't* deal with that. That's the point of typing: to specify and
> enforce interface contracts. At compile-time if at all possible.
One quick question about this. If I write:
sub foo (Bar $f) {..}
my $x
On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
: But what we can't allow is a reference parameter to coerce its argument.
: For example:
:
: sub loggedincr (Int $i is rw) {
: print $log: "Incremented $i.id()\n";
: $i++ unless $i.constant;
:
Damian Conway <[EMAIL PROTECTED]> writes:
> Austin Hastings wrote:
>
>> But what's the vision for p6? My expectation is that the
>> type-checking stuff will be heavily used
>> for:
>> 1- Large scale projects.
>> 2- CPAN modules.
>> I expect that the folks who want to do one-liners will still want
Austin Hastings wrote:
But what's the vision for p6?
My expectation is that the type-checking stuff will be heavily used
for:
1- Large scale projects.
2- CPAN modules.
I expect that the folks who want to do one-liners will still want to be
able to say C
So the "strict" bits have to be forgivin
Austin Hastings wrote:
But what's the vision for p6?
My expectation is that the type-checking stuff will be heavily used
for:
1- Large scale projects.
2- CPAN modules.
3- speed
When you are not on perl one liners, but maybe some inner tight loops of
some algorithm or whatever, where speed d
> Agreed. It should do compile-time verification, not runtime.
>
> That said, I still think there *might* be something to be said for
> compile-time 'hints' for explicitly _untyped_ values.
Perhaps there should be a distinction between "untyped" and "Object".
Something that is explicitly an O
I think the issue of type coercion (forcing one type to another) should
be decided separately from the issue of "implicit" types (recognizing
when an untyped variable can be KNOWN at a given point to hold a
specific type, even if it isn't explicitly stated.)
As far as true coercion goes: for th
On Wednesday, March 12, 2003, at 11:07 AM, Damian Conway wrote:
Austin Hastings wrote:
In this case, I rather like the idea of being able to say
sub foo(@a is Array of Int) {...}
my @input = read_a_bunch_o_data();
foo(@input);
Where the compiler will automatically "wrap" the @input array
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> > In this case, I rather like the idea of being able to say
> >
> >sub foo(@a is Array of Int) {...}
> >
> >my @input = read_a_bunch_o_data();
> >foo(@input);
> >
> >
> > Where the compiler will automaticall
Austin Hastings wrote:
In this case, I rather like the idea of being able to say
sub foo(@a is Array of Int) {...}
my @input = read_a_bunch_o_data();
foo(@input);
Where the compiler will automatically "wrap" the @input array in a
make-it-an-int converter. This, to me, is DWIM.
But to ma
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> > You're treading dangerously close to the S&M line there...
>
> Sure. That's exactly what types are for.
>
Granted.
> > Does it make sense to say C for this stuff?
>
> I'd much rather that simply using typed params i
26 matches
Mail list logo
