Re: [Haskell-cafe] Re: [Hs-Generics] how to automatically create and install documentations of a package?

[Michael Shulman]

Andy Gimblett wrote:
 Is there a way to make it automatically update a single contents page
 with links to the documentation of all installed packages?

 See:
  http://thread.gmane.org/gmane.comp.lang.haskell.cafe/53531/focus=53560
  http://thread.gmane.org/gmane.comp.lang.haskell.cafe/53531/focus=53572

 Seeing this today (I'm catching up on haskell-cafe!) made me want this
 too, so I rolled my own.

Thanks!  Actually, this looks like maybe what I really wanted:

http://hackage.haskell.org/trac/hackage/ticket/516

I'll probably keep using my script for now, though, until a new version
of cabal is released with doc-index-file.  I've copied my little script
below in case anyone else wants a lightweight solution.

Mike


#!/bin/bash

# This script, when run in a directory containing subdirectories of
# the form pkg-1.1.1/html with haddock documentation, builds a master
# table of contents for all this documentation, including all the
# system-installed libraries from SYSDOCPATH.

SYSDOCPATH=/usr/share/doc/ghc6-doc/libraries

args=

# Skip the 'ghc' package, which has a lot of packages we don't care about
for dir in $(find $SYSDOCPATH -type d -path '*libraries/*' -and -not
-name 'ghc'); do
pushd $dir /dev/null
for thing in $(find . -name '*.haddock'); do
args=$args -i $dir,$dir/$thing
done
popd /dev/null
done

for dir in $(find . -type d -name 'html'); do
pushd $dir /dev/null
for thing in $(find . -name '*.haddock'); do
args=$args -i $dir,$dir/$thing
done
popd /dev/null
done

haddock --gen-contents $args
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Hs-Generics] how to automatically create and install documentations of a package?

[Michael Shulman]

Gwern Branwen wrote:
 If you use cabal-install (as you should!), you can have it build
 haddocks by customizing ~/.cabal/config and adding:
 
 documentation: True

Is there a way to make it automatically update a single contents page
with links to the documentation of all installed packages?  I have been
doing this manually every time I cabal-install something, by running a
little shell script which looks through all the packages directories for
html directories and .haddock files and compiles them all into a
call to haddock --gen-contents.

Mike

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Proposal for stand-alone deriving declarations?

[Michael Shulman]

On 10/6/06, John Hughes [EMAIL PROTECTED] wrote:

deriving (Eq Foo, Ord Foo)

instead of

deriving (Eq, Ord) for Foo


So what does

newtype Foo a = Foo a
newtype Bar b = Bar b
class C a b
deriving (C (Foo a) (Bar b))

mean?  I could see it meaning any or all of the following:

instance (C (Foo a) b) = (C (Foo a) (Bar b))
instance (C a (Bar b)) = (C (Foo a) (Bar b))
instance (C a b) = (C (Foo a) (Bar b))

Perhaps I am misunderstanding?

Mike
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

[Haskell-cafe] Having our cake and eating it too

[Michael Shulman]

This proposal is somewhat tongue in cheek, but at least it's amusing,
and who knows, it might be good for something.  The idea is that one
could, in theory, allow both prefix unary minus and right sections of
subtraction, with the type-checker deciding which is meant based on
the context.  Has this been noticed before?

Consider the following code snippet, which runs in GHC 6.6 (with the
new ability to define postfix operators).


