Re: [Haskell-cafe] Use of uninstantiated type class

[Yves Parès]

Okay, I found something which I'm sure already exists somewhere:

{-# LANGUAGE TypeFamilies, TypeOperators, EmptyDataDecls #-}

data True
type family a `Or` b :: *
type instance True `Or` a = True
type instance a `Or` True = True

type family Ctx ref impl :: *
data Foo
data Bar
type instance Ctx Foo Foo = True
type instance Ctx Bar Bar = True

runFoo :: MyIO Foo a -> IO a
runBar :: MyIO Bar a -> IO a

fooCtxAction :: (Ctx Foo c) ~ True => MyIO c ()

bothCtxAction :: (Ctx Foo c `Or` Ctx Bar c) ~ True => MyIO c ()

allCtxAction :: MyIO c ()


2011/3/5 Yves Parès 

> But I don't have an explicit type to put.
> I cound do:
>
> data CtxFooInst
> instance CtxFoo CtxFooInst
>
> and declare runFoo as this:
>
> runFoo :: MyIO CtxFooInst a -> IO a
>
> But I loose the ability to make functions that can run several contexts.
>
>
> 2011/3/5 Ivan Lazar Miljenovic 
>
> On 5 March 2011 10:45, Yves Parès  wrote:
>> > Hello,
>> >
>> > For testing purposes, I am trying to make an overlay to IO which carries
>> a
>> > phantom type to ensure a context.
>> > I define contexts using empty type classes :
>> >
>> > class CtxFoo c
>> > class CtxBar c
>> >
>> > The overlay :
>> >
>> > newtype MyIO c a = MyIO (IO a)
>> >
>> > Then I define some methods that run only a specific context :
>> >
>> > runFoo :: (CtxFoo c) => MyIO c a -> IO a
>> > runFoo (MyIO x) = x
>> >
>> > runBar :: (CtxBar c) => MyIO c a -> IO a
>> > runBar (MyIO x) = x
>> >
>> > And then an action that runs in context 'Foo' :
>> >
>> > someAction :: (CtxFoo c) => MyIO c ()
>> > someAction = putStrLn "FOO"
>> >
>> > Then I run it :
>> >
>> > main = runFoo someAction
>> >
>> > But obiously, GHC complains that my type 'c' remains uninstantiated :
>> >
>> > Ambiguous type variable `c' in the constraint:
>> >   (CtxFoo c) arising from a use of `runFoo'
>> > Probable fix: add a type signature that fixes these type variable(s)
>> > In the expression: runFoo someAction
>> > In an equation for `main': main = runFoo someAction
>> >
>> >
>> > Is there a way to deal with this ?
>>
>> Provide an explicit type signature for either runFoo or someAction;
>> this is the same problem as doing "show . read" in that GHC can't tell
>> which instance to use.
>>
>> --
>> Ivan Lazar Miljenovic
>> ivan.miljeno...@gmail.com
>> IvanMiljenovic.wordpress.com
>>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Convert a function to a string of operators?

[Brandon Moore]

> From: Evgeny Grablyk 

> 
> Hello!
> 
> I was wondering if it was possible to "convert" a function (which  may
> also call functions) to a plain list of operators on  parameters.
> Example:

If your "operators" are only things in Num (or maybe some other
typeclasses), the suggestions you have gotten about making a
special Num instance are excellent.

If you are curious how things are actually compiled, you can
use the -ddump-simpl option. This is way more detail that
you probably want, showing things like how + is implemented
in terms of more primitive operations, or explicit passing
around of class method dictionaries.

I hoped the ghci debugger might be useful, but it seems to
evaluate expressions like (baw 1 10 100) to a final result
in one step, and can't show you an expression corresponding
to unevaluated values.

Brandon


  

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

Re: [Haskell-cafe] Use of uninstantiated type class

[Yves Parès]

But I don't have an explicit type to put.
I cound do:

data CtxFooInst
instance CtxFoo CtxFooInst

and declare runFoo as this:

runFoo :: MyIO CtxFooInst a -> IO a

But I loose the ability to make functions that can run several contexts.


2011/3/5 Ivan Lazar Miljenovic 

> On 5 March 2011 10:45, Yves Parès  wrote:
> > Hello,
> >
> > For testing purposes, I am trying to make an overlay to IO which carries
> a
> > phantom type to ensure a context.
> > I define contexts using empty type classes :
> >
> > class CtxFoo c
> > class CtxBar c
> >
> > The overlay :
> >
> > newtype MyIO c a = MyIO (IO a)
> >
> > Then I define some methods that run only a specific context :
> >
> > runFoo :: (CtxFoo c) => MyIO c a -> IO a
> > runFoo (MyIO x) = x
> >
> > runBar :: (CtxBar c) => MyIO c a -> IO a
> > runBar (MyIO x) = x
> >
> > And then an action that runs in context 'Foo' :
> >
> > someAction :: (CtxFoo c) => MyIO c ()
> > someAction = putStrLn "FOO"
> >
> > Then I run it :
> >
> > main = runFoo someAction
> >
> > But obiously, GHC complains that my type 'c' remains uninstantiated :
> >
> > Ambiguous type variable `c' in the constraint:
> >   (CtxFoo c) arising from a use of `runFoo'
> > Probable fix: add a type signature that fixes these type variable(s)
> > In the expression: runFoo someAction
> > In an equation for `main': main = runFoo someAction
> >
> >
> > Is there a way to deal with this ?
>
> Provide an explicit type signature for either runFoo or someAction;
> this is the same problem as doing "show . read" in that GHC can't tell
> which instance to use.
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> IvanMiljenovic.wordpress.com
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Use of uninstantiated type class

[Ivan Lazar Miljenovic]

On 5 March 2011 10:45, Yves Parès  wrote:
> Hello,
>
> For testing purposes, I am trying to make an overlay to IO which carries a
> phantom type to ensure a context.
> I define contexts using empty type classes :
>
> class CtxFoo c
> class CtxBar c
>
> The overlay :
>
> newtype MyIO c a = MyIO (IO a)
>
> Then I define some methods that run only a specific context :
>
> runFoo :: (CtxFoo c) => MyIO c a -> IO a
> runFoo (MyIO x) = x
>
> runBar :: (CtxBar c) => MyIO c a -> IO a
> runBar (MyIO x) = x
>
> And then an action that runs in context 'Foo' :
>
> someAction :: (CtxFoo c) => MyIO c ()
> someAction = putStrLn "FOO"
>
> Then I run it :
>
> main = runFoo someAction
>
> But obiously, GHC complains that my type 'c' remains uninstantiated :
>
>     Ambiguous type variable `c' in the constraint:
>   (CtxFoo c) arising from a use of `runFoo'
>     Probable fix: add a type signature that fixes these type variable(s)
>     In the expression: runFoo someAction
>     In an equation for `main': main = runFoo someAction
>
>
> Is there a way to deal with this ?

Provide an explicit type signature for either runFoo or someAction;
this is the same problem as doing "show . read" in that GHC can't tell
which instance to use.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com

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

[Haskell-cafe] Use of uninstantiated type class

[Yves Parès]

Hello,

For testing purposes, I am trying to make an overlay to IO which carries a
phantom type to ensure a context.
I define contexts using empty type classes :

class CtxFoo c
class CtxBar c

The overlay :

newtype MyIO c a = MyIO (IO a)

Then I define some methods that run only a specific context :

runFoo :: (CtxFoo c) => MyIO c a -> IO a
runFoo (MyIO x) = x

runBar :: (CtxBar c) => MyIO c a -> IO a
runBar (MyIO x) = x

And then an action that runs in context 'Foo' :

someAction :: (CtxFoo c) => MyIO c ()
someAction = putStrLn "FOO"

Then I run it :

main = runFoo someAction

But obiously, GHC complains that my type 'c' remains uninstantiated :

Ambiguous type variable `c' in the constraint:
  (CtxFoo c) arising from a use of `runFoo'
Probable fix: add a type signature that fixes these type variable(s)
In the expression: runFoo someAction
In an equation for `main': main = runFoo someAction


Is there a way to deal with this ?
The interest of using type classes and not empty types to represent the
contexts is that it stays simple, and that I can do that :

someAction2 :: (CtxFoo c, CtxBar c) => MyIO c ()
someAction2 = putStrLn "FOO and BAR"

... a function that can run in both contexts.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Convert a function to a string of operators?

[Bas van Dijk]

On 4 March 2011 22:10, Job Vranish  wrote:
> Make your own expression type and make it an instance of the Num typeclass.

This is also the approach I took in repr:

http://hackage.haskell.org/package/repr

For example:

$ cabal install repr
$ ghci
> import Text.Repr
> let r = 1.5 + 2 + (3 + (-4) * (5 - pi / sqrt 6)) :: Repr Double
> extract r
17.281195923884734
> show r
"fromRational (3 % 2) + 2 + (3 + negate 4 * (5 - pi / sqrt 6))"

Bas

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

Re: [Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)

[Michal Konečný]

On Friday 04 Mar 2011 21:06:45 Edward Kmett wrote:
> I'd be more than willing to tackle flipping things over to use foreign
> prims, so that I have something I can build on top without requiring the
> contortions to get a ghc build with integer-simple. 
> 
> Dan has a cabal buildable library with foreign prims to use as a model.
> 
> Is the google code repository up to date?

Hi Ed,

Yes, it is up to date.  Moreover, I am not planning to do any development on 
it in the next few weeks.  I would be very happy if you would experiment with 
the foreign prims in hmpfr.

Michal
-- 
|o| Michal Konecny 
|o|http://www-users.aston.ac.uk/~konecnym/
|o|office: (+42) (0)121 204 3462 
|o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston


signature.asc
Description: This is a digitally signed message part.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)

