[Grace-core] Typing Collections

Kim Bruce kim at cs.pomona.edu
Tue Jul 15 23:51:49 PDT 2014


As you might guess, this is something I struggled with as well -- and in fact came up with different decisions from the original when working today looking at fixed sized arrays (an interesting exercise for exercising the compiler even if we don't put them in the language).

I believed the version that I had in the listsNsets module was internally consistent -- i.e., the with and withAll work the same for all the kinds of objects.  However, I now see that it does crash when I try to construct a list (though I'm puzzled as to why -- the complete error message is "Runtime error around line 792, which is the line with the constructor.)  Pointers to my error are appreciated.

I must admit that I am one who is highly dependent on good static type systems to check my work, and the "structural" dialect crashes badly (with a called exception that had no useful information) when I tried checking listsNsets in that dialect.  I haven't had a chance to try to narrow down the problem there, alas.

I think the main problem with the current formulation, as noted by Andrew, is that you can't really erase the type parameters in the dynamic version and have it read reasonably.  As a result, I believe that Andrew's proposed formulation makes the most sense for a language with flexible typing.

Kim



On Jul 15, 2014, at 11:09 PM, James Noble <kjx at ecs.vuw.ac.nz> wrote:

>>    def oneToFive = list.with<Number>(1, 2, 3, 4, 5)
> 
> this is what I'd expect, or the dotless alternative list<Number>(1, 2, 3, 4, 5)
> 
>> If we keep the extra compelexity of type parameters, I want a payoff — the payoff being, in this case, that typed and untyped programs differ only in the presence of
>> their types.
> 
> right.  That indeed is the only justification for keeping separate type parameter syntax.
> 
>> Previously, I argued for getting rid of type parameters as a special case and just using ordinary method parameters
> 
> yep, that doesn't work with ordinary method paramemters.
> if we adopted some version of "generalised requests" that had optional name+parameter parts
> then those types could be ordinary optional method parameters
> https://projects.cecs.pdx.edu:8443/~black/NewOOL/index.cgi/wiki/GeneralisedMessages
> 
> James, sporadically
> 
> 
> 
> (because I'm still wondering, here's that in the [[ ]] syntax)
> 
>> def oneToFive = list.with[[Number]](1, 2, 3, 4, 5)
> 
>> list[[Number]](1, 2, 3, 4, 5)
> 
> Hmmm. 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core




More information about the Grace-core mailing list