Re: returns and context

2005-06-01 Thread TSa (Thomas Sandlaß)

Gaal Yahas wrote:

How do I specify the signature of a context-sensitive function?

 sub foo() returns (what?) {
 return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
 }

If it were two subs, one would is returns Int and the other List of
Sheep. The draft S29 uses things like Int|List to express this kind
of thing but that looks weird to me (how would you return a typed
junction?). S06 and E06 don't raise this issue.


Well, if my type lattice proposal were accepted as the way the type system
of Perl 6 works, the return type of your function could indeed be written
or possibly inferred by the compiler to be :(Int|List[Sheep]) but it would
mean a LUB (least upper bound) of the two types mentioned. This implies
that if you were to give foo's return value to a multi which has two
different possible receivers for :(Int) and :(List of Sheep) respectively,
the context might be undef or a LUB as well.

The base point with type systems is that if one is not specific about the
types than nothing specific can happen! So either the caller must state
what shall be the return type or the implementation must specify what it
returns. I would call the former reverse dispatch or somesuch. Since every
function that has a very unspecificly declared return type might
nonetheless produce something beeing the most specific. So, all 
dispatchable targets have to be called and after all return types are 
available the most specific is picked. That smells like the autothreading

of junctions that I don't understand either.

The case where the caller just hands over the args to the dispatcher OTOH,
calls the most specific target and then has to go with whatever the output
is. It might just produce a type error or lead to the next dispatch.

An alternative return type of your sub might be :(Int ^ List of Sheep)
which firstly excludes the GLB (greatest lower bound) of :(Int) and
:(List of Sheep) which is written :(Int  List of Sheep) and secondly
doesn't prevent the double call or undefined context, either.

My conclusion from all this is that the notion of context is Perl's
version of static typing ala C++ and Java.


Sorry if this wasn't what you wanted to hear.
--
TSa (Thomas Sandlaß)



Re: returns and context

2005-05-31 Thread Rod Adams

Gaal Yahas wrote:


How do I specify the signature of a context-sensitive function?

sub foo() returns (what?) {
return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
}

If it were two subs, one would is returns Int and the other List of
Sheep. The draft S29 uses things like Int|List to express this kind
of thing but that looks weird to me (how would you return a typed
junction?). S06 and E06 don't raise this issue.
 



Being that I'm the one who wrote it that way, it doesn't look at all 
weird to me to do it that way. =)


I suspect a typed junction would look like : Junction of Int|Str.

-- Rod Adams



Re: returns and context

2005-05-31 Thread Sam Vilain

Rod Adams wrote:

How do I specify the signature of a context-sensitive function?
sub foo() returns (what?) {
return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
}

I suspect a typed junction would look like : Junction of Int|Str.


Not quite.  AIUI that means a Junction of which the members are Int or Str.

This is how I've been writing it:

  sub foo() returns Scalar|List {
  return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
  }

I think the default return type of unlabeled subs would be:

  returns Void|Scalar|List

but of course $?SELF =:= none(@Larry) ;)

Sam.


Re: returns and context

2005-05-31 Thread Rod Adams

Sam Vilain wrote:


Rod Adams wrote:


How do I specify the signature of a context-sensitive function?
sub foo() returns (what?) {
return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
}


I suspect a typed junction would look like : Junction of Int|Str.



Not quite.  AIUI that means a Junction of which the members are Int or 
Str.



Yep, which is how I interpreted the question inside the parens inside 
the paragraph, completely ignoring the question in the code block, since 
Gaal answered it himself.



-- Rod Adams