[Michal Konečný]

Hi Dan,

On Friday 04 Mar 2011 21:59:12 Daniel Peebles wrote:
> I'm adding Ed to the conversation as he's very interested in this topic,
> too. 

I do apologise - I was meant to post the previous email back to haskell-cafe 
but by mistake it went only to you.  I hope you do not mind that I am taking 
the discussion back to the cafe.  I attach my email so that other readers of 
the cafe can see it.

> The experts were right about it being impossible to work with GHC's
> GMP – until recently. "foreign import c" calls are indeed going to call GC
> when you don't want it, but when they split integer-gmp out of GHC's own
> RTS, Duncan Coutts (one of those experts) added the "foreign import prim"
> construct so that he could do exactly what you want, and operate on GMP
> integers with GHC-allocated memory without worrying about temporary
> storage blowing up while you aren't looking.
>
> So in general, I'd lean more towards replacing all your ccall bindings to
> MPFR with cmm bindings. It does require some GHC internals knowledge but
> is fairly mechanical, and would solve all the problems, without requiring
> a rewrite of GMP (that would be slower anyway). 
>
> Ed is actually going to get started on a fairly simple binding to a subset
> of MPFR for one of his projects, using the CMM approach based on the
> structure of my natural-gmp package
> (https://github.com/pumpkin/natural-gmp, which is itself based heavily on
> integer-gmp, but reworked to work fine from cabal rather than depending on
> GHC's build process). Once he is done with that, you might want to refer
> to his implementation to make your more complete MPFR binding work with
> integer-gmp (and thus make no speed sacrifices).

If this is the best approach, I would welcome help with this as I will not 
have much time to work on it until the summer due to teaching commitments and 
the need to publish work done earlier.

> I would also like a gmp-compatible replacement, but it's going to
> necessarily be slower and would prefer to be able to have fast
> computations over floating-point numbers AND integers/naturals.

Eek, I made a mistake, I apologise again - the proposal I was quoting in the 
announcement is not what I had in mind.  I was meant to refer to a mention by 
igloo at the very end of

http://hackage.haskell.org/trac/ghc/ticket/311

which is a very different proposal from the one I linked to and the one you 
seem to refer to here. 

I was not at all thinking of writing a gmp compatible replacement.  I was 
thinking of taking gmp sources and mechanically modify the exported names and 
modify integer-gmp to use those modified names.  Thus there would be no 
difference in the speed of Integer as it would still use an exact clone of the 
original gmp in exactly the same way as now but not interfere with what the 
usual gmp code does via other libraries.

Please correct me if I this approach is not feasible or if there is some 
advantage in using cmm over this proposal that I am missing.

Michal
-- 
|o| Michal Konecny 
|o|http://www-users.aston.ac.uk/~konecnym/
|o|office: (+42) (0)121 204 3462 
|o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston
--- Begin Message ---
Hello Dan,

Thank your for your suggestions.  

I implemented the dependency on integer-simple because I need hmpfr to work in 
the short term.  In the long term, I would like to adopt a better approach.  
At the moment I do not know enough about ghc internals to be able to determine 
the approach, so I welcome your pointers.  I know that Aleš, who knows more 
about the ghc internals, has tried various things but could not make hmpfr 
work with the current integer-gmp.

I did not file a bug because there was a similar ghc ticket open for quite 
some time (#601) and it has been closed when it became possible to use 
integer-simple instead of integer-gmp.  That is why I felt that the best 
solution to the problem at present is to use integer-simple.

I am not an expert but based on what I read experts say on the topic I 
concluded that it is close-to-impossible to make ghc+integer-gmp work with 
libraries such as mpfr that heavily use gmp.

Of the suggested solutions we are aware of, the one that seems to me and Aleš 
most promising is to create a clone of gmp that differs from the original only 
in the names of all exported symbols and distribute it as a part of ghc to be 
dynamically linked with all executables produced by ghc.  The clone could be 
produced using a script to allow easy updates with new versions of gmp.  I 
would be interested whether someone has been trying or has plans to try to 
implement this approach.  The reason why I like this approach than writing cmm 
wrappers around MPFR and prim importing them is that it is more maintainable 
and also opens the way for other libraries that depend on gmp to work with 
ghc.

Michal

On Friday 04 Mar 2011 20:27:10 you wrote:
> According to Duncan Coutts (whom I asked about this issue in #ghc), the
> solution he

Re: [Haskell-cafe] Learn You a Haskell for Great Good - a few doubts

[Daniel Fischer]

On Friday 04 March 2011 22:33:20, Alexander Solla wrote:
> > Unfortunately, Haskell's tuples aren't quite products.[1]
> 
> I'm not seeing this either.  (A,B) is certainly the Cartesian product of
> A and B.

Not quite in Haskell, there

(A,B) = A×B \union {_|_}

_|_ and (_|_,b) are distinguishable.

(A,()) contains

- (a,()) for a in A
- (a, _|_) for a in A
- _|_

the three classes are distinguishable

case x of
   (a,b) -> do
putStrLn "Bona fide tuple"
case b of
  () -> putStrLn "With defined second component"

will produce different output for them.

In Haskell, |(A,B)| = |A|×|B| + 1 (and |()| = 2, () = { (), _|_ }),
and |(A,B,C)| = |A|×|B|×|C| + 1 etc.
So one would expect |(A)| = |A| + 1 by consistency for 1-tuples.

> In what sense are you using "product" here?

Set theoretic or more general, category theoretic, I presume.

> Is your complaint
> a continuation of your previous (implicit) line of thought regarding
> distinct bottoms?

I don't think distinguishing bottoms is the issue, but distinuishing bottom 
from partially defined values.

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

Re: [Haskell-cafe] Learn You a Haskell for Great Good - a few doubts

[Daniel Fischer]

On Friday 04 March 2011 17:45:13, Markus Läll wrote:
> Sorry, I didn't mean to answer you in particular. I meant to say that
> for tuples you could (I think) have an enumeration over them without
> requiring any component be bounded.

Yes, you can (at least mathematically, it may be different if you consider 
actual Enum instances, then Int overflow has to be reckoned with).

The problem is with simultaneous Ord and Enum instances.
Let's call an

instance Ord A where ...

and an

instance Enum A where ...

compatible when toEnum and fromEnum are strictly monotonic, i.e.

x `rel` y <=> fromEnum x `rel` fromEnum y

for rel in { (<), (==), (>) }
and analogously for toEnum (restricted to legitimate arguments).
And let's ignore overflow, so pretend Int were infinite (so Int = Z).

That means, for compatible Ord and Enum instances, it follows that for any 
x, y \in A with x <= y, the set { z \in A : x <= z && z <= y } is finite 
[it has at most (fromEnum y - fromEnum x + 1) elements].

So when A is a tuple type and the Ord instance is lexicographic ordering,
a compatible Enum instance is only possible if

- at least one component is empty, or
- at most one component is infinite and only single-element types appear as 
components before the infinite one.

Otherwise, if x1 < x2 and Y is infinite, the set
S(t) = { (x,y) : (x1,t) <= (x,y) && (x,y) <= (x2,t) }
is infinite because we can embed Y into it [foo y = if y < t then (x2,y) 
else (x1,y)].

In fact, for any Enum instance, there is exactly one compatible Ord 
instance, namely

x `rel` y <=> fromEnum x `rel` fromEnum y

Conversely, given an Ord instance, if there exists a compatible Enum 
instance, fromEnum gives an order-isomorphism between A and a subset of the 
integers. Then there are four main possibilities

1. A is finite
(then A has the order type of some natural number n = card(A))
2. A has a smallest element but not a largest
(then A has the order type of the natural numbers N)
3. A has a largest element but no smallest
(then A has the order type of Z-N)
4. A has neither a smallest nor a largest element
(then A has the order type of Z)

Anyway, there exists a compatible Enum instance (and then infinitely many), 
if and only if A has the order type of a subset of the integers.

> 
> An example of type (Integer, Integer) you would have:
> 
> [(0,0) ..] = [(0,0) (0,1) (1,0) (0,2) (1,1) (2,0) ... ]

That's (Nat, Nat) rather than (Integer,Integer), not fundamentally 
different, but simpler to handle.

> 
> where the order can be visualized by taking diagonals of a table
> starting from the upper left:
> 
> 0  1  2 ..
> 0 (0,0)  (0,1)  (0,2)
> 1 (1,0)  (1,1)  (1,2)
> 2 (2,0)  (2,1)  (2,2)
> ..
> 
> Would this also have an uncomputable order type?

No, order type is that of N, if order is given by enumeration

> At least for comparing
> tuples you'd just:
> 
> lt :: (Integer,Integer) -> (Integer,Integer) -> Bool
> (a,b) `lt` (c,d) = let
>   sum1 = (a + b)
>   sum2 = (c + d)
>in if sum1 == sum2
>  then a < c
>  else sum1 < sum2
> 
> 
> Implementing fromEnum looks like a bit harder problem..

That's pretty easy, in fact.

fromEnum (a,b) = t + a
  where
s = a+b
t = (s*(s+1)) `quot` 2 -- triangular number

toEnum is a bit more difficult, you have to take a square root to see on 
which diagonal you are

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

Re: [Haskell-cafe] Learn You a Haskell for Great Good - a few doubts

[Alexander Solla]

On Thu, Mar 3, 2011 at 10:14 PM, wren ng thornton  wrote:

> On 3/3/11 2:58 AM, Antti-Juhani Kaijanaho wrote:
>
>> On Thu, Mar 03, 2011 at 12:29:44PM +0530, Karthick Gururaj wrote:
>>
>>> Thanks - is this the same "unit" that accompanies IO in "IO ()" ? In
>>> any case, my question is answered since it is not a tuple.
>>>
>>
>> It can be viewed as the trivial 0-tuple.
>>
>
> Except that this is problematic since Haskell doesn't have 1-tuples (which
> would be distinct from plain values in that they have an extra bottom).
>
>
I don't get this line of thought.  I understand what you're saying, but why
even bother trying to distinguish between bottoms when they can't be
compared by equality, or even computed? The type (forall a . a) doesn't
contain any values!   It is empty, and so is a subset of any other type.  If
you choose to interpret all bottoms as being the same non-existent,
unquantifiable (in the language of Haskell) "proto-value", you get the
isomorphism between types a and (a), as types.  Indeed, those are the
semantics in use by the language.  A value written (a) is interpreted as a.
 A type written (a) is interpreted as a.

In an idealized world, yes, unit can be thought of as the nullary product
> which serves as left- and right-identity for the product bifunctor.
> Unfortunately, Haskell's tuples aren't quite products.[1]
>

I'm not seeing this either.  (A,B) is certainly the Cartesian product of A
and B.  In what sense are you using "product" here? Is your complaint a
continuation of your previous (implicit) line of thought regarding distinct
bottoms?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Convert a function to a string of operators?

[Job Vranish]

Make your own expression type and make it an instance of the Num typeclass.
Then you can build your expression using the usual operators and then use
show to convert to a string.

For example:
https://github.com/jvranish/grhug/blob/master/SymbolicDifferentiation/SymbolicDifferentiation.hs

It probably does more than you want, but you should be able to get the basic
idea.

The really slick thing about it is that you can use expression type on any
function that takes a Num and you'll get a representation of the computation
that took place to get the result.

For example:
  show (baw a b c :: Int)  -- will show you an int
and
  show (baw a b c :: Expr)  -- will give you "(a + b) * c"  (well... a, b, c
will be replace by whatever you passed in, but you can make them variable
names just the same)

- Job


On Fri, Mar 4, 2011 at 3:32 PM, Evgeny Grablyk wrote:

> Hello!
>
> I was wondering if it was possible to "convert" a function (which may
> also call functions) to a plain list of operators on parameters.
> Example:
>
> foo a b = a + b
> bar a b = a * b
>
> baw a b c = bar (foo a b) c
> baw' a b c = (a + b) * c
>
> Any way to get `baw'' from `baw'?  Preferrably as a String.
>
> --
> Evgeny
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)

[Edward Kmett]

I'd be more than willing to tackle flipping things over to use foreign
prims, so that I have something I can build on top without requiring the
contortions to get a ghc build with integer-simple.

Dan has a cabal buildable library with foreign prims to use as a model.

Is the google code repository up to date?

-Edward Kmett

On Fri, Mar 4, 2011 at 3:27 PM, Daniel Peebles  wrote:

> According to Duncan Coutts (whom I asked about this issue in #ghc), the
> solution here is to use the new foreign import prim machinery to talk to
> MPFR. This prevents GC from occurring during the MPFR calls and will make
> everything work nicely without reimplementing GMP.
>
> Dan
>
>
> On Fri, Mar 4, 2011 at 3:09 PM, Daniel Peebles wrote:
>
>> Have you submitted a bug report to GHC of why it can't work with the
>> current integer-gmp binding? I know that GHC's collector is collecting
>> MPFR's temporary data, but maybe it'd be good to get a discussion going on
>> what can be done to stop it from doing this even in the context of the
>> existing integer-gmp + GHC's allocator (even if this needs to be a patch to
>> MPFR to talk to GHC a bit here and there). Might it help to go through CMM
>> like the GMP binding does, for example?
>>
>> I'd really like to see libraries that use GMP work nicely with GHC,
>> without going and reimplementing GMP more slowly and so on.
>>
>> Dan
>>
>> 2011/3/3 Michal Konečný 
>>
>>> Dear all,
>>>
>>>
>>> I am pleased to announce hmpfr-0.3.2, a new version of Aleš Bizjak's
>>> bindings
>>> to the MPFR arbitrary precision floating point arithmetic library.  The
>>> changes in this version are quite small but significant:
>>>
>>> - support for MPFR 3.0.0 as well as MPFR 2.4.*
>>> - dependency on integer-simple instead of integer-gmp
>>>
>>> The latter is most significant because unfortunately it makes it rather
>>> more
>>> difficult to install hmpfr.   Currently almost all binary distributions
>>> of ghc
>>> have integer-gmp compiled in to provide the Integer type via the standard
>>> GMP
>>> library.  Also haskell platform 2010.2.0.0 assumes that ghc has been
>>> compiled
>>> with integer-gmp although it makes no specific use of it.  Instructions
>>> on how
>>> to compile ghc and haskell platform with integer-simple instead of
>>> integer-gmp
>>> are on:
>>>
>>> http://code.google.com/p/hmpfr/wiki/GHCWithoutGMP
>>>
>>> The rationale for this change is the fact that despite much effort hmpfr
>>> is
>>> very unreliable on ghc that includes integer-gmp due to ghc deallocating
>>> GMP
>>> data that was allocated by MPFR at unpredictable times.
>>>
>>> Aleš and I hope that hmpfr can return to using integer-gmp once the
>>> proposal
>>>
>>>
>>> http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinReplacementforGMP
>>>
>>> to replace gmp with a modified gmp in ghc is implemented and made the
>>> default.
>>>
>>> Best regards,
>>> Michal
>>> --
>>> |o| Michal Konecny 
>>> |o|http://www-users.aston.ac.uk/~konecnym/
>>> |o|office: (+42) (0)121 204 3462
>>> |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston
>>>
>>> ___
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Learn You a Haskell for Great Good - a few doubts

[Alexander Solla]

On Fri, Mar 4, 2011 at 8:45 AM, Markus Läll  wrote:

>
> Would this also have an uncomputable order type? At least for comparing
> tuples you'd just:


You can tell if an enumeration will have an uncomputable order type by
whether or not your enumeration has to "count to infinity" before it can
continue.  For example, let's use top-left to bottom-right diagonals.  Then
you would have to "count infinitely many steps" (0,0), (1,1), (2,2), (3,3)
... before you could go to the next diagonal.  This excludes an enumeration
from being computable in the usual sense (or having a computable order
type).  As Daniel pointed out, every countable set can be put in
*some* computable
order, since it can inherit the order of the naturals through the
enumeration.


>
> lt :: (Integer,Integer) -> (Integer,Integer) -> Bool
> (a,b) `lt` (c,d) = let
>   sum1 = (a + b)
>   sum2 = (c + d)
>in if sum1 == sum2
>  then a < c
>  else sum1 < sum2


The order you impose is a bit broken, but the principle of using diagonals
is sound. (Consider (1,2) and (2,1):  under this order, (1,2) `lt` (2,1) and
(2,1) `lt` (1,2), so (1,2) == (2,1))

Indeed, the diagonal construction is how an enumeration of the rationals is
demonstrated.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Announce: new releases of bitset and funsat

[Denis Bueno]

Hello all,

Just a small announcement.

funsat has been bumped to 0.6.2. New in 0.6.2: works with ghc-6.12 and
fixed some space leaks.

http://hackage.haskell.org/package/funsat

bitset has been bumped to 1.1. New in 1.1: can easily convert between
the BitSet representation and the underlying Integer.

http://hackage.haskell.org/package/bitset

-- 
                              Denis

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

[Haskell-cafe] Convert a function to a string of operators?

[Evgeny Grablyk]

Hello!

I was wondering if it was possible to "convert" a function (which may
also call functions) to a plain list of operators on parameters.
Example:

foo a b = a + b
bar a b = a * b

baw a b c = bar (foo a b) c
baw' a b c = (a + b) * c

Any way to get `baw'' from `baw'?  Preferrably as a String.

-- 
Evgeny

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

Re: [Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)

[Daniel Peebles]

According to Duncan Coutts (whom I asked about this issue in #ghc), the
solution here is to use the new foreign import prim machinery to talk to
MPFR. This prevents GC from occurring during the MPFR calls and will make
everything work nicely without reimplementing GMP.

Dan

On Fri, Mar 4, 2011 at 3:09 PM, Daniel Peebles  wrote:

> Have you submitted a bug report to GHC of why it can't work with the
> current integer-gmp binding? I know that GHC's collector is collecting
> MPFR's temporary data, but maybe it'd be good to get a discussion going on
> what can be done to stop it from doing this even in the context of the
> existing integer-gmp + GHC's allocator (even if this needs to be a patch to
> MPFR to talk to GHC a bit here and there). Might it help to go through CMM
> like the GMP binding does, for example?
>
> I'd really like to see libraries that use GMP work nicely with GHC, without
> going and reimplementing GMP more slowly and so on.
>
> Dan
>
> 2011/3/3 Michal Konečný 
>
>> Dear all,
>>
>>
>> I am pleased to announce hmpfr-0.3.2, a new version of Aleš Bizjak's
>> bindings
>> to the MPFR arbitrary precision floating point arithmetic library.  The
>> changes in this version are quite small but significant:
>>
>> - support for MPFR 3.0.0 as well as MPFR 2.4.*
>> - dependency on integer-simple instead of integer-gmp
>>
>> The latter is most significant because unfortunately it makes it rather
>> more
>> difficult to install hmpfr.   Currently almost all binary distributions of
>> ghc
>> have integer-gmp compiled in to provide the Integer type via the standard
>> GMP
>> library.  Also haskell platform 2010.2.0.0 assumes that ghc has been
>> compiled
>> with integer-gmp although it makes no specific use of it.  Instructions on
>> how
>> to compile ghc and haskell platform with integer-simple instead of
>> integer-gmp
>> are on:
>>
>> http://code.google.com/p/hmpfr/wiki/GHCWithoutGMP
>>
>> The rationale for this change is the fact that despite much effort hmpfr
>> is
>> very unreliable on ghc that includes integer-gmp due to ghc deallocating
>> GMP
>> data that was allocated by MPFR at unpredictable times.
>>
>> Aleš and I hope that hmpfr can return to using integer-gmp once the
>> proposal
>>
>>
>> http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinReplacementforGMP
>>
>> to replace gmp with a modified gmp in ghc is implemented and made the
>> default.
>>
>> Best regards,
>> Michal
>> --
>> |o| Michal Konecny 
>> |o|http://www-users.aston.ac.uk/~konecnym/
>> |o|office: (+42) (0)121 204 3462
>> |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)

[Daniel Peebles]

Have you submitted a bug report to GHC of why it can't work with the current
integer-gmp binding? I know that GHC's collector is collecting MPFR's
temporary data, but maybe it'd be good to get a discussion going on what can
be done to stop it from doing this even in the context of the existing
integer-gmp + GHC's allocator (even if this needs to be a patch to MPFR to
talk to GHC a bit here and there). Might it help to go through CMM like the
GMP binding does, for example?

I'd really like to see libraries that use GMP work nicely with GHC, without
going and reimplementing GMP more slowly and so on.

Dan

2011/3/3 Michal Konečný 

> Dear all,
>
> I am pleased to announce hmpfr-0.3.2, a new version of Aleš Bizjak's
> bindings
> to the MPFR arbitrary precision floating point arithmetic library.  The
> changes in this version are quite small but significant:
>
> - support for MPFR 3.0.0 as well as MPFR 2.4.*
> - dependency on integer-simple instead of integer-gmp
>
> The latter is most significant because unfortunately it makes it rather
> more
> difficult to install hmpfr.   Currently almost all binary distributions of
> ghc
> have integer-gmp compiled in to provide the Integer type via the standard
> GMP
> library.  Also haskell platform 2010.2.0.0 assumes that ghc has been
> compiled
> with integer-gmp although it makes no specific use of it.  Instructions on
> how
> to compile ghc and haskell platform with integer-simple instead of
> integer-gmp
> are on:
>
> http://code.google.com/p/hmpfr/wiki/GHCWithoutGMP
>
> The rationale for this change is the fact that despite much effort hmpfr is
> very unreliable on ghc that includes integer-gmp due to ghc deallocating
> GMP
> data that was allocated by MPFR at unpredictable times.
>
> Aleš and I hope that hmpfr can return to using integer-gmp once the
> proposal
>
>
> http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinReplacementforGMP
>
> to replace gmp with a modified gmp in ghc is implemented and made the
> default.
>
> Best regards,
> Michal
> --
> |o| Michal Konecny 
> |o|http://www-users.aston.ac.uk/~konecnym/
> |o|office: (+42) (0)121 204 3462
> |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Thoughts on program annotations.

