On Sun, Jan 5, 2014 at 8:36 PM, Ben Kloosterman <[email protected]> wrote:
> On Mon, Jan 6, 2014 at 4:31 AM, Jonathan S. Shapiro <[email protected]>wrote: > Ben: We're having a persistent miscommunication about HAS-FIELD and interfaces. I want to try to clear it up. One or the other of us will learn something. Hopefully both! First: as a matter of *type*, the fact that object methods do not actually occupy storage in the object is an implementation matter. Such a method is still considered to be a member field of the object for typing purposes. Second: Following this logic, if HAS-FIELD takes the general form 'container HAS-FIELD "memberName" 'memberType then HAS-METHOD is merely HAS-FIELD with a kind constraint on the 'memberType. It's pure sugar. By contrast, HAS-STATIC-METHOD is *not* pure sugar. It's semantically distinct because there is actually no field relationship whatsoever between a static method and the struct type in whose namespace the static method resides. Third: interfaces do not subsume HAS-FIELD. An interface is constrained such that all of its members are required to be methods (or attributes, but those are methods). With some syntactic support you can kludge up something that looks syntactically like an actual member field, but it's a convenience hack - under the covers the interface members are still constrained to have method type. This is true because in its baseline conception an interface is an object consisting entirely of method delegates. So given a declaration like: struct S 'a { i : int; a: 'a; } the structure satisfies the constraint 'a has-field "i" int Note that an interface cannot describe a member of type "int". The more interesting question here is whether HAS-FIELD should apply to interface members. The question, really, is whether the presence of the existential is a distinction for typing purposes. The answer, *because* it is an unopened existential, is "no". Therefore, yes, HAS-FIELD should match interface members. Finally, on reflection, the use of the name HAS-FIELD leads indirectly to the very confusion we seem to be sorting out, I'm therefore inclined to rename it HAS-MEMBER. That's equally descriptive, but it doesn't pull in any intuitions about field storage that seem to be slightly implied by the name HAS-FIELD. Having said all that, it might conceivably be useful to match only interface members. I think the right way to do that is with a kind constraint: 'ContainerType :: Interface HAS-FIELD "name" 'FieldType > On Sat, Jan 4, 2014 at 5:57 PM, Ben Kloosterman <[email protected]>wrote: >> >>> Speaking of confusion if you keep HasField, then i would have a seperate >>> HasMethod . Keeping it seperate makes it very clear when your using a >>> method vs a delegate field. >>> >> >> I'm still not clear what you mean by a delegate field. But from a typing >> perspective what you propose is wrong. A method is simply a field having >> method type. >> > > Its a bit confusing because a field can hold a function pointer (delegate) > vs a method , both can be invoked , its obvious when you need a "this" but > less so for pure functions . > I've never understood why people think a function pointer is a delegate. A delegate is an *object* that encapsulates a method call. A function pointer is just a reference to a procedure object. > >> The one that's more interesting is has-static-method, because that one is >> not just sugar. >> > > Doesnt that overlap with a type class ? Its like a 1 function convenience > type class , how is that not Sugar ? > I don't see how. A type class expresses no notion of namespace containment, and a type class doesn't tell me whether a particular type is an instance of that type class. > > >> Should HasField be removed from the user and subsumed by interfaces ? >>> >> >> It can't be, because HAS-FIELD describes cases that interfaces do not, >> and interfaces are potentially matched by HAS-FIELD. >> > > Yes interfaces are likely built on HasField but that doesnt need to mean a > programmer can use it . > No no. Interfaces are *not* built on HAS-FIELD. They are potentially *matched* by HAS-FIELD. A constraint like: 'Type IMPLEMENTS 'Interface is a completely different constraint altogether. As a concrete example, that constraint is *not* good enough to explain forall 'a def getX a : 'a { a.x } > What set of uses of HasField can be done by interfaces ? > None. > Im asking because it reduces the when to use type class and when to use > interfaces question. > Well, given that the answer is "none", I'm not sure it tells us anything on this. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
