On 7 April 2011 14:33, Doug McIlroy <d...@cs.dartmouth.edu> wrote: > This supposition is unwarranted. We have all seen relative naming > systems that run both ways: a.b.c versus c(b(a)). And Haskellites > would simplify the latter to c$b$a. Secondary storage may be > organized by files, segments, objects, etc. Combinations of these > notions have been created in order to cater for legacy languages > that depend on particular models. > > It is a step too far to try to predict how Haskell modules will > be adopted into every possible naming environment.
The proposal doesn't try to regulate the use of Haskell modules in every possible naming environment. Just file systems. And there only as a set of guidelines. To quote Duncan Coutts previously in this thread: "I hope I was clear in the example text that the interoperability guidelines were not forcing implementations to use files etc, just that if they do, if they uses these conventions then sources will be portable between implementations. It doesn't stop an implementation using URLs, sticking multiple modules a file or keeping modules in a database." _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
