Self type

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: array slice syntax

Stefan Gössner
thanks for the clarification
--
stefan

Brendan Eich wrote:

> On Aug 16, 2007, at 10:42 AM, Lars T Hansen wrote:
>
>> On 8/16/07, Stefan Gössner <[hidden email]> wrote:
>>> Hello,
>>> here are my first questions after following the list quite a while.
>>>
>>> 1. I really like the array slice syntax [start:end:step] described in
>>> http://developer.mozilla.org/es4/proposals/slice_syntax.html
>>>
>>> The description seems to miss the case, where 'start' is greater  
>>> than 'end'.
>>>
>>> a[5:2]
>>>
>>> Will
>>> (a) 'step' be implicitely set to -1 ?
>>> (b) an empty array come as result ?
>>> (c) an error occur ?
>> The description seems to be clear here, the result should be an  
>> empty array.
>
> Same as for Python:
>
>  >>> s = [1,2,3]
>  >>> s[2:1]
> []
>
>>> 2. The descendant operator '..' is mentioned only in the tutorial
>>> introduction.
>>> http://developer.mozilla.org/es4/spec/ 
>>> chapter_1_tutorial_introduction.html
>>> I could not find it mentioned elsewhere.
>>>
>>> Is it also considered to work with array notation as in:
>>>
>>> y..[0]   // access the first element of all arrays of 'y' and it's
>>> descendants.
>> I don't think so.  The descendant operator is for E4X (ECMAScript for
>> XML, ECMA-357) and has not been discussed in other contexts.  E4X is
>> not included in ECMAScript 4 at this stage.
>
> We are reserving E4X syntax but not requiring it to be supported.
>
> The .. operator bugs me because it implicitly quotes its right  
> operand (as . does), so you could not use it as Perl and other  
> languages do for range operator. If it were a dyadic operator that  
> did not quote either operand, than it could be overridden by the  
> operators proposal (or an operators proposal, at any rate ;-) and  
> made to work for range (integer literal or value on left) as well as  
> for E4X (XML on left).
>
> Generalizing query, matching, and filtering from E4X to the whole  
> language, cleaning up the "un-JavaScript-y" aspects of E4X, making  
> use of practical research such as JMatch [1], all will have to wait  
> for a future Edition. But we certainly can discuss ideas here. Please  
> feel free to do so.
>
> /be
>
> [1] http://www.cs.cornell.edu/Projects/jmatch/
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Self type

Peter Hall-4
In reply to this post by Cormac Flanagan
I think my confusion here, is perhaps that I'm seeing this a slightly
different way. What you are saying seems to suggest that Self type
annotations can behave differently at runtime. To me, this example
from the wiki should be an error:

type T1 = { f:function(this:Self, z:Self):Self, w:int}
var x:T1 = { ... }:T1
type T2 = { f:function(this:Self, z:Self):Self }
var y:T2 = x; // ERROR

Because the types are equivalent to:

type T1 = { f:function(this:T1, z:T1):T1, w:int}
type T2 = { f:function(this:T2, z:T2):T2}

So T1's f and T2's f are incompatible. In a real situation, an author
would have to be a bit more careful about how the types are defined,
and probably use wildcard types or Object (or perhaps fully expanded
type definitions) where necessary. But I think that is better than
having wildcards inserted automatically behind the scenes.


Peter

On 8/14/07, Cormac Flanagan <[hidden email]> wrote:

>
>
> Peter Hall wrote:
> > On 8/14/07, Eylon Stroh <[hidden email]> wrote:
> >> From the proposal:
> >> "The return type T2 is ok, even if the function returns a T1 instead...
> >> covariant occurrences of Self (eg in the result type) are replaced by
> >> T2"
> >>
> >
> > I was also wondering about this.
> > To me, if someone writes "Self" for an argument or return type, they
> > probably mean T1. If they actually want it to be "*", why not let them
> > write "*"? Or is there something else going on here?
>
> Yes, it would be intuitive to replace "Self" by T1, but it would be
> unsound, since Self really means:
>
>    the actual allocated type of the current object, which is some unknown
>    subtype of the known static type T1 of that object
>
> so we can only safely replace Self by T1 in "covariant" contexts (where
> we get stuff out, and don't care if we actually get a subtype),
> but not in "contravariant" contexts, such as argument positions.
>
> - Cormac
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Self type

Eylon Stroh-3
Peter,

This was my confusion, as well.  I was about to send a reply to Cormac's
email but, in working through my reply, I realized what was going on.

The types are not quite equivalent to substituting T1 and T2, because
Self is the concrete object type which needs to be a subtype of the
defined type but not exactly the same, so the equivalent expressions
are:

type T1 = { f:function(this:t1, z:t1):t1, w:int } for some t1 <: T1

type T2 = { f:function(this:t2, z:t2):t2 } for some t2 <: T2

This means that

var x:T1 = { ... }:T1; var y:T2 = x;

is not an error, because T1 is a legitimate candidate for t2 <: T2.

-- Eylon --


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Peter Hall
Sent: Friday, August 17, 2007 7:35 AM
To: Cormac Flanagan
Cc: Brendan Eich; es4-discuss
Subject: Re: Self type

I think my confusion here, is perhaps that I'm seeing this a slightly
different way. What you are saying seems to suggest that Self type
annotations can behave differently at runtime. To me, this example from
the wiki should be an error:

type T1 = { f:function(this:Self, z:Self):Self, w:int} var x:T1 = { ...
}:T1 type T2 = { f:function(this:Self, z:Self):Self } var y:T2 = x; //
ERROR

Because the types are equivalent to:

type T1 = { f:function(this:T1, z:T1):T1, w:int} type T2 = {
f:function(this:T2, z:T2):T2}

So T1's f and T2's f are incompatible. In a real situation, an author
would have to be a bit more careful about how the types are defined, and
probably use wildcard types or Object (or perhaps fully expanded type
definitions) where necessary. But I think that is better than having
wildcards inserted automatically behind the scenes.


Peter

On 8/14/07, Cormac Flanagan <[hidden email]> wrote:
>
>
> Peter Hall wrote:
> > On 8/14/07, Eylon Stroh <[hidden email]> wrote:
> >> From the proposal:
> >> "The return type T2 is ok, even if the function returns a T1
instead...
> >> covariant occurrences of Self (eg in the result type) are replaced
> >> by T2"
> >>
> >
> > I was also wondering about this.
> > To me, if someone writes "Self" for an argument or return type, they

> > probably mean T1. If they actually want it to be "*", why not let
> > them write "*"? Or is there something else going on here?
>
> Yes, it would be intuitive to replace "Self" by T1, but it would be
> unsound, since Self really means:
>
>    the actual allocated type of the current object, which is some
unknown
>    subtype of the known static type T1 of that object
>
> so we can only safely replace Self by T1 in "covariant" contexts
> (where we get stuff out, and don't care if we actually get a subtype),

> but not in "contravariant" contexts, such as argument positions.
>
> - Cormac
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
12