{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances 
-fallow-overlapping-instances #-}
module Minus where
import TypeCast



class Minus a b where
(-) :: a - b



instance (Num a, TypeCast a b) = Minus a b where
(-) = typeCast . negate



instance (TypeCast a b, Num b, TypeCast b c) = Minus a (b - c) where
(-) x y = typeCast ((typeCast x) - y)


(TypeCast is the usual one from HList etc.)  Loading this in the
interpreter, we now have:

*Minus (1 -) :: Int
-1

*Minus 3 - 1  :: Int
2

*Minus map (- 1) [2..5]
[1,2,3,4]

*Minus map (1 -) [2..5]
[-1,-2,-3,-4]

*Minus map (-) [2..5]  :: [Int]
[-2,-3,-4,-5]

*Minus zipWith (-) [1,3,5] [1,2,3]
[0,1,2]

In short, the operator - can be used as *either* an infix
subtraction operator (which can be sectioned on both sides) or a
postfix unary negation operator (which can also be sectioned once).
The trick is the same one used for variadic arguments: the
type-checker can infer from context whether (1 -) should return a
number or a function, and resolves it accordingly.

Thus, if we could figure out a way to define prefix operators,
analogous to the way we can now define postfix operators, we could in
theory allow prefix unary minus and right sections of subtraction to
coexist peacefully.  But I haven't had much luck coming up with a
non-ugly suggestion for how to do this.  I'd be interested to hear if
anyone else has ideas, although I doubt any such solution would ever
make it into any Haskell standard.  (-:

It's also unfortunate that we need the explicit type signatures in the
interpreter above, but otherwise there would be no context for
type-inference based on the return value.  As usual, though, this
problem would probably hardly ever arise in an actual program, where
most values have a known type.  (Actually, I still don't understand
why a type signature is necessary on 3 - 1; anyone care to enlighten
me?)

Comments?

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] cumulative sum

[Michael Shulman]

On 10/2/06, Tamas K Papp [EMAIL PROTECTED] wrote:

Hi,

I have two lists, p and lambda (both are finite).  I would like to
calculate

1) the cumulative sum of lambda, ie if

lambda = [lambda1,lambda2,lambda3,...]

then

csum lambda = [lambda1,lambda1+lambda2,lambda1+lambda2+lambda3,...]


Try (scanl1 (+) lambda)

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Typeclass vs. Prolog programming

[Michael Shulman]

Thank you Oleg!  That explanation is very clear.

On 9/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

The typechecker commits to the instance
and adds to the current constraints
TypeCast x Int, Ord Bool, Eq Bool
The latter two are obviously satisfied and so discharged. The former
leads to the substitution {x-Int}.


By the rules just enumerated, this substitution would be forbidden,
since the type variable x is not considered variable, right?  So this
happens via the magic of functional dependencies?  The typechecker
encounters (eventually) the instance

instance TypeCast'' () x x

and since TypeCast'' is declared with a functional dependency:

class TypeCast'' t x y | t x - y, t y - x

it concludes that the first x in the above instance is uniquely
determined by the second, which in our case is Int, and therefore x
must be Int.  Is that right?

This is all very beautiful, but it's a little annoying that the
cornerstone silver bullet TypeCast has to be defined in a way that
fools the typechecker into doing the right thing in spite of itself.
Is this all part of the general fundeps are very hard to get right
problem?

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: variadic functions and typeCast

[Michael Shulman]

On 9/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

First of all, there is a version of TypeCast that works within the
same module, please see any code described in
http://pobox.com/~oleg/ftp/Haskell/typecast.html


Yes, I was aware of that; I gave the shorter version just because it's
shorter.  I didn't realize how well-known this TypeCast is, so forgive
my ignorance.

Thanks for your answer.  I think the real point at which I was
confused is that the type-checker never unifies types in order to
*find* an instance of a class, but functional dependencies of a class
can make it unify types.  Thus, by making the instance look more
general but moving the unification into a TypeCast constraint, since
TypeCast has a bidirectional fundep, we can make the instance match a
pair of types that aren't yet unified, and then use TypeCast's fundep
to force their unification.  Is that right?

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] MR details (was: Implicit type of numeric constants)

[Michael Shulman]

On 9/23/06, Bernie Pope [EMAIL PROTECTED] wrote:

If a pattern binding is not simple, it must have a data constructor
on the lhs, therefore it cannot be overloaded. So the (dreaded) MR only
applies to simple pattern bindings.


I thought it was simple pattern bindings that could be *exempted* from
the MR by supplying an explicit type signature, while non-simple
pattern bindings are always subject to it.

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] variadic functions and typeCast

[Michael Shulman]

Hi all,

I am writing, for my own amusement, a more general version of the
trick to implement variadic functions in Haskell outlined at
http://okmij.org/ftp/Haskell/vararg-fn.lhs.  (If someone else has done
this already, please point me to it!)  Code is attached at the end of
the message.  My question concerns the use of `typeCast', which is
defined as follows:

class TypeCast x y | x - y, y - x where
   typeCast :: x - y

instance TypeCast x x where
   typeCast = id

This is taken from the paper Strongly typed heterogeneous
collections by Oleg Kiselyov, Ralf Lammel, and Keean Schupke.  As
observed there, the TypeCast instance declaration must occur in a
separate module; otherwise the compiler is too eager about type
simplification.  (I also get the same errors if VarArg is interpreted
by GHCi, even if TypeCast is in a separate module.)  I think I
understand the reason for this, but I find it a little surprising; it
wasn't clear to me from the documentation that fundeps introduce a new
dependence on module boundaries.

Anyway, my main question about typeCast is this: why is it needed here
at all?  If I omit it entirely, the code compiles fine, but then
using it gives error messages like the following:


Prelude VarArg build 'h' 'i' :: String

interactive:1:0:
   No instances for (VarFold [a] [a] [Char], VarAccum Char [a])
 arising from use of `build' at interactive:1:0-4
   ...


I don't understand why the type-checker is unable to infer that the
type variable `a' should be specialized to `Char' here, since the only
available instance of VarFold whose third type is [Char] has the first
type also being [Char].  I've given the compiler all the type hints I
can think of.  Can someone explain this to me?

I should say that if I add a functional dependency l - a to the
class VarAccum, then this particular example works.  However, I have
other examples in mind for which l doesn't functionally determine a,
so I don't want to do that.  And I don't see why it's necessary.

Here's the code:


class VarAccum a l where
   accum :: a - l - l

class VarFold b l r where
   varFold :: (l - b) - l - r

instance (TypeCast b c) = VarFold b l c where
   varFold f xs = typeCast (f xs)

instance (VarFold b l r, VarAccum a l) = VarFold b l (a - r) where
   varFold f xs x = varFold f (accum x xs)

-- This is the type of variadic functions from lots of As to a B.
type a :-- b = forall r. (VarFold b [a] r) = r
infixr 0 :--

instance VarAccum a [a] where
   accum x xs = (x:xs)

varArg :: forall a b. ([a] - b) - (a :-- b)
varArg f = varFold (f . reverse) ([] :: [a])

build :: forall a. a :-- [a]
build = varArg (id :: [a] - [a])


Thanks!
Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell] How to define Y combinator in Haskell

[Michael Shulman]

On 9/15/06, Robert Dockins [EMAIL PROTECTED] wrote:

You can define a direct fixed point combinator
without relying on nominal recursion in Haskell, but it requires you to
define a helper newtype.


That's really nifty!  I'd been wondering whether you could do this
too.  Is there a reason for the extra `z' parameter?


Don't run this in GHC because it will diverge.  Hugs works, however.


According to

http://www.haskell.org/pipermail/glasgow-haskell-bugs/2001-August/001717.html

this is due to a bug in the GHC inliner that probably won't be fixed.
However, experimentation indicates you can work around the bug using
the NOINLINE pragma:


newtype Mu a = Roll { unroll :: Mu a - a }

fix :: (a - a) - a
fix f = doink (Roll doink)
   where {-# NOINLINE doink #-}
 doink x = f ((unroll x) x)


Mike
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell-cafe] Re: evaluate vs seq

[Michael Shulman]

On 9/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

With this in mind the equations
1)  return _|_ == Return _|_
2)  _|_ `seq` (return _|_) == _|_
can be interpreted:
1) when reducing a return-redex (i.e. evaluating it), we get weak-head
normal form without evaluating the argument (which was _|_)
2) when reducing the `seq`-thing but not further evaluating the
arguments (_|_ in our case), we get nowhere (i.e. only _|_)

Thus, when evaluating the expressions (one step!, i.e. just to weak head
normal form), number 1) returns immediately but in 2), the `seq` needs
to evaluate its first argument. So the semantics of applying _|_ to a
function determines its behavior with respect to how much of its
arguments will be evaluated! I think this is the point our
misunderstanding is about?

For (evaluate :: a-IO a), I said something like
3)  evaluate _|_== ThrowException
and meant, that when evaluating 3) one step to weak head normal form,
the argument does not get evaluated. 2) is much different to that.
Equation 3) is of course wrong and must be more like
evaluate x == Evaluate x
where (Evaluate x) is a constructor but with a particular behavior when
executed in the IO-Monad.


Great, thank you!  I think this finally answers my question.

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: evaluate vs seq

[Michael Shulman]

On 9/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

So `seq` forces its first argument. When we define
  f x = x `seq` (Return x)
we thereby get
  f _|_== _|_
  f [] == Return []
  f (x:xs) == Return (x:xs)
To compare, the semantics of (evaluate) is
  evaluate _|_== ThrowException =/= _|_
  evaluate [] == Return []
  evaluate (x:xs) == Return (x:xs)
That should answer your question.


I must not be phrasing my question very well; I feel like we're
talking past each other.  It seems to me that when writing actual
programs (rather than reasoning about denotational semantics) the
reason one would use `seq' or `evaluate' is to force something to be
evaluated now rather than later, i.e. to get around Haskell's
default lazy execution.

Your semantics say that (x `seq` return x) and (evaluate x) have the
same result when x is anything other than _|_.  All well and good, but
(return x) *also* has those same results when x is not _|_.  Why would
one use the former two rather than (return x), if x is known not to be
_|_?  Because they evaluate x at different times, right?  Even though
the eventual return value is the same, and thus the *semantics* are the
same.  So laying aside the formal semantics, what is the difference in
terms of actual, real, Haskell programs?

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] foreach

[Michael Shulman]

On 9/13/06, Henning Thielemann [EMAIL PROTECTED] wrote:

If you want more sugar, what about the list monad?

main = do
 args - getArgs
 sequence_ $
   do arg - args
  n - [1..3]
  return (putStrLn $ show n ++ )  ++ arg)


Or, what about using ListT to combine it with IO, eliminating the need for
two separate `do' blocks?

main = ( return ()) $ runListT $ do
arg - ListT getArgs
n - ListT $ return [1..3]
liftIO $ putStrLn ((show n) ++ )  ++ arg)

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] MonadList?

[Michael Shulman]

On 9/13/06, Bertram Felgenhauer [EMAIL PROTECTED] wrote:

Michael Shulman wrote:

 class MonadList m where
option :: [a] - m a
[...]

There's no need for an extra class, it can be done with MonadPlus:

option :: MonadPlus m = [a] - m a
option = msum . map return


But this doesn't always give the behavior I want.  It works for any
monad of the form (ListT m), but not for a monad like (ErrorT e []).
I would want

runErrorT $ do
 x - option [1..3]
 return x

to return [Right 1, Right 2, Right 3], but with your definition it
returns [Right 1].  This is because (ErrorT e []) inherits its
instance of MonadPlus from Error, not from [].  (Is there a reason for
this, or is it just assumed that this is the more frequently desired
behavior?)  However, I declare

instance (Error e) = MonadList (ErrorT e []) where
   option = lift

then the above code does return [Right 1, Right 2, Right 3].

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: evaluate vs seq

[Michael Shulman]

On 9/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 The GHC documentation says that (evaluate a) is not the same as (a
 `seq` return a).  Can someone explain the difference to me, or point
 me to a place where it is explained?

(evaluate a) is weaker than (a `seq` return a). (a `seq` return a) is
always _|_ whereas (evaluate a) is not _|_, but does throw an exception
when executed.


Okay...  I think maybe I understand now.  To check my understanding,
is the following a correct description?

* (return a) = produces an IO action which, when executed, returns a
 in the IO monad, but lazily evaluated.  Thus, if a is undefined, it
 doesn't throw an exception unless and until its value is actually
 used.

* (a `seq` return a) = evaluate a *right now*, then produce an IO action
 which, when executed, returns the result of evaluating a.  Thus, if
 a is undefined, throws an exception right now.

* (evaluate a) = produces an IO action which, when *executed*, evaluates
 a (not lazily) and returns the result in the IO monad.  Thus, if a is
 undefined, throws an exception if and when the IO action in question
 is executed.

If this is correct, then the way I would explain your examples is
as follows.  The 1 versions always throw an exception, since that
happens when the function is first called.


e 0 = return a
e 1 = a `seq` return a
e 2 = evaluate a

t x = e x  return ()
-- t 0 == return ()
-- t 1 == throwIO something
-- t 2 == throwIO something


Here the IO action is executed, so 2 throws an exception; but its
value is never used, so 0 doesn't.


u x = e x `seq` return ()
-- u 0 == return ()
-- u 1 == undefined
-- u 2 == return ()


Here the IO action is never even executed, since it gets replaced with
(return ()), so neither 0 nor 2 throws an exception.


v x = catch (e x) (\_ - return ()) = print
-- v 0 == throwIO something
-- v 1 == print ()
-- v 2 == print ()


Here, again, the IO action is executed, so 2 throws an exception at
that point, which gets caught and so the result is replaced with ().
But 0 executes with no problem and returns a, lazily evaluated, which
thereby slips out from under the `catch' to throw an error when its
value is actually used, later, by `print'.

Is that all correct?

Thanks for your help!
Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] sections of noncommutative operators

[Michael Shulman]

A propos of sections of subtraction, and thence to sections of other
noncommutative operators, as a Haskell newbie I was surprised to
discover (the hard way!) that

( 0)

and

(() 0)

mean different things.  I had typed ( 0) when I meant to type (()
0).  No compiler errors, of course, and I had a devil of a time
finding that bug.  My initial reaction was that ( 0) should be an
error and you should have to write (() 0); now I realize that the
section notation is more fundamental, since () itself is actually a
double section.  And of course I should have written ( 0) anyway;
it's probably my lisp background that tripped me up.  But is there any
way this could be made less confusing?  Do any of the online tutorials
warn against this sort of mistake, and I just missed it?

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: sections of noncommutative operators

[Michael Shulman]

No, lisp doesn't have currying, but of course I knew that Haskell
does.  I think my thought processes went something like this: I want
to partially apply , but  is an infix operator in Haskell, so
first I have to convert it to the function () written with prefix
notation and then partially apply it.  That led me to (() 0), and
then I mistyped ( 0), probably since in lisp  is already a function
written with prefix notation.  I guess to someone not coming from
lisp, ( 0) means less than zero and not the function  with 0
passed as its first argument.  I guess I'm just unlucky enough to get
confused by something that other people find straightforward.  (-:

On 09 Sep 2006 11:17:52 +0100, Jón Fairbairn [EMAIL PROTECTED] wrote:

Right about the start of the design of Haskell, I proposed
the rule parentheses should only be used for grouping.


I think I would have liked that rule.  Are parentheses currently used
for anything else besides grouping and sections?

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: sections of noncommutative operators

[Michael Shulman]

On 9/9/06, Brian Hulley [EMAIL PROTECTED] wrote:

Yes: tuples, contexts, set of classes to derive from in a deriving clause,
module export list, import directives.


I guess I thought of most of those as a sort of grouping, without
really thinking about it.  But I suppose you are right that they are
actually different.

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] evaluate vs seq

[Michael Shulman]

The GHC documentation says that (evaluate a) is not the same as (a
`seq` return a).  Can someone explain the difference to me, or point
me to a place where it is explained?

Mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe