Hi Vass - Firstly, I'm not convinced think that the current state of affairs (assignment or = on records is structural, everything else is nominative) has any productivity benefits. I am willing to listen to an argument that a fully structural type system has productivity benefits, but my opinion is that you win some and lose some. I don't know of any programs where = on records being structural (and nothing else) is enough to give a productivity benefit. It seems to me you'd also need function resolution to specially handle record arguments for that strategy to make any sense. (In other words, right now records are mostly nominative and just a little bit structural; I think they should be one way or another).
The upcoming interfaces have nominative typing (as I recall) in order to fit in with the rest of Chapel but I don't think it would be very hard to make them structural. If we did that, though, we'd still want to have some sort of way of tagging a structural interface to indicate some usage information; so that an interface like 'Copyable' or 'Serializeable' might indicate that those things should work, even if all objects have the required methods and the interfaces are empty. But - at the end of the day - I'd like somebody to explain with a real/concrete example in what way a structural type system or just a structural = on records makes a program easier to write. I'm not convinced by the mere assertion that it has productivity benefits... Show me. :) -michael On 01/03/2014 04:37 PM, Vassily Litvinov wrote: > [removing the chapel-bugs list] > > On 01/03/2014 07:40 AM, Michael P. Ferguson wrote: > > > [...] >> Lastly, I think it's confusing that in this one way we have a structural >> type system, >> where the rest of the Chapel type system is nominative. [...] > > I agree. Towards that end, we all have played with the idea of a "use" clause > inside a record or class declaration, which incorporates the other record's > fields but does not create a subtype of that record. > > To be fair, a structural type system has ease-of-programming aka productivity > benefits, and I think Brad likes those. So I'd say that ideally we'd provide > them in Chapel as well. In which case they need to be clearly distinguished > from the nominative universe. Maybe they could be based on Michael&Jeremy's > interfaces? > > Vass ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
