develooper Front page | perl.perl6.language | Postings from March 2005

Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?

Thread Previous | Thread Next
From:
=?UTF-8?B?VGhvbWFzIFNhbmRsYcOf?=
Date:
March 30, 2005 15:13
Subject:
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Message ID:
424B328B.8080504@orthogon.com
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 of
parametric types but trying to avoid these terms. I gave an example
how to get a Str into an Array of Int when you assume in general that
Array of Int <: Array of Any. Which is reasonable only for reading
because the reader doesn't care of the type and Int is compatible with
such a reading. For writing you need the reverse relation because the
writer expects an array that accepts Ints and and Array of Any does
this. For a read-write Array both cases must hold, thus only type
equality is sound. So when the compiler knows about a 'is rw' trait
on a parameter and the type of an array---and it does so the latest
when the call is attempted, but that is not the compiler then---it
should reject the call!


> I'm saying that you can't determine that kind of thing in general at
> compile time.

Of course not, but the question is than just shifted to: "do you want a
runtime exception when sub foo( @a is rw ) is called with an Array of Int?"
If you answer no, than you take the consequence that this Array of Int
might contain other things than Ints. That's all.

There is no type inference per se in my argument. It just might help the
compiler to gather the necessary type information to ask the above question
at compile time.

Larry takes the point of view that the Str goes in but the Array knows
that it should be an Int and nicely converts that for you. And actually
Any might just be a glb (greatest upper bound) of Int and Str, written
Int|Str in Perl6, so the type checker knows that *this* case is OK.
But it will complain if Any isn't a glb of SomeOtherType and you call
foo with Array of SomeOtherType. Note that
   Int|Str <: Str && Str <: Int|Str && Int|Str <: Int && Int <: Int|Str
holds. Given an even more complex Any type that encompasses the general
purpose types of Perl6---namely Str, Int, Num, Bool and Refs thereof---
the lazy Perl6 programmer gets what Perl5 did all the time. This is
what is called "Render the Illusion of Simplicity".

This illusion fades when you get the compile time warning "no glb for
Any and SomeOtherType" and you have to go figure what to do about it ;)
But once again these might hit a strong programmer and the not so strong
ones a kept in the illusion: "look I just use SomeOtherType and it works".


> I'm all for an optional strong type system, as long as it
> remains optional and mixable (so static things and dynamic things can
> play nicely together, whether the module is static and the user dynamic
> or vice-versa).  

Optional in what sense?
-- 
TSa (Thomas SandlaƟ)


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About