[Haskell-cafe] Re: Use of abbreviations in Haskell
"Felix Martini" wrote:
> [..]
>
> data QualifiedName = QualifiedName {
> name :: String
> uri :: Maybe String
> prefix :: Maybe String
> }
>
> but the global scope of the record field names doesn't allow that and
> therefore all kinds of abbreviations are inserted in front of the
> record field names which are hard to remember. So a better record
> syntax would be welcome. Perhaps the constructor could be used to
> limit the scope of the record field name e.g. QualifiedName.prefix?
>
/me votes for introducing
> data Attribute = Attribute {
> Attribute.key :: QualifiedName
> Attribute.value :: String
> }
It's surely gonna be used, and iff it becomes exceedingly wide-spread,
it can be made default (in 10 years or so).
OTOH, I don't like the idea of having to write "Attribute" all the
time, and neither want to write pages of
attrKey = Attribute.key
for 1000-element records (or TH to tackle standard language problems,
for that matter), so there has to be some way for library users to
shorten code without being masochistic, somewhat like this:
A = Attribute
, that is, allow definition of data constructors in usual declarations,
up to some limits.
--
(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.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Use of abbreviations in Haskell
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Use of abbreviations in Haskell
Derek Elkins wrote:
> module Attribute where
> data Attribute = Attribute {
> key :: QualifiedName,
> value :: String
> }
+1
Assuming that the above definition is inside a file called Foo/Bar.hs
and, syntactically, inside a "module Foo where", I think a sane way to
search for the module Foo.Bar.Attribute is
a) Foo.Bar.Attribute.hs
b) Foo/Bar.Attribute.hs
c) Foo/Bar/Attribute.hs
d) Foo.Bar.hs:Attribute
e) Foo/Bar.hs:Attribute
...I guess you see a pattern emerging. It's not entirely unlike public
inner java classes[1]
The reason that the Main module is an exception to the naming/placement
rules is that it's _always_ the root of the search tree, which is only
confusing if you insist on being confused by it[2].
Furthermore, if you
import Foo.Bar
, you get Attribute.(..) imported by default, _except_ if you also do
import [qualified] Foo.Bar.Attribute [as A]
This fixes both the insanity of having thousands of three-line modules
in thousands of files (which noone wants to manage) and source
directories consisting of more directories than files.
[1]uhmm... can inner classes be public? I think I never tried...
[2]like javac chooses to be.
--
(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.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Use of abbreviations in Haskell
Ketil Malde wrote: > > 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. import [qualified] module Foo [as F] [hiding(baz)] where bar = undefined baz = bar OTOH, the Ocaml folks are going to ridicule us even more. "Now they redid the module system, and it's still second-class" -- (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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Use of abbreviations in Haskell
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. > > 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.) > It's just that inline modules, especially that syntax above, reminded me of Ocaml. It's not far from there to foo = module Foo where bar = undefined import foo -- (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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Use of abbreviations in Haskell
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Use of abbreviations in Haskell
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Use of abbreviations in Haskell
> "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. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Use of abbreviations in Haskell
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Use of abbreviations in Haskell
>> 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 >> simply treat[ing] a file Foo.Bar as a concatenation of module >> Foo.Bar and optionally modules Foo.Bar.*? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
