Colin Paul Adams wrote:

...

...

...

...

...

"Achim" == Achim Schneider writes:

Achim> OTOH, I don't like the idea of having to write "Attribute" Achim> all the time, and neither want to write pages of

Achim> attrKey = Attribute.key

Achim> for 1000-element records (or TH to tackle standard language Achim> problems, for that matter), so there has to be some way for Achim> library users to shorten code without being masochistic, Achim> somewhat like this:

Achim> A = Attribute

Nay, there's no tax on keystrokes.

Code is far more often read than written.

Say, did you ever read Java and wondered why you have to continuously scroll to the right albeit using a 500-column terminal? Exceedingly long names are fine to organise a large library, but becomes burdensome when code only uses a subset of it... which is usually the case. _both_ in reading and writing. The longer identifiers are, the shorter information distance between two related ones tends to be, as in generateMapThatTakesAFooAndReturnsABarBydoingBaz vs. generateMapThatTakesAFuAndReturnsABarBydoingBaz compare this with locally-defined aliases mapOfFoo and mapOfFu Short notation isn't the problem, missing explanation of it is.[1] Currently, you can observe stuff like data Abst -- raction = Foo | Bar in my code. I don't mind making that a language feature for increased profit. Anyway, my code tends to get refactored more than being read or written. I want to finish typing _before_ the next idea kicks in. [1] This, as a side note, also tends to make me hate academics. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

On Fri, Jan 2, 2009 at 9:21 PM, Miguel Mitrofanov wrote:

module Element where import QName import ... data Element = Element {name :: QName, attribs :: [Attr], content :: [Content], line :: Maybe Line}

module Attr where import QName import ... data Attr = Attr {key :: QName, val :: String}

module QName where import ... data QName = QName {name :: String, uri :: Maybe String, prefix :: Maybe String}

module Main where import qualified QName as Q import qualified Element as E ... Q.name ... E.name ...

I'm using this pattern of writing code and, so far, I find it very convenient. Yet, the code is likely to be spread across lots of files, which is not always a Good Thing. Cristiano

On Fri, 2009-01-02 at 23:48 +0300, Miguel Mitrofanov wrote:

...

...

module Main where import qualified QName as Q import qualified Element as E ... Q.name ... E.name ...

I'm using this pattern of writing code and, so far, I find it very convenient. Yet, the code is likely to be spread across lots of files, which is not always a Good Thing.

That's a completely different matter. Personally, I think that holding each module in a separate file is not a great idea.

+1 jcc

Isaac Dupree writes:

Derek Elkins wrote:

...

I haven't been able to find any semantic difficulties with this addition.

I like it too... what I run into is that there's an implicit assumption that module of name Foo.Bar.Baz *must* be found in a file Foo/Bar/Baz.[l]hs .

Ah, surely mere practicalities will not stand in the way of improving the usability of the language?

GHC uses this all the time

..unless you want a compiler, I guess. How about this: 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). -k -- If I haven't seen further, it is by standing in the footprints of giants

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 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

Isaac Dupree writes: My proposal:

...

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.

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)

This has been requested on and off, typically exposing internals for testing purposes.

- 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")

My choice would be to be cavalier about it, and sweep these under the orthogonality carpet :-) I'm not convinced they would complicate things - not a lot, at any rate. If possible the system should be designed so that sub-modules should behave just as if they were defined in files in the appropriate subdirectory. Is it possible? OTOH, a bonus would be that you might avoid the need to bootstrap recursive modules if you put them in the same file?

and as we already mentioned, it would likely involve some implicit importing of the sub-module.

I must have missed this, could you help me with a pointer?

I think my module-search mechanism makes a well-defined, deterministic way to find the right module

Yes.

Implicit importing: submodule syntax implies adding an "import The.Module.Name" line at that point in the containing file.

I'm not sure I agree with that, I don't see why we shouldn't treat these modules as ordinary modules. One of the motivations for doing this is to qualify record labels - not being able to specify "import .. qualified" or "as ..." seems like rather a loss.

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.

Which is? Do we avoid one pass, or what?

so an example could be

module MyData ( module MyData.Sub, -- or equivalently, D(..) transform ) where -- so I would require this as well, import MyData.Sub (transform, D(..))

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

Another example: ------------------------------ module Foo where import qualified Foo.Bar as Bar import Foo.Zot f z = x z -- z = Zot.z, f :: Z -> Float g b = Bar.x b + Bar.y b ... module Foo.Bar where data B = B { x, y :: Int } ... module Foo.Zot where data Z = Z { x :: Float } ... ------------------------------ I'd make an exception for Main, which would count as no top-level module, and thus allow module Main where import ... import Sub ... module Sub where -- not Main.Sub, but possibly FileName.Sub? import ... ... -k -- If I haven't seen further, it is by standing in the footprints of giants

Achim Schneider writes:

...

...

Implicit importing: submodule syntax implies adding an "import The.Module.Name" line at that point in the containing file.

...

I'm not sure I agree with that, I don't see why we shouldn't treat these modules as ordinary modules.

import [qualified] module Foo [as F] [hiding(baz)] where bar = undefined baz = bar

Why do you want the 'where' there? Why not simply treat a file Foo.Bar as a concatenation of module Foo.Bar and optionally modules Foo.Bar.*?

OTOH, the Ocaml folks are going to ridicule us even more. "Now they redid the module system, and it's still second-class"

Well, they would be wrong, wouldn't they? I don't want to "redo" the module system, and in fact, I think my proposal wouldn't change the language at all, merely how the compiler searches for modules. (Which it would be nice if the compilers agreed upon, of course.) -k -- If I haven't seen further, it is by standing in the footprints of giants

Achim Schneider wrote:

Ketil Malde wrote:

...

Achim Schneider writes:

...

import [qualified] module Foo [as F] [hiding(baz)] where bar = undefined baz = bar

Why do you want the 'where' there? Why not simply treat a file Foo.Bar as a concatenation of module Foo.Bar and optionally modules Foo.Bar.*?

Because the module definition syntax is "module Foo[(exports] where"... technically, it's not necessary, but it's nice.

Additionally, I don't think concatenation works well here, n-ary trees work better. module Foo where import module Bar where import module Baz where quux = undefined quux' = quux . quux quux'' = quux' . quux' quux''' = quux'' . quux'' would be nice. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

Ketil Malde wrote:

...

...

Achim Schneider writes:

...

...

...

import [qualified] module Foo [as F] [hiding(baz)] where bar = undefined baz = bar

...

...

Why do you want the 'where' there?

...

Because the module definition syntax is "module Foo[(exports] where"... technically, it's not necessary, but it's nice.

Right - I missed the 'module' and just read it as an import statement. Clearly your proposal here goes beyond mine, what are the advantages? I.e, what's the rationale for syntactical changes instead of

module Foo where [...] import Foo just doesn't look elegant to my eyes so I'd like to have it in one statement, that's all. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.