[Haskell-cafe] Use of abbreviations in Haskell

[Derek Elkins]

On Fri, 2009-01-02 at 15:20 +0100, Felix Martini wrote:
> Hi all,
> 
> There is currently a discussion on reddit/programming about Haskell.
> One complaint is that Haskell functions often use abbreviated names. I
> tend to agree with that. In my personal experience it generally takes
> more time to learn a third party Haskell library than libraries
> written in other languages. I am not sure why but it could be because
> of function names. It seems to me that Haskell's current record syntax
> enhances this. Take for example the new xml library,
> 
> data Element = Element {
>   elName :: QName
>   elAttribs :: [Attr]
>   elContent :: [Content]
>   elLine :: Maybe Line
> }
> 
> data Attr = Attr {
>   attrKey :: QName
>   attrVal :: String
> }
> 
> data QName = QName {
>   qName :: String
>   qURI :: Maybe String
>   qPrefix :: Maybe String
> }
> 
> Personally i would prefer it to be something like
> 
> data Element = Element {
>   name :: QualifiedName
>   attributes :: [Attribute]
>   content :: [Content]
>   line :: Maybe Line
> }
> 
> data Attribute = Attribute {
>   key :: QualifiedName
>   value :: String
> }
> 
> data QualifiedName = QualifiedName {
>   name :: String
>   uri :: Maybe String
>   prefix :: Maybe String
> }
> 
> but the global scope of the record field names doesn't allow that 

They are not global.  They are scoped to the module just like any other
function definition.  So if you were to put each record in it's own
module you can have Attribute.key today.  No one does this though
because that's rather heavy-weight.

I've suggested in #haskell a few times an orthogonal language feature
that will resolve this as well as providing other nice things and, being
orthogonal, it keeps namespacing to namespacing mechanisms (namely
modules.)  The feature is simply local modules.

You'd get what you want by simply writing,

    module Attribute where
        data Attribute = Attribute {
            key :: QualifiedName,
            value :: String
          }

I haven't been able to find any semantic difficulties with this
addition.  There are some choices, namely what to import and export by
default and some scoping issues.  My choices would be to import
everything in scope at the module declaration, the containing module
tacitly imports everything the contained module exports, the same
notation Module.name is used so a local module would shadow a top-level
(hierarchical) module of the same name (though I don't expect that to be
a common case.)  With these conventions there would often be nominal
mutual recursion between local modules at the same level.  The
implementation could either check to see if there is any actual mutual
recursion and give an error, or, much more preferably, simply allow
mutually recursive local modules as this should be much easier to handle
than mutually recursive top-level modules.

Some other benefits of this would be a nice way to make abstract data
types, which are also underused due to the heaviness of the module
system.  You could write, for example,

    module Stack (Stack, empty, push, pop, isEmpty) where
        newtype Stack a = Stack [a]
        empty = Stack []
        push x (Stack xs) = Stack (x:xs)
        pop (Stack (x:xs)) = Just (x, Stack xs)
        pop (Stack []    ) = Nothing
        isEmpty (Stack xs) = null xs

It should be straightforward to implement this today as a pre-processor
at the cost of not allowing local modules with the same qualified name
as a top-level module and losing some encapsulation.  The pre-processor
would simply need to extract all the local module declarations and make
the appropriate hierarchical modules and add the appropriate import
statements.  The easiest and most restrictive way to deal with mutual
recursion in this case is simply have a local module only import it's
ancestor modules and any modules explicitly imported.  The benefit of
this approach is that it doesn't require any kind of analysis, it could
be done on an almost purely textual basis.

> 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?
> 
> 
> Regards,
> Felix
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe