Re: Context and return types question
Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote: my ($x, :$named) = foo; # or something like that That looks to me like a form of positional extraction. (Of course, my hit rate on p6 stuff has been remarkably low of late...) It's not just positional, but allows for named arguments too. It is exactly like calling a function: named arguments match to parameters with those names, then any left over are positional.
Re: Context and return types question
On Apr 21, 2008, at 9:39 , John M. Dlugosz wrote: TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: I think the type is just :( $: :named$ ) if you want to extract the invocant with a $ prefix. Otherwise it would be :( $, :named $ ) and you extract the item positionally with prefix @ or .[]. I don't want to have to "extract" it. I want to be able to say $x = foo and get the single value return from foo, and only dress it up if I want the optional secondary returns my ($x, :$named) = foo; # or something like that That looks to me like a form of positional extraction. (Of course, my hit rate on p6 stuff has been remarkably low of late...) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: Context and return types question
HaloO, John M. Dlugosz wrote: I don't want to have to "extract" it. I want to be able to say $x = foo I guess that does not collapse the capture that foo returns. So it goes into $x unaltered. If you later use $x as an invocant of a method this extracts the invocant slot from the capture. And $x works as expected. and get the single value return from foo, and only dress it up if I want the optional secondary returns my ($x, :$named) = foo; # or something like that Should work. Sorry, you lost me again. Single-assignment is a feature from constraint programming e.g. in Oz. There you have a single-assignment store. I interpreted Larry's comment on my coro question as making single-assignment semantics first-class and everything else second-class. A capture can contain an array that later on can change its content: @a = 1,2,3; @b = 4,5,6; @c = 7,8,9; $cap = \(@a,@b); $cap[0] = @c; # error $cap[0][] = @c; # ok, @a now 7,8,9 Writing into a container is contra-variant. Reading is co-variant. So a capture has to be invariant. Assume A <: B <: C and regard my A $a; my C $c; my B $ba := $a; # ok for reading from $a my B $bc := $c; # ok for writing into $c Both bindings are type errors. If captures were recursively immutable you could allow bindings ala $ba. Well, or we interpret $a and $b as typed views of whatever value they lead to. This insures that there will never be assignment or binding type errors. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: Context and return types question
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: I guess with strong you mean as lossless as possible? I think the type is just :( $: :named$ ) if you want to extract the invocant with a $ prefix. Otherwise it would be :( $, :named$ ) and you extract the item positionally with prefix @ or .[]. I don't want to have to "extract" it. I want to be able to say $x = foo and get the single value return from foo, and only dress it up if I want the optional secondary returns my ($x, :$named) = foo; # or something like that Note that Captures are immutable and therefore nicely covariant. Except of course that containers are captured as containers and can be mutated. But Larry revealed that single assignment semantics are aspired and mutability is a historic artifact or so. Regards, TSa. Sorry, you lost me again.
Re: Context and return types question
HaloO,
John M. Dlugosz wrote:
Great. So the flip side is, what do I return from a function so that it
gives a single value if called simply, but provides optional named
returns that are there if you catch them? As a capture with one
positional and one named argument?
Yeah, just that.
And how do you declare =that= return type ("of" type) to be strongly typed?
I guess with strong you mean as lossless as possible?
I think the type is just :( $: :named$ ) if you want to extract the
invocant with a $ prefix. Otherwise it would be :( $, :named$ ) and you
extract the item positionally with prefix @ or .[]. Note that Captures
are immutable and therefore nicely covariant. Except of course that
containers are captured as containers and can be mutated. But Larry
revealed that single assignment semantics are aspired and mutability
is a historic artifact or so.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Re: Context and return types question
HaloO, Larry Wall wrote: In general, we're trying to get away from want-based context dependency and instead attempting to encourage lazy semantic constructs such as Captures that can behave with a wide dynamic range when actually bound later. Shouldn't we then change the heading of the respective section from "Advanced Subroutine Features" to "Deprecated Subroutine Features"? For instance, Arrays now behave such that, if you use one in numeric context, you get the number of elements, so unlike in Perl 5, you need not decide at return time whether the array is in item or list context. You just return the array, and it will act much like it does in Perl 5 if you use it in a numeric or boolean context. Since the default return type is Capture, it doesn't matter if you declare the "of" type as Array or not, since the Capture doesn't force either item or list context on the Array either. It should behave much the same in either case, except that if you declare the "of" type as Array, you give the compiler/optimizer/type inferencer more information to work with at compile time. Note that this implies Seq <: Num <: Item <: Seq which is a cycle! Dealing with cycles is not within the reach of type system because these need <: to be transitive. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: Context and return types question
HaloO,
John M. Dlugosz wrote:
How about sub foo (--> Seq^Item) {...}?
Interesting idea, but that doesn't tell the compiler that the return is
keyed to the context. The compiler should know what return type to
expect, if only I could explain it.
Sorry, the type has nothing to do with how the function comes up with
its return value. In that respect you must regard the context as part
of the input of the function that of course influences its output.
I don't see how Seq^Item as a type is any different than Seq|Item. It
can only hold one at a time anyway.
A type is a type. There is nothing that varies or holds a value or some
such. Seq|Item means to me that there are three cases: Seq only, Item
only and both. Seq^Item excludes the latter. That is Seq^Item is the
disjoint union of Seq and Item. Larry's reply essentially means
Item <: Seq that is Seq subsumes Item. But that has problems of its
own---see my reply there.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Re: Context and return types question
Great. So the flip side is, what do I return from a function so that it
gives a single value if called simply, but provides optional named
returns that are there if you catch them? As a capture with one
positional and one named argument?
And how do you declare =that= return type ("of" type) to be strongly typed?
--John
Larry Wall larry-at-wall.org |Perl 6| wrote:
On Fri, Apr 18, 2008 at 05:34:25AM -0500, John M. Dlugosz wrote:
If a function returns different things if called in list context or item
context, how do you define the "of" type (outer return type) to make the
function strongly typed?
You can't. An "of" type forces the function into a single context
(unless we allow polymorphic return types as TSa mentions).
In general, we're trying to get away from want-based context dependency
and instead attempting to encourage lazy semantic constructs such
as Captures that can behave with a wide dynamic range when actually
bound later.
For instance, Arrays now behave such that, if you use one in numeric
context, you get the number of elements, so unlike in Perl 5, you need
not decide at return time whether the array is in item or list context.
You just return the array, and it will act much like it does in Perl 5
if you use it in a numeric or boolean context. Since the default
return type is Capture, it doesn't matter if you declare the "of"
type as Array or not, since the Capture doesn't force either item or
list context on the Array either. It should behave much the same in
either case, except that if you declare the "of" type as Array, you
give the compiler/optimizer/type inferencer more information to work
with at compile time.
Larry
Re: Context and return types question
If a function returns different things if called in list context or
item context, how do you define the "of" type (outer return type) to
make the function strongly typed?
How about sub foo (--> Seq^Item) {...}?
Interesting idea, but that doesn't tell the compiler that the return is
keyed to the context. The compiler should know what return type to
expect, if only I could explain it.
I don't see how Seq^Item as a type is any different than Seq|Item. It
can only hold one at a time anyway.
Re: Context and return types question
On Fri, Apr 18, 2008 at 05:34:25AM -0500, John M. Dlugosz wrote: > If a function returns different things if called in list context or item > context, how do you define the "of" type (outer return type) to make the > function strongly typed? You can't. An "of" type forces the function into a single context (unless we allow polymorphic return types as TSa mentions). In general, we're trying to get away from want-based context dependency and instead attempting to encourage lazy semantic constructs such as Captures that can behave with a wide dynamic range when actually bound later. For instance, Arrays now behave such that, if you use one in numeric context, you get the number of elements, so unlike in Perl 5, you need not decide at return time whether the array is in item or list context. You just return the array, and it will act much like it does in Perl 5 if you use it in a numeric or boolean context. Since the default return type is Capture, it doesn't matter if you declare the "of" type as Array or not, since the Capture doesn't force either item or list context on the Array either. It should behave much the same in either case, except that if you declare the "of" type as Array, you give the compiler/optimizer/type inferencer more information to work with at compile time. Larry
Re: Context and return types question
HaloO John,
your inquiry rate is quite high. I try to keep-up as good
as I can. Without being authoritative, of course.
you wrote:
If a function returns different things if called in list context or
item context, how do you define the "of" type (outer return type) to
make the function strongly typed?
How about sub foo (--> Seq^Item) {...}?
Unfortunately the set of type constructors is rather limited
as of now. $Larry explicitly disallowed
role R does A|B {...}
at one point in the discussion. But these one-junction types
would be very useful e.g. Num could actually be Real^NaN^Overflow^...
so that if you wanted a non-exceptional type you could use Real.
Note that this implies that Num is *unordered* and the order-ops
actually act on the Real type.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
