HaloO Autrijus,

you wrote:
On Fri, May 13, 2005 at 07:13:53PM +0200, "TSa (Thomas Sandlaß)" wrote:

Larry Wall wrote:

: Void context still exists and is not a form of singular or plural
: context. Perhaps this should be called nullar context, although void
: context works equally well for me and is not confusing because we have
: no Void type.

Nice, without Void we don't need the double headed pseudo type lattice needed if we were to distinguish subs that return no usefull---that is Any---value from the ones that return no value at all.


Hrm.  So if I have a sub that does nothing:

sub Foo { }

I don't know what the empty body does. But it might just return an undef value.


Is it illegal to say this?

sub Foo returns Void { }

Well, $Larry said that there's no Void type. Thus it's illegal unless of course some non-standard class bears that name which would be a bit odd.


What about:

sub Foo returns :() { }

Ups, looks quite void to me. So, this might prevent e.g.

  $x = Foo();

by giving a static type error. OTOH, @Larry might argue
that it's one way to write :(Any).


Or do I really need to convert it to this?

sub Foo returns Any { }

The only reason to distinguish the topmost type from Void is that it can't be used as a value e.g. in an assignment.

OTOH such a Code subtype should be easily subtypable, and the
return type is covariant like the invocants, but the
non-invocants are contra-variant.
So, assuming Bit <: Int <: Num <: Any, and <: beeing the
subtype relation, and using the --> for function types,
this means e.g.

 :( Bit,Int : Int,Num --> Int ) <: :( Int,Int : Bit,Int --> Num )

In words:
 1) :(Bit,Int) is more specific than :(Int,Int) for MMD
 2) :(Int,Num) is more general than  :(Bit,Int) for type safety on call
 3) :(Int) can go were a :(Num) is expected as return type

Subtyping :(: Any --> ) 'sub with param type Any returning void'
wouldn't work if Void is the bottommost type or outside the
type system.

Actually I still wonder if the type system will work as indicated
above at all. P6l might find that too B&D-ish.
--
TSa (Thomas Sandlaß)



Reply via email to