tag:blogger.com,1999:blog-3083788237966827171.post2008299119303201836..comments2023-11-03T04:16:02.546-07:00Comments on Jesper's Blog: Type Lists and Heterogeneously Typed ArraysJesper Nordenberghttp://www.blogger.com/profile/07589508061874776093noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-3083788237966827171.post-5432788666811483502010-02-26T15:51:52.284-08:002010-02-26T15:51:52.284-08:00Hello Ralf,
Lots of questions, I'll try to an...Hello Ralf,<br /><br />Lots of questions, I'll try to answer to my best ability :)<br /><br />> How would you model TIPs or TICs or Records?<br /><br />I'm not familiar with TIPs and TICs. Care to elaborate? <br /><br />As for records they can be modelled similar to objects (see OO.scala), ie a field is a unique type.<br /><br />> Perhaps you want to add some comments to OO.scala?<br /><br />I thought it was self explanitory ;) Basically an object is a HList of methods where each method has a unique type. Method dispatch is simply a lookup by type and a call to the corresponding function object. Overriding methods is simply a "replace by type" operation. <br /><br />> I can see from GetByType (HLists.scala) & friends how you deal with type equality.<br /><br />Unfortunately type equality can't be modeled on a pure type level in Scala (this has been discussed on the mailing lists). This makes it impossible to create a generic type set for example.<br /><br />> What is the GetByType operation good for?<br />> I think it looks up the n-th occurrence of a given type in an HList.<br />> Is that something useful?<br /><br />Yes, it's useful for object method overriding for example.<br /><br />> Why not do something like HOccurs early on instead?<br /><br />I'm not sure what you mean by this.<br /><br />> Why make a value-level Int a required constructor argument of Succ?<br />> Shouldn't this value-level value always implied (as later done with views)?<br /><br />I added this constructor arg afterwards because, I think, it eliminates the need for an additional implicit parameter when passing a Nat object as parameter.<br /><br />> Why have both If and If2 in Booleans?<br />> It looks like If2 is more well-behaved.<br />> So is there any reason to keep If?<br /><br />As you write, If2 is needed in some cases to make code type safe as it specifies a common super type bound. In some cases If is sufficient though and there's no need to use the more complex If2.<br /><br />> What is trait IfTrue for?<br />> (It's never used in HLists.scala.)<br /><br />Good question. Can't remember why I added that.<br /><br />> Why is Head of HNil Nothing?<br />> Why is Tail of HNil HNil?<br />> Wouldn't it be better to leave these type-level operations out of HNil?<br /><br />Yes, optimally these type members would not be part of HList nor HNil, but I think I ran into some type problems when I tried to model it this way. Don't remember exactly where though.Jesper Nordenberghttps://www.blogger.com/profile/07589508061874776093noreply@blogger.comtag:blogger.com,1999:blog-3083788237966827171.post-26156446301603216472010-01-02T19:00:33.543-08:002010-01-02T19:00:33.543-08:00How would you model TIPs or TICs or Records?
Perha...How would you model TIPs or TICs or Records?<br />Perhaps you want to add some comments to OO.scala?<br />I can see from GetByType (HLists.scala) & friends how you deal with type equality.<br />So do you want to propose a TIP & TIC like structure?<br />It is not so obvious how you would do this.<br />But I am counting on it to be feasible and you able to do it!<br /><br />Less important:<br /><br />What is the GetByType operation good for?<br />I think it looks up the n-th occurrence of a given type in an HList.<br />Is that something useful?<br />Why not do something like HOccurs early on instead?<br /><br />Why make a value-level Int a required constructor argument of Succ?<br />Shouldn't this value-level value always implied (as later done with views)?<br /><br />Even less important:<br /><br />Why have both If and If2 in Booleans?<br />It looks like If2 is more well-behaved.<br />So is there any reason to keep If?<br />What is trait IfTrue for?<br />(It's never used in HLists.scala.)<br /><br />Why is Head of HNil Nothing?<br />Why is Tail of HNil HNil?<br />Wouldn't it be better to leave these type-level operations out of HNil?Ralf Lämmelhttps://www.blogger.com/profile/11811593229142993414noreply@blogger.comtag:blogger.com,1999:blog-3083788237966827171.post-72321525606917657242009-09-27T10:39:13.649-07:002009-09-27T10:39:13.649-07:00Thanks, Jesper. That seems to do the trick.Thanks, Jesper. That seems to do the trick.Anonymoushttps://www.blogger.com/profile/03350776762967743057noreply@blogger.comtag:blogger.com,1999:blog-3083788237966827171.post-47561279896554773702009-09-26T01:57:45.737-07:002009-09-26T01:57:45.737-07:00@Rafael:
Yes, containsFn and isSubSetFn are implic...@Rafael:<br />Yes, containsFn and isSubSetFn are implicits that can are used when creating functions that checks for membership and sub set relationship. I don't think it's possible to write these as pure type functions as there is no way to perform type equality checks (see discussion on the mailing list, http://thread.gmane.org/gmane.comp.lang.scala/17474/focus=17481).<br /><br />You can find some example uses in OneOfs.scala which models simple generic type unions. To check if two TLists contains the same elements one can do:<br /><br />def areEqual[T1 <: TList, T2 <: TList](implicit s1 : IsSubSetFn[T1, T2], s2 : IsSubSetFn[T2, T1]) = ...<br /><br />It's quite unfortunate that this function can't be written on a pure type level.Jesper Nordenberghttps://www.blogger.com/profile/07589508061874776093noreply@blogger.comtag:blogger.com,1999:blog-3083788237966827171.post-74818977870287873032009-09-25T22:32:19.611-07:002009-09-25T22:32:19.611-07:00Metascala is indeed awesome.
I'm having diffi...Metascala is indeed awesome.<br /><br />I'm having difficulties grasping how to use containsFn and isSubSetFn "predicates" (for lack of a better word). They appear to be tools for statically checking whether a given TList contains a type T or is a superset of another given TList. But <br /><br />containsFn[Int, MyTList] <br /><br />just seems to build a new ContainsFn[Int, Int :: MyTList] regardless of whether MyTList contains or doesn't contain Int.<br /><br />My immediate goal is have a method that takes two TLists as parameters and fails do compile if they don't represent the same list of types. It's not clear to me if the Utils.Equal can help in this case.Anonymoushttps://www.blogger.com/profile/03350776762967743057noreply@blogger.comtag:blogger.com,1999:blog-3083788237966827171.post-8002762685144005692009-09-18T00:53:24.871-07:002009-09-18T00:53:24.871-07:00Awesome!
I've also found something like Scala...Awesome!<br /><br />I've also found something like ScalaNLP's HTMap (map of types to values of that type) very useful. See: http://github.com/dlwh/scalanlp-core/blob/master/src/main/scala/scalanlp/collection/immutable/HTMap.scalaJorge Ortizhttps://www.blogger.com/profile/14454965475839432618noreply@blogger.comtag:blogger.com,1999:blog-3083788237966827171.post-42652314772621139812009-09-14T09:48:57.726-07:002009-09-14T09:48:57.726-07:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3083788237966827171.post-46518492280957350852009-09-14T09:28:58.443-07:002009-09-14T09:28:58.443-07:00cool stuff man!cool stuff man!Luc Duponcheelhttps://www.blogger.com/profile/09285501928970939466noreply@blogger.com