[Jason Dusek]

On Fri, Mar 4, 2011 at 07:01, wren ng thornton  wrote:
> where the annotation of MergeAnn is merged with the previous
> annotation up the tree (via mappend), thus allowing for
> annotations to be inherited and modified incrementally based
> on the Monoid instance; whereas the NewAnn constructor uses
> the annotation directly, overriding any contextual
> annotations. This can be helpful to reduce the amount of
> duplication in the AST, though how helpful will depend on how
> you plan to use/generate the ASTs.

  To handle this situation, I thought I'd leave it in the hands
  of the user (who will be me later) to use Data.Foldable.fold
  (or not) to arrive at the annotation when building up their
  tree of statements. I don't anticipate a problem with this but
  I may not use monoidal annotations on this AST for some time.
  (I anticipate using comments and raw text inclusions in the
  near future.)

--
Jason Dusek
Linux User #510144 | http://counter.li.org/

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

[Haskell-cafe] darcs hacking sprint #6 (1-3 April, Paris)

[Eric Kow]

Hi everybody,

Following up on my last message, the date and venue for the sixth Darcs
Hacking sprint has been confirmed.

Get out your berets everybody, because we're going to Paris!

Here are three things to know

1. Everybody is welcome to join us.  We'd love to have you, whatever
   your Haskell or Darcs hacking experience.  Also, if you've got a
   wacky idea for the future of version control, or a cool use for the
   Darcs library, you should join us too :-)

2. Please let us know if you're attending.  Just add your name to
   http://wiki.darcs.net/Sprints/2011-04 and you're good to go.
   You can also send us an email.

3. We can reimburse travel costs (within reason!).  Let us know if you'd
   like a reimbursement, and save your receipts.

   Many thanks to everybody who participated in our fundraising drives
   or who gave money on the side.  Thanks also to the Software Freedom
   Conservancy for making fundraising and reimbursements so painless!
   If you can't join us in person, but you'd like to cheer us on,
   say hello at http://darcs.net/donations.html!

Looking forward to seeing you!

Eric

PS. Berets optional.

-- 
Eric Kow 
For a faster response, try +44 (0)1273 64 2905 or
xmpp:ko...@jabber.fr (Jabber or Google Talk only)


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

Re: [Haskell-cafe] Learn You a Haskell for Great Good - a few doubts

[Markus Läll]

Sorry, I didn't mean to answer you in particular. I meant to say that for
tuples you could (I think) have an enumeration over them without requiring
any component be bounded.

An example of type (Integer, Integer) you would have:

[(0,0) ..] = [(0,0) (0,1) (1,0) (0,2) (1,1) (2,0) ... ]

where the order can be visualized by taking diagonals of a table starting
from the upper left:

0  1  2 ..
0 (0,0)  (0,1)  (0,2)
1 (1,0)  (1,1)  (1,2)
2 (2,0)  (2,1)  (2,2)
..

Would this also have an uncomputable order type? At least for comparing
tuples you'd just:

lt :: (Integer,Integer) -> (Integer,Integer) -> Bool
(a,b) `lt` (c,d) = let
  sum1 = (a + b)
  sum2 = (c + d)
   in if sum1 == sum2
 then a < c
 else sum1 < sum2


Implementing fromEnum looks like a bit harder problem..


--
Markus Läll




On Fri, Mar 4, 2011 at 5:12 AM, Daniel Fischer <
daniel.is.fisc...@googlemail.com> wrote:
>
> On Friday 04 March 2011 03:24:34, Markus wrote:
> > What about having the order by diagonals, like:
> >
> > 0 1 3
> > 2 4
> > 5
> >
> > and have none of the pair be bounded?
> >
>
> I tacitly assumed product order (lexicographic order).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Thoughts on program annotations.

[Stephen Tetley]

There's also Martin Erwig's Parametric Fortran - which looks largely
similar but hides some of the parametric types with existentials.

Check the papers on his website, epscially the PADL one:

http://web.engr.oregonstate.edu/~erwig/papers/abstracts.html

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

Re: [Haskell-cafe] Learn You a Haskell for Great Good - a few doubts

[Max Rabkin]

On Fri, Mar 4, 2011 at 17:37, Chris Smith  wrote:
> The most common use of Ord in real code, to be honest, is to use the value
> in some data structure like Data.Set.Set or Data.Map.Map, which requires Ord
> instances.  For this purpose, any Ord instance that is compatible with Eq
> will do fine.

It's true that you can build valid Maps and Sets with any valid
instance of Ord that defines a total order that is consistent with Eq,
and lookup, membership testing and insert will work. However, there
are operations on Maps and Sets which make the order visible to the
caller: min, max, splits, folds, etc.

--Max

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

Re: [Haskell-cafe] Learn You a Haskell for Great Good - a few doubts

[Ozgur Akgun]

On 4 March 2011 09:47, Karthick Gururaj  wrote:

> I'm not able to still appreciate the choice of the default ordering order,
>

I don't know if this will help you appreciate the default or not, but just
to say this default is concordant with the auto-derived Ord instances.

data Tuple3 a b c = Tuple3 a b c
deriving (Eq,Ord,Show)

ghci> sort [Tuple3 1 2 4, Tuple3 1 2 3, Tuple3 2 1 1, Tuple3 1 3 5]
[Tuple3 1 2 3,Tuple3 1 2 4,Tuple3 1 3 5,Tuple3 2 1 1]

ghci> sort [(1,2,4), (1,2,3), (2,1,1), (1,3,5)]
[(1,2,3),(1,2,4),(1,3,5),(2,1,1)]

No surprises here. Just another place where we have the lexicographic
ordering by default.

HTH,

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

Re: [Haskell-cafe] Learn You a Haskell for Great Good - a few doubts

[Chris Smith]

On Mar 4, 2011 2:49 AM, "Karthick Gururaj" 
wrote:
> > Ord has to be compatible with Eq, and none of these are.
> Hmm.. not true. Can you explain what do you mean by "compatibility"?

Compatibility would mean that x == y if and only if compare x y == EQ.  This
is not a restricrion enforced by the type system, but it is something that I
would think ought to be true (though it is not,for example, for the IEEE
floating point types; I personally consider that a bug and believe the IEEE
notions of comparison ought to be exposed in a different set of operations
rather than instances of Ord and Eq).  In this sense it is much like the
monad laws.  So whether it has to be true depends on what you mean by "has
to be".

> Ok - at this stage, I'll just take your word for it. I'm not able to
> still appreciate the choice of the default ordering order, but I need
> to wait until I get to see/develop some real code.

The most common use of Ord in real code, to be honest, is to use the value
in some data structure like Data.Set.Set or Data.Map.Map, which requires Ord
instances.  For this purpose, any Ord instance that is compatible with Eq
will do fine.

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

Re: [Haskell-cafe] HDF5 binding

[James Cook]

On Mar 4, 2011, at 8:25 AM, Ferenc Wagner wrote:


Hi,

This is fairly extensive indeed!  I got nowhere near this, but also  
took

a somewhat different angle, especially by using StorableArrays for
passing arrays around (I used HDF5 in conjunction with LaPack).  I  
also
experienced with going a little higher level here and there.   
Attributes
aren't implemented yet, because that would require making location  
ids a
type class.  An unsolved problem is the safe representation of  
ranks: I
went for generality by using lists for indexing, but it would be  
nice to

express dimensionality constraints in the types (with sane syntax).
Maybe there's a handy technique for this, I didn't explore the field.
Talking about indexing, choosing Fortran convention seems to be a
mistake in retrospect, but that's no big deal.


I've skimmed through your code, it looks good.  It's definitely a bit  
higher level than mine - mine is (intentionally) little more than a  
bunch of types and foreign imports with names changed minimally,  
mostly just uppercasing or lowercasing the "H5?" prefixes as needed.   
That approach seems to work really well for large C interfaces (like  
OpenGLRaw, etc.) if for no other reason than that it exposes the C  
interface via Haskell's much-better type system and documentation  
tools.  I'll read through yours in more detail, it looks like there  
are some good ideas there that I can apply when I start working on  
something higher-level.



I attach my code so you can get a better idea what I'm talking about,
maybe you can find some usable pieces.  Separating the generic hid  
type
into specific newtypes worked out to some extent, but maybe isn't a  
good

idea at the lowest level (where the FFI makes it automatic).  I'd need
broader experience with the HDF5 API to tell.


My experience isn't especially broad either, but from what I've seen a  
type-level approach for distinguishing hid_t usages ought to work, at  
least most of the time.  One thought I have is to use a phantom type  
parameter at the lowest level, so that foreign imports can either  
constrain it or not, as the situation seems to call for.


Thanks

-- James

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

Re: [Haskell-cafe] A practical Haskell puzzle

[Heinrich Apfelmus]

Yves Parès wrote:

Okay thanks I got the difference between both.
The 'exists' syntax seems very useful. Is it planned to be added to GHC in a
near future?


Probably not. But once GADTs become more prominent, there might be 
pressure to add first-class existential types to the language.


Note that GHC has long supported existential types, just not the 
explicit syntax.



Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


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

Re: [Haskell-cafe] A practical Haskell puzzle

[Heinrich Apfelmus]

Yitzchak Gale wrote:

Eric Mertens wrote:

(but I've had my head in Agda lately)


Indeed, coming across this problem tempted me
to abandon the real world and take refuge in Agda.


http://hpaste.org/44469/software_stack_puzzle


Wow, so simple, and no higher-rank types! This is the
best solution yet. I am now truly in awe of the power
of GADTs.


Just for reference, here a full version of my solution

  http://hpaste.org/44503/software_stack_puzzle_annotat

It's almost the same as Eric's solution except that he nicely fused the 
 dropC  and  takeC  functions into  runLayers , thereby eliminating the 
need for existential quantification.


However, note that GADTs subsume higher-rank types. With

  data Exists f where
 Exists :: f a -> Exists f

you can always encode them as

  exists a. f a = Exists f
  forall a. f a = (exists a. f a -> c) -> c = (Exists f -> c) -> c


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


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

Re: [Haskell-cafe] HDF5 binding

[Ferenc Wagner]

James Andrew Cook  writes:

> What an interesting coincidence, that makes at least three of
> us. Apparently it's an idea whose time has come.
>
> Mine is also an incomplete low-level binding but is currently under
> semi-active development and I aim to make it cover the entire hdf5.h
> interface.
>
> If anyone is interested in it I've put it on github at:
> https://github.com/mokus0/bindings-hdf5

Hi,

This is fairly extensive indeed!  I got nowhere near this, but also took
a somewhat different angle, especially by using StorableArrays for
passing arrays around (I used HDF5 in conjunction with LaPack).  I also
experienced with going a little higher level here and there.  Attributes
aren't implemented yet, because that would require making location ids a
type class.  An unsolved problem is the safe representation of ranks: I
went for generality by using lists for indexing, but it would be nice to
express dimensionality constraints in the types (with sane syntax).
Maybe there's a handy technique for this, I didn't explore the field.
Talking about indexing, choosing Fortran convention seems to be a
mistake in retrospect, but that's no big deal.

I attach my code so you can get a better idea what I'm talking about,
maybe you can find some usable pieces.  Separating the generic hid type
into specific newtypes worked out to some extent, but maybe isn't a good
idea at the lowest level (where the FFI makes it automatic).  I'd need
broader experience with the HDF5 API to tell.
-- 
Regards,
Feri.



hdf5.tgz
Description: GNU Unix tar archive
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: Haskell XML Toolbox Version 9.1

[Uwe Schmidt]

Haskell XML Toolbox 9.1

I would like to announce an update hxt-9.1 of the Haskell XML Toolbox.

Main changes compared to hxt-9.0 are

* space optimization of DOM tree for better performance for lager XML
  documents
* optimization of space used during parsing in native XML and HTML parsers
* a binding to the expat parser via hexpat

Cheers,

  Uwe


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

[Haskell-cafe] Getting started with http-enumerator

[C K Kashyap]

Hi,
I'd like to use http-enumerator for things that I've been using perl/Lwp
for. I tried looking but was not able to find good documentation for it.
Could someone please point me to simple examples?
Like posting a form, dealing with cookies etc.
Regards,
Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell IDE

[Gracjan Polak]

Ivan Lazar Miljenovic  gmail.com> writes:
> 
> Sounds similar to what haskell-indent does, except that it uses 2
> spaces rather than 4, backspace does the chars less, and TAB also has
> a version (albeit not as nice as the one in haskell-indentation) of
> the tab-cycle.
> 


I rejected haskell-indent some time ago, do not remember the reason now.

I think I'll give it a second chance.

-- 
Gracjan



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

Re: [Haskell-cafe] Haskell IDE

[Ivan Lazar Miljenovic]

On 4 March 2011 19:16, Gracjan Polak  wrote:
> Alexander Danilov  gmail.com> writes:
>
>>
>> 03.03.2011 16:05, Hauschild, Klaus (EXT) пишет:
>> > Hi Haskellers,
>> > whats your Haskell IDE of choise? Currently I use leksah. Is the
>> > EclipseFP Plugin for Eclipse a real alternative?
>> > Thanks
>> > Klaus
>> >
>> >
>>
>> Emacs, look at haskell wiki for details about haskell-mode.
>>
>
> Emacs is good as an editor for Haskell. Indentation is problematic.
>
> I'd like to have a indent mode that has following bindings:
> - TAB indents 4 chars more
> - Shift-TAB indents 4 chars less
> - RET - indents a line same as previous line unless last line had a block
>  opening keyword

Sounds similar to what haskell-indent does, except that it uses 2
spaces rather than 4, backspace does the chars less, and TAB also has
a version (albeit not as nice as the one in haskell-indentation) of
the tab-cycle.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com

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

Re: [Haskell-cafe] Learn You a Haskell for Great Good - a few doubts

[Karthick Gururaj]

On Fri, Mar 4, 2011 at 10:42 AM, Richard O'Keefe  wrote:
>
> On 4/03/2011, at 5:49 PM, Karthick Gururaj wrote:
>> I meant: there is no reasonable way of ordering tuples, let alone enum
>> them.
>
> There are several reasonable ways to order tuples.
>>
>> That does not mean we can't define them:
>> 1. (a,b) > (c,d) if a>c
>
> Not really reasonable because it isn't compatible with equality.
>> 2. (a,b) > (c,d) if b>d
>> 3. (a,b) > (c,d) if a^2 + b^2 > c^2 + d^2
>> 4. (a,b) > (c,d) if a*b > c*d
>
> Ord has to be compatible with Eq, and none of these are.
Hmm.. not true. Can you explain what do you mean by "compatibility"?

One of the following, and exactly one, must always hold, on a ordered
set (is this what you mean by "compatibility"?), for any arbitrary
legal selection of a, b, c and d.
a. (a, b) EQ (c, d)
b. (a, b) LT (c, d)
c. (a, b) GT (c, d)

All the definitions above are compatible in this sense.

> Lexicographic ordering is in wide use and fully compatible
> with Eq.
>> Which of
>> these is a reasonable definition?
>
>> The set of complex numbers do not
>> have a "default" ordering, due to this very issue.
>
> No, that's for another reason.  The complex numbers don't have
> a standard ordering because when you have a ring or field and
> you add an ordering, you want the two to be compatible, and
> there is no total order for the complex numbers that fits in
> the way required.
>>
>> When we do not have a "reasonable" way of ordering, I'd argue to not
>> have anything at all
>
> There is nothing unreasonable about lexicographic order.
> It makes an excellent default.
Ok - at this stage, I'll just take your word for it. I'm not able to
still appreciate the choice of the default ordering order, but I need
to wait until I get to see/develop some real code.

>>
>>
>> As a side note, the cardinality of rational numbers is the same as
>> those of integers - so both are "equally" infinite.
>
> Ah, here we come across the distinction between cardinals and
> ordinals.  Two sets can have the same cardinality but not be
> the same order type.  (Add 1 to the first infinite cardinal
> and you get the same cardinal back; add 1 to the first infinite
> ordinal and you don't get the same ordinal back.)

:) Ok. The original point was whether there is a reasonable way to
enumerate a tuple, I guess there is none.

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

Re: [Haskell-cafe] Haskell IDE

[Gracjan Polak]

Alexander Danilov  gmail.com> writes:

> 
> 03.03.2011 16:05, Hauschild, Klaus (EXT) пишет:
> > Hi Haskellers,
> > whats your Haskell IDE of choise? Currently I use leksah. Is the
> > EclipseFP Plugin for Eclipse a real alternative?
> > Thanks
> > Klaus
> >
> >
> 
> Emacs, look at haskell wiki for details about haskell-mode.
> 

Emacs is good as an editor for Haskell. Indentation is problematic.

I'd like to have a indent mode that has following bindings:
- TAB indents 4 chars more
- Shift-TAB indents 4 chars less
- RET - indents a line same as previous line unless last line had a block
  opening keyword


Indentation indents mostly too far right in current haskell-mode for my taste.

-- 
Gracjan



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