Back to Questions
1.4k
views3
comments
Nominative vs. Structural types
f#

I came across a case where it would be really convenient to have an inferred interface (structural typing). It seems that this has been discussed before here:

[link:cs.hubfs.net]

Will F# ever become structural typed line OCaml? Given that things like this often have undesirable effects in corner cases, is this even desirable in F#?

Is there anyway to simulate this in a nominative type system? Basically, I'd like to have a function take a complicated class instead of N arguments. But, I want to avoid the ugly (in this case) explicit base type.

.

Correct me if I'm wrong, but it seems that mostly what people want is to be able to abstract over a number of existing types in some way unforeseen by the original designer of those types.Structural subtyping aka ducktyping is but one way to skin this cat.Any open extension mechanism can deal with this. For example if you would be able to implement an interface on some existing types post hoc, that would solve your problem using nominative typing.I think some open form of overloading like type classes also provide a solution.A "dynamic" keyword, like in C#, also solves it.There may be others, still.To answer your second question: there is reflection (there's a link in the thread you mention), and you could have a look at [link:www.atrevido.net]

By on 3/3/2009 12:38 AM ()

The underlying problem is that the CLR won't help out. We could easily imagine some sort of "extension interfaces", but without CLR support, it's painful.

Reflection/dynamic lose type safety, so I don't think it's much of a worthwhile approach. (Although, it might be the only option sometimes :)).

F#'s approach, inlining with member constraints is one way.

Another other way that occurs to me right now is that the compiler could generate a wrapper interface and use it at the callsite. Similar to how you can do that now with an object expression -- just done automatically. That might be the easiest "cross-language" way of accomplishing this.

By on 3/3/2009 12:46 AM ()

you could have a look at [link:www.atrevido.net]

After I posted, I had a thought that structural typing could be implemented with inline macros ...if only such a construct existed in f#! :)

I have to play around with it somewhat to see if it meets my needs fully. (i.e. works well with C#, handles changes in an expected way, etc.).

the compiler could generate a wrapper interface and use it at the callsite

I think that could work too, and it would solve the problem of interacting with other .NET code. But, you are still hacking a structural type system on top of a nominative system. You would still have to implement the interface. So, I don't know if you could ensure equivalence among modules with the ``same'' types compiled at different times without knowledge of each other.

Reflection/dynamic lose type safety, so I don't think it's much of a worthwhile approach.

As a rule, I try to stay away from specifying things at runtime. While reflection is great for doing some things, it leaves me with an uneasy feeling that my tests may not have executed every path of code.

By on 3/3/2009 8:39 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper