Cafe, I was going to write about this earlier, but I'm so ill read on the record selector papers that I deleted the draft.
My proposal would be for each selector name to be a special type of "phantom" type class (existing in the intermediate language only). This type class would not be accessible by the programmer and thus s/he couldn't make a polymorphic function for which specialization would be needed. In other words - in normal circumstances there is no need for dictionaries and thus no run-time difference between this method and using different record names. Example: > data IPv4Hdr = Hdr4 { src, dst :: IPv4 } > data IPv6Hdr = Hdr6 { src, dst :: IPv6 } > > func4 :: IPv4Hdr -> IO () > func4 hdr = do > let s = src hdr > ... > > func6 :: IPv6Hdr -> IO () > func6 hdr = do > let s = src hdr > ... At some intermediate stage you'd see: > class Src h s where > src :: h -> s > class Dst h d where > dst :: h -> d > > instance Src IPv4Hdr IPv4 where > src (IPv4 s _) = s > instance Dst IPv4Hdr IPv4 where > dst (IPv4 _ d) = d > -- repeat for IPv6 The only point of frustration I see is if the programmer manually makes both data types an instance of a programmer-visible type class, thus making a polymorphic function. > class IPHdr a > instance IPHdr IPv4Hdr > instance IPHdr IPv6Hdr > > sendPing :: (IPHdr a) => a -> IO () > sendPing p = networkSend (dst p) pingPayload In this case I'd vote for specializing the function so there still aren't any extra dictionaries, but I know that is not always optimal. Tom On Sat, Jan 3, 2009 at 10:08 PM, Isaac Dupree <m...@isaac.cedarswampstudios.org> wrote: > Ketil Malde wrote: >> A module may be defined in a file with a name corresponding to the >> module name, or any dot-separated prefix of it? I.e. the file >> Foo/Bar.hs will define module Foo.Bar and optionally Foo.Bar.Baz as >> well? >> >> GHC should then be able to find it, and I believe it already has a >> prioritized search mechanism (presumably, the file could be named >> Foo.Bar.hs, too). > > I don't think GHC actually allows that (Foo.Bar.hs, ever). But your suggestion > could work. > > 1. Try Foo/Bar/Baz.hs ; if it exists, end search (and error if it does not > contain Foo.Bar.Baz, obviously as the file's top-level module). > 2. Try Foo.Bar.hs ; if it exists, end search (and error if it does not contain > Foo.Bar.Baz, obviously as a sub-module). > 3. Try Foo.hs ; if it exists, end search (and error if it does not contain > Foo.Bar.Baz, obviously as a sub-module... or possibly as a sub-sub-module?). > 4. give up :-) > > Note though, that local modules tempt us to a couple other things too, even > though they're not necessary to the proposal and would complicate it: > - access-controlled modules (e.g. if other code can't import Foo.Bar.Baz) > - relative-path imports / module names (e.g. if in Foo/Bar.hs we make Baz and > try to import it some way with "import Baz") > > and as we already mentioned, it would likely involve some implicit importing > of the sub-module. > > translating into ordinary haskell: > I think my module-search mechanism makes a well-defined, deterministic way to > find the right module, no complex translation necessary (except layout rule > madness maybe?). > Implicit importing: submodule syntax implies adding an "import > The.Module.Name" line at that point in the containing file. This would > suggest > that submodules must be at the top, among the imports, because all imports > must syntactically be at the beginning of the file -- and there's a reason for > this. Bother! Even if the reason is dependency chasing, one would think > same-file dependencies aren't important, but the submodules themselves can > import things from other files, so those lines should need to be near the > beginning anyway. > > so an example could be > > module MyData > ( > module MyData.Sub, -- or equivalently, D(..) > transform > ) > where > > module MyData.Sub --or "module Sub" ?? that seems a bit too ad-hoc though > where > data D = E | F > > transform :: D -> D > transform F = E > transform E = F > > > ~Isaac > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe