Good Haskell Style

[Thomas Schilling-2]

On 2 aug 2007, at 09.50, Simon Peyton-Jones wrote:
> Is there an emacs mode or Lisp-blob that lets you use TAB to go to  
> the next n-col boundary, but expands the jump into spaces.
>
> In emacs modes, TAB usually does all sorts of other snazzy things  
> concerning layout, which I don't want.  I just want something that  
> behaves like old-fashioned TAB, but generates a file with spaces.

This should work:

;; tabs are evil, always use spaces instead
(setq indent-tabs-mode nil)

;; in your haskell-mode-hook:
   (define-key haskell-mode-map [tab] 'indent-for-tab-command)


Regards,
/ Thomas

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Simon Marlow-5]

Thomas Schilling wrote:

> On 2 aug 2007, at 09.50, Simon Peyton-Jones wrote:
>> Is there an emacs mode or Lisp-blob that lets you use TAB to go to the
>> next n-col boundary, but expands the jump into spaces.
>>
>> In emacs modes, TAB usually does all sorts of other snazzy things
>> concerning layout, which I don't want.  I just want something that
>> behaves like old-fashioned TAB, but generates a file with spaces.
>
> This should work:
>
> ;; tabs are evil, always use spaces instead
> (setq indent-tabs-mode nil)
>
> ;; in your haskell-mode-hook:
>   (define-key haskell-mode-map [tab] 'indent-for-tab-command)

While we're on emacs... I know I can colour trailing whitespace
differently, but that's just annoying.  What I want is: on lines that I
edit, remove the trailing whitespace (and if I undo the edit, put the
whitespace back too).  Is there something that does that?  I couldn't find it.

Cheers,
        Simon
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Jon Fairbairn]

David Roundy <droundy@...> writes:

> Trailing white space doesn't particularly hurt, except if you're using
> version control, in which case any removal of white space is liable to
> conflict with actual coding changes, so it's better to have a policy that
> it shouldn't be included.

This is surely an issue with either the language definition
or the version control system.  In general, we ought to aim
for a state of affairs where every requirement we make is
mechannically checked. In this particular case, I'd say that
the version control system ought to be more syntactically
aware when looking for differences¹, for example by removing
all trailing space before doing comparisons (and making sure
that anything extracted from the repo has none).

>  I've certainly never heard of a scenario in which
> trailing white space is beneficial.

Neither have I, but since it's invisible, asking that it not
be there without providing automatic mechanical assistance
is to add a tedious burden.

[1] this isn't the only place where a version control system
that understood more of the language would be useful: for
example, rather than having to specify a regexp, I'd like
darcs replace to pick one (from a configuration file?)
depending on language.

--
Jón Fairbairn                                 Jon.Fairbairn@...


_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

On Thu, 2007-08-02 at 08:51 +0100, Bayley, Alistair wrote:

> > From: libraries-bounces@...
> > [mailto:libraries-bounces@...] On Behalf Of Isaac Dupree
> >
> > And prefer to indent an even number (normally an even number
> > of spaces,
> > but, an odd number when using birdtrack-literate-haskell '>
> > foo = ...').
>
> I moot that birdtrack-literate-haskell should be avoided, largely
> because (AFAICT) it is not supported by Haddock.

Doesn't Cabal handle this transparently? I thought it did. If you find
it doesn't please file a bug against Cabal.

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Alistair Bayley]

> > I moot that birdtrack-literate-haskell should be avoided, largely
> > because (AFAICT) it is not supported by Haddock.
>
> Doesn't Cabal handle this transparently? I thought it did. If you find
> it doesn't please file a bug against Cabal.
>
> Duncan

I didn't think it would work, because presumably it just invokes Haddock anyway.

So I just tried it, and got:
dist\build\tmp\Database\Enumerator.hs:"dist\\build\\tmp\\Database\\Enumerator.hs":
187:1: Parse error

and the offending lines in this file are:

#ifndef __HADDOCK__
    deriving (Functor, Monad, MonadIO, MonadFix, MonadReader sess)
#else
    -- Haddock can't cope with the "MonadReader sess" instance
    deriving (Functor, Monad, MonadIO, MonadFix)
#endif

so it would appear that __HADDOCK__ is not defined. But there's a
bigger problem, in that this Enumerator.hs file is obviously the
output of "ghc -E Enumerator.lhs -o Enumerator.hs", as it does not
contain any of the original comments, which again is no good for
Haddock.

Am I using birdtrack-lhs the wrong way? I've written my Haddock
comments like so:

| Returns the number of rows affected.

> execDML :: IE.Command stmt s => stmt -> DBM mark s Int

and:

|
Module      :  Database.Enumerator
Copyright   :  (c) 2004 Oleg Kiselyov, Alistair Bayley
License     :  BSD-style
...

But now I'm thinking that perhaps I should have written:

> --| Returns the number of rows affected.
> execDML :: IE.Command stmt s => stmt -> DBM mark s Int

which kinda defeats the purpose of the birdtrack style.IMO.

Alistair
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Alistair Bayley]

> and the offending lines in this file are:
>
> #ifndef __HADDOCK__
>     deriving (Functor, Monad, MonadIO, MonadFix, MonadReader sess)
> #else
>     -- Haddock can't cope with the "MonadReader sess" instance
>     deriving (Functor, Monad, MonadIO, MonadFix)
> #endif
>
> so it would appear that __HADDOCK__ is not defined.

Sorry, I should have said, "so it appears that -cpp is not being used".

Alistair
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Thomas Schilling-2]

On 2 aug 2007, at 12.10, Simon Marlow wrote:
> While we're on emacs... I know I can colour trailing whitespace  
> differently, but that's just annoying.  What I want is: on lines  
> that I edit, remove the trailing whitespace (and if I undo the  
> edit, put the whitespace back too).  Is there something that does  
> that?  I couldn't find it.

The simplest thing I can think of, is to not remove whitespace at  
all, but to only remove it when you're saving the file.  I know that  
some modes use such a save hook.  It also wouldn't modify the actual  
file (ie, don't remove the whitespace until you save the file for the  
first time), as long as you edit it.  The only time the spaces would  
be removed permanently were if you save the file, close the buffer,  
and then re-open the file.

If I can come up with a simple solution, I'll let you know.

/ Thomas
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

On Thu, 2007-08-02 at 13:58 +0100, Alistair Bayley wrote:

> > and the offending lines in this file are:
> >
> > #ifndef __HADDOCK__
> >     deriving (Functor, Monad, MonadIO, MonadFix, MonadReader sess)
> > #else
> >     -- Haddock can't cope with the "MonadReader sess" instance
> >     deriving (Functor, Monad, MonadIO, MonadFix)
> > #endif
> >
> > so it would appear that __HADDOCK__ is not defined.
>
> Sorry, I should have said, "so it appears that -cpp is not being used".

It uses -cpp if CPP is in the language extensions in the .cabal file.

(At least that's what the code says it's supposed to be doing which is
not a guarantee that it works).

It does also define __HADDOCK__ when it uses cpp.


Hmm, actually there is a problem here. Unlitting does indeed remove all
the literate comments, so haddock will never see any markup that is put
in the non-code part. To work with current haddock it'd have to be:

> -- | This is a haddock comment
> foo = ...

because that's the only code haddock will see since unlitting turns a
literate haskell file into a valid .hs file. It's a purely textual
transformation and it's done by removing all the non > lines.

Perhaps unlitting should be done by converting all literate comments
into {- ... -} style comments. Then it'd probably work with haddock like
you have it now:

| haddock comment

> foo = ...

since that'd become:

{- | haddock comment -}

foo = ...


Or something like that. Perhaps that's worth investigating and adding to
ghc/cpphs or Cabal's own existing pure Haskell impl of unlitting.

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Alistair Bayley]

> It uses -cpp if CPP is in the language extensions in the .cabal file.

So it does. So now Haddock completes, but produces very limited output.

> Perhaps unlitting should be done by converting all literate comments
> into {- ... -} style comments.
>
> Or something like that. Perhaps that's worth investigating and adding to
> ghc/cpphs or Cabal's own existing pure Haskell impl of unlitting.

As I alluded to earlier, I have a program which I wrote to do this. It
prefixes "--" rather than enclosing in {- -}, and it's not perfect
(there are a number of cases it doesn't handle, although I'm of the
opinion that you shouldn't be doing whatever it fails on). I'm
thinking it might be feasible to distribute this in the Takusen
release and hook it into the cabal "setup haddock" command to
preprocess the .lhs files.

I have been tempted to run it over our .lhs once and for all, and
convert everything to regular .hs files, but Oleg seems to like the
birdtrack style, so we've decided to stick with it for now.

Alistair
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Jon Fairbairn]

"Alistair Bayley" <alistair@...> writes:

> > It uses -cpp if CPP is in the language extensions in the .cabal file.
>
> So it does. So now Haddock completes, but produces very limited output.
>
> > Perhaps unlitting should be done by converting all literate comments
> > into {- ... -} style comments.

I have a programme (FishFeeder) that does this; it's a bit
hacky, but I could post it here if someone was interested in
taking it on.

> As I alluded to earlier, I have a program which I wrote to do this. It
> prefixes "--" rather than enclosing in {- -},

Mine uses {- -} and escapes any such present in comments.

Here is the first comment from the source, which is itself
literate haddock:

| Preprocess literate haskell with Haddockumentation in the
  literate comments for use with Haddock.
  So making things a bit prettier

  Assumes that there is at least one space after every \">\",
  and indents the \"{-\"s (but not the \"-}\"s) by that much so
  that Haddock doesn't give a parse error. This is a bit of
  a hack, but I reckon it's haddock's fault since comments
  shouldn't have any effect on layout.


> and it's not perfect

I'd very be surprised if mine were!

> (there are a number of cases it doesn't handle, although I'm of the
> opinion that you shouldn't be doing whatever it fails on). I'm
> thinking it might be feasible to distribute this in the Takusen
> release and hook it into the cabal "setup haddock" command to
> preprocess the .lhs files.

It would surely be better to distribute a tool (either with
compilers or with haddock) so that it worked for anyone who
likes literate haskell?

> I have been tempted to run it over our .lhs once and for all, and
> convert everything to regular .hs files, but Oleg seems to like the
> birdtrack style, so we've decided to stick with it for now.

I much prefer the birdtrack style; it's a matter of taste,
and there's nothing more likely to cause disaffection than
insisting that someone abide by someone else's taste. I
would hate to see it deprecated just because the tools were
no good.

--
Jón Fairbairn                                 Jon.Fairbairn@...


_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[kahl]

David Roundy <droundy@...> wrote:
 
 >  I've certainly never heard of a scenario in which
 > trailing white space is beneficial.

I have seen ``\ '' at the end of line in TeX,
and consider it extremely bad practice.

Just something to keep in mind in this context...


Wolfram
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

On Thu, 2007-08-02 at 15:41 +0100, Jon Fairbairn wrote:

> "Alistair Bayley" <alistair@...> writes:
>
> > > It uses -cpp if CPP is in the language extensions in the .cabal file.
> >
> > So it does. So now Haddock completes, but produces very limited output.
> >
> > > Perhaps unlitting should be done by converting all literate comments
> > > into {- ... -} style comments.
>
> I have a programme (FishFeeder) that does this; it's a bit
> hacky, but I could post it here if someone was interested in
> taking it on.

Sure why not. Post it. As I say, we've already got unlit code in Cabal.

If anyone wants to then make a patch to Cabal's unlit code that'd be
much appreciated. Then we can ask Alistair to use Takusen as a test
case.

Or we could see about getting it into cpphs's --unlit mode.

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Jon Fairbairn]

Duncan Coutts <duncan.coutts@...> writes:

> On Thu, 2007-08-02 at 15:41 +0100, Jon Fairbairn wrote:
> > "Alistair Bayley" <alistair@...> writes:
> >
> > > > It uses -cpp if CPP is in the language extensions in the .cabal file.
> > >
> > > So it does. So now Haddock completes, but produces very limited output.
> > >
> > > > Perhaps unlitting should be done by converting all literate comments
> > > > into {- ... -} style comments.
> >
> > I have a programme (FishFeeder) that does this; it's a bit
> > hacky, but I could post it here if someone was interested in
> > taking it on.
>
> Sure why not. Post it. As I say, we've already got unlit code in Cabal.

OK, but as I said, it's hacky...




--
Jón Fairbairn                                 Jon.Fairbairn@...


_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[David Brown-22]

Thomas Schilling wrote:

> The simplest thing I can think of, is to not remove whitespace at
> all, but to only remove it when you're saving the file.  I know that
> some modes use such a save hook.  It also wouldn't modify the actual
> file (ie, don't remove the whitespace until you save the file for
> the first time), as long as you edit it.  The only time the spaces
> would be removed permanently were if you save the file, close the
> buffer, and then re-open the file.

Picture mode removes trailing space when you exit it, so perhaps the
function that does that is available to call upon saving.

Dave

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Thomas Schilling-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 2 aug 2007, at 18.03, David Brown wrote:

> Thomas Schilling wrote:
>
>> The simplest thing I can think of, is to not remove whitespace at
>> all, but to only remove it when you're saving the file.  I know that
>> some modes use such a save hook.  It also wouldn't modify the actual
>> file (ie, don't remove the whitespace until you save the file for
>> the first time), as long as you edit it.  The only time the spaces
>> would be removed permanently were if you save the file, close the
>> buffer, and then re-open the file.
>
> Picture mode removes trailing space when you exit it, so perhaps the
> function that does that is available to call upon saving.
>
> Dave
>

Well, this works:

(defun delete-trailing-space ()
    "Deletes trailing space from all lines in buffer."
    (interactive)
    (or buffer-read-only
        (save-excursion
          (message "Deleting trailing spaces ... ")
          (goto-char (point-min))
          (while (< (point) (point-max))
            (end-of-line nil)
            (delete-horizontal-space)
            (forward-line 1))
          (message "Deleting trailing spaces ... done.")))
    nil) ; indicates buffer-not-saved for write-file-hook

(add-hook 'haskell-mode-hook 'my-haskell-mode-hook)

;; Make the hook a named function, so we can redefine it
:: without having torestart emacs.
(defun my-haskell-mode-hook ()
    ...
    (add-hook 'write-file-hooks 'delete-trailing-space)
    ...
    ))

But it has the problem that it will delete the whitespace also in the  
open buffer, so you have to re-insert the whitespace at the end of  
the line.  I am just looking at how to modify the editing functions,  
to have this work more seamlessly.

/ Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQEVAwUBRrIDWiuNq1ISBIDTAQKE5wf/dSuD8pAIaaUj/R4qqB022Z0hfhLjxZpc
2oLNjYCWwYKbPu7NUOuQZ5KasP6A8yJstqZndpcllxNHimKAuqJ6CSGcEEswfpVL
LX5yz9YctFvABXSF0n7zITaQACkkTSHiFPpv/7B6h6mUZYNq8aTpW+PjxGTWn1g3
r2aE5ihhMJZwH/ted+jvjWibf1tP8CtHXSQkzyJpDRGdVcpKogwoJ0HLdL/pA4Kg
+Nc0rAST/zPGPIJPXsUq4LHyH5kMQcLrgtukwN43ijqOv1sGR4Yh6hlapi82nZ0i
J0avFsi/6TibwrMgearo/WqU8gbrD4Nefl191vCmyWv5JUSAt/H6Gw==
=/gC3
-----END PGP SIGNATURE-----
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

On Thu, Aug 02, 2007 at 11:10:22AM +0100, Simon Marlow wrote:

> Thomas Schilling wrote:
> >On 2 aug 2007, at 09.50, Simon Peyton-Jones wrote:
> >>Is there an emacs mode or Lisp-blob that lets you use TAB to go to the
> >>next n-col boundary, but expands the jump into spaces.
> >>
> >>In emacs modes, TAB usually does all sorts of other snazzy things
> >>concerning layout, which I don't want.  I just want something that
> >>behaves like old-fashioned TAB, but generates a file with spaces.
> >
> >This should work:
> >
> >;; tabs are evil, always use spaces instead
> >(setq indent-tabs-mode nil)
> >
> >;; in your haskell-mode-hook:
> >  (define-key haskell-mode-map [tab] 'indent-for-tab-command)
>
> While we're on emacs... I know I can colour trailing whitespace
> differently, but that's just annoying.  What I want is: on lines that I
> edit, remove the trailing whitespace (and if I undo the edit, put the
> whitespace back too).  Is there something that does that?  I couldn't find
> it.

This ought to be doable with a --prehook in darcs record, except that darcs
doesn't yet support prehooks.  It's nicer if done by the editor, though.
--
David Roundy
Department of Physics
Oregon State University
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

On Thu, Aug 02, 2007 at 11:48:37AM +0100, Jon Fairbairn wrote:
> [1] this isn't the only place where a version control system
> that understood more of the language would be useful: for
> example, rather than having to specify a regexp, I'd like
> darcs replace to pick one (from a configuration file?)
> depending on language.

This latter bit is pretty easily added, but I doubt many people have
repositories in which they use darcs replace often on multiple languages,
so it seems like it ought to be pretty low-priority.
--
David Roundy
Department of Physics
Oregon State University
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Ashley Yakeley]

Ian Lynagh wrote:

> * Don't leave trailing white space in your code
> * Don't use tabs
> * Aim to keep lines under 80 characters
> * Use the CamelCase variable naming convention
> * Don't use explicit braces and semicolons

"by giving a parse error if we break any of its rules" -- well, you
hope, right?

My own preferences:

* Don't leave trailing white space in your code.
* Use one tab to indent each level. Display them at 4 space boundaries.
* Aim to keep lines under about 150 characters.
* Use the CamelCase variable naming convention.
* Use explicit braces and semicolons. Use "Allman" style.
* Put a newline at the end of the file.
* Prefix constructor names with "Mk" if there's only one in the type.
* Move private definitions to other "where" clauses where possible.
* Never use any unsafe functions (besides FFI). This is Haskell.
* Compile with "-Wall -Werror". This implies lots of type signatures.

For the time library source however I was rather closer to Ian's
guidelines, just so as not to annoy people. I think it still has tabs
though.

--
Ashley Yakeley

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Simon Marlow-5]

Thomas Schilling wrote:

>
> On 2 aug 2007, at 12.10, Simon Marlow wrote:
>> While we're on emacs... I know I can colour trailing whitespace
>> differently, but that's just annoying.  What I want is: on lines that
>> I edit, remove the trailing whitespace (and if I undo the edit, put
>> the whitespace back too).  Is there something that does that?  I
>> couldn't find it.
>
> The simplest thing I can think of, is to not remove whitespace at all,
> but to only remove it when you're saving the file.  I know that some
> modes use such a save hook.  It also wouldn't modify the actual file
> (ie, don't remove the whitespace until you save the file for the first
> time), as long as you edit it.  The only time the spaces would be
> removed permanently were if you save the file, close the buffer, and
> then re-open the file.
>
> If I can come up with a simple solution, I'll let you know.

I don't actually want it done on the whole file, which is why I asked for
the behaviour only on lines that I edit.  The idea is to be
revision-control-friendly by not introducing unrelated formatting changes.

You could start by removing all the trailing whitespace in all the sources
in the repository, but I think that's unnecessary.  Also I don't want to be
forced to do this everywhere.

Cheers,
        Simon
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

On Fri, 2007-08-03 at 09:07 +0100, Simon Marlow wrote:

> I don't actually want it done on the whole file, which is why I asked for
> the behaviour only on lines that I edit.  The idea is to be
> revision-control-friendly by not introducing unrelated formatting changes.

Ah, but actually it's even harder than that. You want to strip only
lines that end up in the final diff, not merely ones that you edit (but
may end up leaving the same).

So actually perhaps it can be done on save by diffing the old saved
version against the to-be-saved version and fixing the white space in
those new lines that end up covered by the diff.

Sounds like a task for Yi's Haskell mode, all it needs to do is import
the darcs diff code... :-)

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries