Re: [Haskell-cafe] arr considered harmful

2012-12-21 Thread Conal Elliott
Oh, I see Ross's trick. By quantifying over the domain  range types, they
can later be specialized to analysis-time types (like circuit labels) or to
run-time types (like Boolean or Integer).

On Thu, Dec 20, 2012 at 4:55 PM, Conal Elliott co...@conal.net wrote:

 If you require the circuit to be parametric in the value types, you can
 limit the types of function you can pass to arr to simple plumbing.
 See the netlist example at the end of my Fun of Programming slides (
 http://www.soi.city.ac.uk/~ross/papers/fop.html).


 I'm running into this same issue: I have something (another circuits
 formulation) that's almost an arrow but doesn't support arr. I'd like to
 use arrow notation, but then I run afoul of my missing arr. I'd like to
 understand Ross's suggestion and how to apply it. (I've read the FoP
 slides.)

 Ross: do you mean to say that you were able to implement arr and thus run
 your circuit examples via the standard arrow desugarer?

 Ryan: did you get a working solution to the problem you described for your
 Circuit arrow?

 Thanks.  -- Conal



 On Mon, Oct 31, 2011 at 6:52 PM, Paterson, Ross r.pater...@city.ac.ukwrote:

 Ryan Ingram writes:
  Most of the conversion from arrow syntax into arrows uses 'arr' to move
 components around. However, arr is totally opaque to the arrow itself, and
 prevents describing some very useful objects as arrows.

  For example, I would love to be able to use the arrow syntax to define
 objects of this type:

  data Circuit a b where
  Const :: Bool - Circuit () Bool
  Wire :: Circuit a a
  Delay :: Circuit a a
  And :: Circuit (Bool,Bool) Bool
  Or :: Circuit (Bool,Bool) Bool
  Not :: Circuit Bool Bool
  Then :: Circuit a b - Circuit b c - Circuit a c
  Pair :: Circuit a c - Circuit b d - Circuit (a,b) (c,d)
  First :: Circuit a b - Circuit (a,c) (b,c)
  Swap :: Circuit (a,b) (b,a)
  AssocL :: Circuit ((a,b),c) (a,(b,c))
  AssocR :: Circuit (a,(b,c)) ((a,b),c)
  Loop :: Circuit (a,b) (a,c) - Circuit b c
  etc.

  Then we can have code that examines this concrete data representation,
 converts it to VHDL, optimizes it, etc.

  However, due to the presence of the opaque 'arr', there's no way to
 make this type an arrow without adding an 'escape hatch'
  Arr :: (a - b) - Circuit a b
  which breaks the abstraction: circuit is supposed to represent an
 actual boolean circuit; (Arr not) is not a valid circuit because we've lost
 the information about the existence of a 'Not' gate.

 If you require the circuit to be parametric in the value types, you can
 limit the types of function you can pass to arr to simple plumbing.
 See the netlist example at the end of my Fun of Programming slides (
 http://www.soi.city.ac.uk/~ross/papers/fop.html).
 ___
 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] monoid pair of monoids?

2012-12-21 Thread Christopher Howard
On 12/20/2012 08:54 PM, Daniel Feltey wrote:
 You were only missing the restriction that both types a and b must be
 instances of Monoid in order to make Socket a b into an instance of Monoid.
 
 
 
 Dan Feltey

Thank you for your help. An additional question, if I might: For the
sake of elegance and simplicity, I modified the class and instances to
avoid the tuple aspect:

code:

data Socket2 a b = Socket2 a b
  deriving (Show)

instance (Monoid a, Monoid b) = Monoid (Socket2 a b) where
mempty = Socket2 mempty mempty
Socket2 a b `mappend` Socket2 w x = Socket2 (a `mappend` w) (b
`mappend` x)


Of course, I thought it would be likely I would want other classes and
instances with additional numbers of types:

code:

data Socket3 a b c = Socket3 a b c
  deriving (Show)

instance (Monoid a, Monoid b, Monoid c) = Monoid (Socket3 a b c) where
mempty = Socket3 mempty mempty mempty
Socket3 a b c `mappend` Socket3 w x y =
Socket3 (a `mappend` w) (b `mappend` x) (c `mappend` y)

data Socket4 a b c d = Socket4 a b c d
  deriving (Show)

instance (Monoid a, Monoid b, Monoid c, Monoid d) = Monoid (Socket4 a b
c d) where
mempty = Socket4 mempty mempty mempty mempty
Socket4 a b c d `mappend` Socket4 w x y z =
Socket4 (a `mappend` w) (b `mappend` x) (c `mappend` y) (d
`mappend` z)

data Socket 5 a b c d e... et cetera


Seeing as the pattern here is so rigid and obvious, I was wondering: is
it possible to abstract this even more? So I could, for instance, just
specify that I want a Socket with 8 types, and poof, it would be there?
Or is this as meta as we get? (I.e., without going to something like
Template Haskell.)

-- 
frigidcode.com



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


Re: [Haskell-cafe] category design approach for inconvenient concepts

2012-12-21 Thread Oleksandr Manzyuk
On Fri, Dec 21, 2012 at 4:40 AM, Alexander Solla alex.so...@gmail.com wrote:


 On Thu, Dec 20, 2012 at 12:53 PM, Oleksandr Manzyuk manz...@gmail.com
 wrote:

 I have no problems with the statement Objects of the category Hask
 are Haskell types.  Types are well-defined syntactic entities.  But
 what is a morphism in the category Hask from a to b?  Commonly, people
 say functions from a to b or functions a - b, but what does that
 mean?  What is a function as a mathematical object?  It is a plausible
 idea to say that a function from a to b is a closed term of type a -
 b (and terms are again well-defined syntactic entities).  How do we
 define composition?  Presumably, by

 f . g = \x - f (g x)

 This however already presupposes that we are dealing not with raw
 terms, but with their alpha-equivalence classes (otherwise the above
 is not well-defined as it depends on the choice of the variable x).
 Even if we mod out alpha-equivalence, so defined composition fails to
 be associative on the nose, up to equality of (alpha-equivalence
 classes of) terms.  Apparently, we want to consider equivalence
 classes of terms modulo some finer equivalence relation.  What is this
 equivalence relation?  Some kind of definitional equality?


 I don't see how associativity fails, if we mod out alpha-equivalence.  Can
 you give an example?  (If it involves the value undefined, I'll have
 something concrete to add vis a vis moral equivalence)

If you compute (f . g) . h, you'll get \x - (f . g) (h x) = \x - (\x
- f (g x)) (h x), whereas f . (g . h) produces \x - f ((g . h) x) =
\x - f ((\x - g (h x)) x).  As raw lambda-terms, these are distinct.
 They are equal if you allow beta-reduction in bodies of abstractions.
 That's what I meant when I said that we probably wanted to consider
equivalence classes modulo some equivalence relation.  That
hypothetical relation should obviously preserve beta-reduction in the
sense (\x - e) e' = [e'/x]e.

When we do equational reasoning about Haskell code, we apply certain
rules.  I think what I'm asking for is an explicit complete set of
such rules.

Note that sometimes you can also hear that the category of Haskell is
a suitable cpo category.  However, this is an answer to a slightly
different question: what is the categorical model of Haskell?  That
is, what kind of categories can Haskell programs be interpreted in.
What I'm after is a kind of universal syntactic Haskell category.  I
expect the situation to be similar to the simply typed lambda-calculus
but more technically involved.  The simply typed lambda-calculus can
be interpreted in any cartesian closed category, but it is also
possible to construct a cartesian closed category out of the simply
typed lambda-calculus.

As someone coming to Haskell and functional programming from category
theory background, I'm probably paying to much attention to details
that don't concern most practicing functional programmers...

Sasha
-- 
Oleksandr Manzyuk
http://oleksandrmanzyuk.wordpress.com

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


Re: [Haskell-cafe] monoid pair of monoids?

2012-12-21 Thread Steffen Schuldenzucker


Hi Christopher,

On 12/21/2012 09:27 AM, Christopher Howard wrote:

[...]
Of course, I thought it would be likely I would want other classes and
instances with additional numbers of types:

code:

data Socket3 a b c = Socket3 a b c
   deriving (Show)

instance (Monoid a, Monoid b, Monoid c) =  Monoid (Socket3 a b c) where
 mempty = Socket3 mempty mempty mempty
 Socket3 a b c `mappend` Socket3 w x y =
 Socket3 (a `mappend` w) (b `mappend` x) (c `mappend` y)

data Socket4 a b c d = Socket4 a b c d
   deriving (Show)

instance (Monoid a, Monoid b, Monoid c, Monoid d) =  Monoid (Socket4 a b
c d) where
 mempty = Socket4 mempty mempty mempty mempty
 Socket4 a b c d `mappend` Socket4 w x y z =
 Socket4 (a `mappend` w) (b `mappend` x) (c `mappend` y) (d
`mappend` z)

data Socket 5 a b c d e... et cetera


Seeing as the pattern here is so rigid and obvious, I was wondering: is
it possible to abstract this even more? So I could, for instance, just
specify that I want a Socket with 8 types, and poof, it would be there?
Or is this as meta as we get? (I.e., without going to something like
Template Haskell.)


If you are willing to encode your types as generalized tuples, i.e. 
heterogeneous lists, you can do that:


import Data.Monoid

data Nil = Nil
data Cons a bs = Cons a bs
-- type Socket 3 a b c = Cons a (Cons b (Cons c Nil))
-- (feel free to use operator syntax to prettify it)

instance Monoid Nil where
  mempty = Nil
  mappend Nil Nil = Nil

instance (Monoid a, Monoid bs) = Monoid (Cons a bs) where
  mempty = Cons mempty mempty
  mappend (Cons x1 ys1) (Cons x2 ys2) = Cons (mappend x1 x2) (mappend 
ys1 ys2)



-- Steffen

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


Re: [Haskell-cafe] monoid pair of monoids?

2012-12-21 Thread Ilya Portnov

Hi.

Christopher Howard писал 21.12.2012 14:27:



instance (Monoid a, Monoid b, Monoid c, Monoid d) = Monoid (Socket4 
a b

c d) where
mempty = Socket4 mempty mempty mempty mempty
Socket4 a b c d `mappend` Socket4 w x y z =
Socket4 (a `mappend` w) (b `mappend` x) (c `mappend` y) (d
`mappend` z)

data Socket 5 a b c d e... et cetera


Seeing as the pattern here is so rigid and obvious, I was wondering: 
is
it possible to abstract this even more? So I could, for instance, 
just
specify that I want a Socket with 8 types, and poof, it would be 
there?

Or is this as meta as we get? (I.e., without going to something like
Template Haskell.)


Something like

data a ::: b = a ::: b

infixl 5 :::

instance (Monoid a, Monoid b) = Monoid (a ::: b) where ...

So, Monoid instance for, say, (a ::: b ::: c) == ((a ::: b) ::: c) will 
(should) be inferred automatically.


WBR, Ilya Portnov

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


Re: [Haskell-cafe] monoid pair of monoids?

2012-12-21 Thread Sean Leather
On Fri, Dec 21, 2012 at 9:27 AM, Christopher Howard wrote:

 Thank you for your help. An additional question, if I might: For the
 sake of elegance and simplicity, I modified the class and instances to
 avoid the tuple aspect:

 data Socket2 a b = Socket2 a b
 instance (Monoid a, Monoid b) = Monoid (Socket2 a b) where

 Of course, I thought it would be likely I would want other classes and
 instances with additional numbers of types:

 data Socket3 a b c = Socket3 a b c
 instance (Monoid a, Monoid b, Monoid c) = Monoid (Socket3 a b c) where

 data Socket4 a b c d = Socket4 a b c d
 instance (Monoid a, Monoid b, Monoid c, Monoid d) = Monoid (Socket4 a b

 data Socket 5 a b c d e... et cetera
 

 Seeing as the pattern here is so rigid and obvious, I was wondering: is
 it possible to abstract this even more? So I could, for instance, just
 specify that I want a Socket with 8 types, and poof, it would be there?
 Or is this as meta as we get? (I.e., without going to something like
 Template Haskell.)


This perhaps isn't the answer you were looking for, but just in case you
weren't aware, there are already Monoid instances for tuples up to 5. You
can see this at:

http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-Monoid.html#g:1

Another possibility is a generic monoid class (using generic-deriving):

{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE FlexibleContexts #-}



import GHC.Generics



class GMonoid' f where
  gempty'  :: f x
  gappend' :: f x - f x - f x

instance GMonoid' U1 where
  gempty' = U1
  gappend' U1 U1 = U1

instance GMonoid a = GMonoid' (K1 i a) where
  gempty' = K1 gempty
  gappend' (K1 x) (K1 y) = K1 (x `gappend` y)

instance GMonoid' f = GMonoid' (M1 i c f) where
  gempty' = M1 gempty'
  gappend' (M1 x) (M1 y) = M1 (x `gappend'` y)

instance (GMonoid' f, GMonoid' h) = GMonoid' (f :*: h) where
  gempty' = gempty' :*: gempty'
  gappend' (x1 :*: y1) (x2 :*: y2) = gappend' x1 x2 :*: gappend' y1 y2



class GMonoid a where
  gempty  :: a
  gappend :: a - a - a

  default gempty :: (Generic a, GMonoid' (Rep a)) = a
  gempty = to gempty'

  default gappend :: (Generic a, GMonoid' (Rep a)) = a - a - a
  gappend x y = to (gappend' (from x) (from y))

instance (GMonoid b, GMonoid c) = GMonoid (b,c)
-- ...

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


[Haskell-cafe] ghc-heap-view now with recursive pretty-printing

2012-12-21 Thread Joachim Breitner
Hi,

I get the impression that blogs and planet.haskell.org are the best way
to disseminate information about new tools any more. Maybe a part of the
earlier importance has been taken over by GooglePlus, but not all,
leaving both blogs and GooglePlus less useful individually?

Anyways, I’d like to tell you about a feature of ghc-heap-view that I
have blogged about¹, namely the possibility to inspect heap values
recursively in GHCi or in your programs, including thunks, the
references between them and sharing:

Prelude :script /home/jojo/.cabal/share/ghc-heap-view-0.4.0.0/ghci
Prelude let x = [1..10]
Prelude x
[1,2,3,4,5,6,7,8,9,10]
Prelude :printHeap x
_bh [S# 1,S# 2,S# 3,S# 4,S# 5,S# 6,S# 7,S# 8,S# 9,S# 10]

Note that the tools shows us that the list is a list of S# constructors,
and also that it is still hidden behind a blackhole. After running
System.Mem.performGC, this would disappear.


Prelude let x = Just (1 + 1)
Prelude :printHeap x
Just _bco
Prelude x
Just 2
Prelude System.Mem.performGC
Prelude :printHeap x
Just (S# 2)

Here, we see how the calculation was deferred until forced by showing
the value of x. The name _bco stands for a bytecode object as used by
the interpreter. Getting useful information from them is a bit harder
than for compiled thunks, so for more accurate results put the code in a
Haskell source file, compile it and use the GHC.HeapView API to print
the interesting parts.


Prelude let a = hi
Prelude let partial = (a ++)
Prelude partial 
hi
Prelude System.Mem.performGC
Prelude let x = (a, partial)
Prelude :printHeap x
let x1 = hi
in (x1,_fun x1)

This demonstrates a partial application. The information which function
is called there (++ in this case) is lost at runtime, but we still see
that the second element of the tuple is a partial application of some
value to the first element.


Prelude let s = ho
Prelude let x = cycle s
Prelude length (take 100 (show x))
100
Prelude System.Mem.performGC
Prelude :printHeap x
let x0 = C# 'h' : C# 'o' : x0
in x0
Prelude let y = map Data.Char.toUpper x
Prelude length (take 100 (show y))
100
Prelude :printHeap y
C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' 
: C# 'O' : _bh (C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : 
C# 'O' : ... : ...)

The cyclic, tying-the-knot structure of cycle is very visible. But can
also see how easily it is broken, in this case by mapping a function
over the list.


Prelude let {x = 'H' : y ; y = 'o' : x }
Prelude length (show (take 10 x, take 10 y)) `seq` return ()
Prelude System.Mem.performGC
Prelude :printHeap (x,y)
let x1 = C# 'H' : x3
x3 = C# 'o' : x1
in (x1,x3)

If you want to look at multiple variables at once, just pass a tuple to
printHeap


I hope you’ll find it useful, and I am happy to hear about other
features that you might be interested in.

Also, if you don’t know about it, a graphical and interactive variant of
this is available as ghc-vis².

Greetings,
Joachim

¹ 
http://www.joachim-breitner.de/blog/archives/580-GHCi-integration-for-GHC.HeapView.html
² http://felsin9.de/nnis/ghc-vis/
-- 
Joachim nomeata Breitner
  m...@joachim-breitner.de  |  nome...@debian.org  |  GPG: 0x4743206C
  xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/



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


[Haskell-cafe] MPTC or functional dependencies?

2012-12-21 Thread Petr P
Dear Haskellers,

I'm working on a small library for representing semigroup (or monoid)
actions on a set http://hackage.haskell.org/package/semigroups-actions.
The MultiParamTypeClasses extension seems to be best suited for the task,
as a group can act on many sets, and a set can be acted on by different
groups:

-- | Represents an action of semigroup @g@ to set @a@.
--
-- Laws: @'Endo' . 'act'@ must be a homomorphism of semigroups.
class Semigroup g = SemigroupAct g a where
act :: g - (a - a)

But soon I realized that with MPTC the compiler has problems inferring
types and I had to explicitly specify types when using `act` in many
places. Because it seems that in most cases a set will have only a single
group acting on it, I was thinking about using FDs:

class Semigroup g = SemigroupAct g a | a - g where

But on the other hand, this can limit the generality of the type class. I
cannot decide which one I should choose.

What would you suggest? According to your experience, would you choose
plain MPTC or FD?

Best regards,
Petr Pudlak
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] MPTC or functional dependencies?

2012-12-21 Thread Kim-Ee Yeoh
Petr,

Your subject header is misleading: FDs don't make sense without MPTCs.

As you acknowledge at the end, what you're ultimately asking is: to FD or
not to FD.

Note also, the contemporary debate has shifted to TFs (type families) vs
FDs.


-- Kim-Ee


On Fri, Dec 21, 2012 at 7:38 PM, Petr P petr@gmail.com wrote:

 Dear Haskellers,

 I'm working on a small library for representing semigroup (or monoid)
 actions on a set http://hackage.haskell.org/package/semigroups-actions.
 The MultiParamTypeClasses extension seems to be best suited for the task,
 as a group can act on many sets, and a set can be acted on by different
 groups:

 -- | Represents an action of semigroup @g@ to set @a@.
 --
 -- Laws: @'Endo' . 'act'@ must be a homomorphism of semigroups.
 class Semigroup g = SemigroupAct g a where
 act :: g - (a - a)

 But soon I realized that with MPTC the compiler has problems inferring
 types and I had to explicitly specify types when using `act` in many
 places. Because it seems that in most cases a set will have only a single
 group acting on it, I was thinking about using FDs:

 class Semigroup g = SemigroupAct g a | a - g where

 But on the other hand, this can limit the generality of the type class. I
 cannot decide which one I should choose.

 What would you suggest? According to your experience, would you choose
 plain MPTC or FD?

 Best regards,
 Petr Pudlak


 ___
 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] arr considered harmful

2012-12-21 Thread Kim-Ee Yeoh
Hey Conal,

 I have something (another circuits formulation) that's almost an arrow
but doesn't support arr.

Have you seen Adam Megacz's generalized arrows?

http://www.cs.berkeley.edu/~megacz/garrows/



-- Kim-Ee


On Fri, Dec 21, 2012 at 7:55 AM, Conal Elliott co...@conal.net wrote:

 If you require the circuit to be parametric in the value types, you can
 limit the types of function you can pass to arr to simple plumbing.
 See the netlist example at the end of my Fun of Programming slides (
 http://www.soi.city.ac.uk/~ross/papers/fop.html).


 I'm running into this same issue: I have something (another circuits
 formulation) that's almost an arrow but doesn't support arr. I'd like to
 use arrow notation, but then I run afoul of my missing arr. I'd like to
 understand Ross's suggestion and how to apply it. (I've read the FoP
 slides.)

 Ross: do you mean to say that you were able to implement arr and thus run
 your circuit examples via the standard arrow desugarer?

 Ryan: did you get a working solution to the problem you described for your
 Circuit arrow?

 Thanks.  -- Conal



 On Mon, Oct 31, 2011 at 6:52 PM, Paterson, Ross r.pater...@city.ac.ukwrote:

 Ryan Ingram writes:
  Most of the conversion from arrow syntax into arrows uses 'arr' to move
 components around. However, arr is totally opaque to the arrow itself, and
 prevents describing some very useful objects as arrows.

  For example, I would love to be able to use the arrow syntax to define
 objects of this type:

  data Circuit a b where
  Const :: Bool - Circuit () Bool
  Wire :: Circuit a a
  Delay :: Circuit a a
  And :: Circuit (Bool,Bool) Bool
  Or :: Circuit (Bool,Bool) Bool
  Not :: Circuit Bool Bool
  Then :: Circuit a b - Circuit b c - Circuit a c
  Pair :: Circuit a c - Circuit b d - Circuit (a,b) (c,d)
  First :: Circuit a b - Circuit (a,c) (b,c)
  Swap :: Circuit (a,b) (b,a)
  AssocL :: Circuit ((a,b),c) (a,(b,c))
  AssocR :: Circuit (a,(b,c)) ((a,b),c)
  Loop :: Circuit (a,b) (a,c) - Circuit b c
  etc.

  Then we can have code that examines this concrete data representation,
 converts it to VHDL, optimizes it, etc.

  However, due to the presence of the opaque 'arr', there's no way to
 make this type an arrow without adding an 'escape hatch'
  Arr :: (a - b) - Circuit a b
  which breaks the abstraction: circuit is supposed to represent an
 actual boolean circuit; (Arr not) is not a valid circuit because we've lost
 the information about the existence of a 'Not' gate.

 If you require the circuit to be parametric in the value types, you can
 limit the types of function you can pass to arr to simple plumbing.
 See the netlist example at the end of my Fun of Programming slides (
 http://www.soi.city.ac.uk/~ross/papers/fop.html).
 ___
 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] MPTC or functional dependencies?

2012-12-21 Thread Petr P
  Hi Kim-Ee,

you're right, it's a bit misleading.

I thought about TFs too, personally I mostly prefer them over FDs, but I'd
like the library available for as many compilers as possible. 'semigroups'
is just Haskell 98 and I'd like to keep the requirements similarly low.

  Best regards,
  Petr Pudlak


2012/12/21 Kim-Ee Yeoh k...@atamo.com

 Petr,

 Your subject header is misleading: FDs don't make sense without MPTCs.

 As you acknowledge at the end, what you're ultimately asking is: to FD or
 not to FD.

 Note also, the contemporary debate has shifted to TFs (type families) vs
 FDs.


 -- Kim-Ee


 On Fri, Dec 21, 2012 at 7:38 PM, Petr P petr@gmail.com wrote:

 Dear Haskellers,

 I'm working on a small library for representing semigroup (or monoid)
 actions on a set http://hackage.haskell.org/package/semigroups-actions.
 The MultiParamTypeClasses extension seems to be best suited for the task,
 as a group can act on many sets, and a set can be acted on by different
 groups:

 -- | Represents an action of semigroup @g@ to set @a@.
 --
 -- Laws: @'Endo' . 'act'@ must be a homomorphism of semigroups.
 class Semigroup g = SemigroupAct g a where
 act :: g - (a - a)

 But soon I realized that with MPTC the compiler has problems inferring
 types and I had to explicitly specify types when using `act` in many
 places. Because it seems that in most cases a set will have only a single
 group acting on it, I was thinking about using FDs:

 class Semigroup g = SemigroupAct g a | a - g where

 But on the other hand, this can limit the generality of the type class. I
 cannot decide which one I should choose.

 What would you suggest? According to your experience, would you choose
 plain MPTC or FD?

 Best regards,
 Petr Pudlak


 ___
 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] Layer on a layer of record syntax in the type synonym?

2012-12-21 Thread Christopher Howard
Using a simple type I gave earlier from my monadic type question...

code:

data Socket3 a b c = Socket3 a b c
  deriving (Show)


Is it possible somehow to layer on record syntax onto a synonym of the type?

The idea would be something like this...

code:

type SpaceShip =
  Socket3 { engine :: Last Engine
  , hull :: Last Hull
  , guns :: [Guns]
  }


...purely for the convenience. But this doesn't seem to work with type
as it assumes you are referring to already made constructors, and
evidently newtype only allows use of a single record. I could wrap it
in a normal data declaration but that would add an extra layer of
complexity I think.

-- 
frigidcode.com



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


Re: [Haskell-cafe] MPTC or functional dependencies?

2012-12-21 Thread Roman Cheplyaka
* Petr P petr@gmail.com [2012-12-21 13:38:21+0100]
 Dear Haskellers,
 
 I'm working on a small library for representing semigroup (or monoid)
 actions on a set http://hackage.haskell.org/package/semigroups-actions.
 The MultiParamTypeClasses extension seems to be best suited for the task,
 as a group can act on many sets, and a set can be acted on by different
 groups:
 
 -- | Represents an action of semigroup @g@ to set @a@.
 --
 -- Laws: @'Endo' . 'act'@ must be a homomorphism of semigroups.
 class Semigroup g = SemigroupAct g a where
 act :: g - (a - a)
 
 But soon I realized that with MPTC the compiler has problems inferring
 types and I had to explicitly specify types when using `act` in many
 places. Because it seems that in most cases a set will have only a single
 group acting on it, I was thinking about using FDs:
 
 class Semigroup g = SemigroupAct g a | a - g where
 
 But on the other hand, this can limit the generality of the type class. I
 cannot decide which one I should choose.
 
 What would you suggest? According to your experience, would you choose
 plain MPTC or FD?

Another option to consider is not to make this a type class at all.

Something like

  newtype SemigroupAction g a = SemigroupAction { act :: g - a - a }

Instead of specifying types you'll be passing SemigroupAction values
(which is arguably less tedious). Plus you don't have to do newtype
wrapping of types and can have as many actions as you want even for the
same pairs of types.

Roman

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


Re: [Haskell-cafe] Layer on a layer of record syntax in the type synonym?

2012-12-21 Thread Ivan Lazar Miljenovic
On 22 December 2012 00:36, Christopher Howard
christopher.how...@frigidcode.com wrote:
 Using a simple type I gave earlier from my monadic type question...

 code:
 
 data Socket3 a b c = Socket3 a b c
   deriving (Show)
 

 Is it possible somehow to layer on record syntax onto a synonym of the type?

 The idea would be something like this...

 code:
 
 type SpaceShip =
   Socket3 { engine :: Last Engine
   , hull :: Last Hull
   , guns :: [Guns]
   }
 

 ...purely for the convenience. But this doesn't seem to work with type
 as it assumes you are referring to already made constructors, and
 evidently newtype only allows use of a single record. I could wrap it
 in a normal data declaration but that would add an extra layer of
 complexity I think.

No, you can't suddenly add records in just for a type alias.  You
might be able to create lenses though for setters/getters, though if
you just want getters you can just write them yourself.


 --
 frigidcode.com


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




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

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


Re: [Haskell-cafe] Layer on a layer of record syntax in the type synonym?

2012-12-21 Thread Daniel Trstenjak

Hi Christopher,

On Fri, Dec 21, 2012 at 04:36:04AM -0900, Christopher Howard wrote:
 Using a simple type I gave earlier from my monadic type question...
 
 code:
 
 data Socket3 a b c = Socket3 a b c
   deriving (Show)
 
 
 Is it possible somehow to layer on record syntax onto a synonym of the type?
 
 The idea would be something like this...
 
 code:
 
 type SpaceShip =
   Socket3 { engine :: Last Engine
   , hull :: Last Hull
   , guns :: [Guns]
   }
 
 
 ...purely for the convenience. But this doesn't seem to work with type
 as it assumes you are referring to already made constructors, and
 evidently newtype only allows use of a single record. I could wrap it
 in a normal data declaration but that would add an extra layer of
 complexity I think.

I don't know in which context you would like to use the SpaceShip type,
but the solution using the very generic Socket3 might bite you later,
because you don't have a concrete type for your SpaceShip and can't 
identify it.

Why having a Socket3 in the first place, what's the point of it?



 
 -- 
 frigidcode.com
 



 ___
 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] Layer on a layer of record syntax in the type synonym?

2012-12-21 Thread Nicolas Trangez
On Fri, 2012-12-21 at 04:36 -0900, Christopher Howard wrote:
 Using a simple type I gave earlier from my monadic type question...
 
 code:
 
 data Socket3 a b c = Socket3 a b c
   deriving (Show)
 
 
 Is it possible somehow to layer on record syntax onto a synonym of the type?
 
 The idea would be something like this...
 
 code:
 
 type SpaceShip =
   Socket3 { engine :: Last Engine
   , hull :: Last Hull
   , guns :: [Guns]
   }
 
 
 ...purely for the convenience. But this doesn't seem to work with type
 as it assumes you are referring to already made constructors, and
 evidently newtype only allows use of a single record. I could wrap it
 in a normal data declaration but that would add an extra layer of
 complexity I think.

Although this 'Socket3' data type which all of a sudden should be
aliased as 'SpaceShip' feels/looks really strange (are you sure that's
the right way to reach whatever the goal is?), you could use lenses:

import Control.Lens

data Socket3 a b c = Socket3 a b c
  deriving (Show)

data Last a = Last a deriving Show
data Engine = Engine deriving Show
data Hull = Hull deriving Show
data Gun = Gun deriving Show

type SpaceShip = Socket3 (Last Engine) (Last Hull) [Gun]

engine :: Simple Lens SpaceShip (Last Engine)
engine = lens get lset
  where
get (Socket3 a _ _) = a
lset (Socket3 _ b c) a' = Socket3 a' b c

hull :: Simple Lens SpaceShip (Last Hull)
hull = lens get lset
  where
get (Socket3 _ b _ ) = b
lset (Socket3 a _ c) b' = Socket3 a b' c

guns :: Simple Lens SpaceShip [Gun]
guns = lens get lset
  where
get (Socket3 _ _ c) =  c
lset (Socket3 a b _) = Socket3 a b

main :: IO ()
main = do
print $ s0 ^. engine
print $ s0 ^. guns

let s1 = guns .~ [Gun, Gun] $ s0
print s1
print $ s1 ^. guns
  where
s0 :: SpaceShip
s0 = Socket3 (Last Engine) (Last Hull) []

(I'm no Lens expert so maybe there are better ways than manually
creating these Lens instances, or make them shorter/abstract something
out)

Nicolas


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


Re: [Haskell-cafe] Categories (cont.)

2012-12-21 Thread Tillmann Rendel

Hi,

Christopher Howard wrote:

instance Category ...


The Category class is rather restricted:

Restriction 1:
You cannot choose what the objects of the category are. Instead, the 
objects are always all Haskell types. You cannot choose anything at 
all about the objects.


Restriction 2:
You cannot freely choose what the morphisms of the category are. 
Instead, the morphisms are always Haskell values. (To some degree, you 
can choose *which* values you want to use).



These restrictions disallow many categories. For example, the category 
where the objects are natural numbers and there is a morphism from m to 
n if m is greater than or equal to n cannot be expressed directly: 
Natural numbers are not Haskell types; and is bigger than or equal to 
is not a Haskell value.


  Tillmann

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


[Haskell-cafe] Substituting values

2012-12-21 Thread Radical
Sometimes I'll need something like:

  if value == Foo then Bar else value

Or some syntactic variation thereof:

  case value of { Foo - Bar; _ - value }

Is there a better/shorter way to do it? I'm surprised that it's more
complicated to substitute a value on its own than e.g. in a list, using
filter. Or perhaps I'm missing the right abstraction?

Thanks,

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


[Haskell-cafe] Fighting research paper bit-rot

2012-12-21 Thread cheater cheater
Hi guys,
after yet another episode of trying to figure out why library code
doesn't make any sense when reading the related paper, I decided to
start a small wiki just for the purpose of describing differences
between what's in the paper and what's in the code.

The first article can be found at:

http://functionalpapersupdated.wikia.com/wiki/Transactional_memory_with_data_invariants

This one was tricky: it was the check from stm-invariants.pdf. There
is a check in the STM library which is a completely different
function. The check from the paper is in another module and library
and is called alwaysSucceeds.

Everyone's more than welcome to add their favourite papers and
describe the differences. The wiki is freely editable.

Hopefully it can, with time, grow to be of help to anyone trying to
learn about Haskell or category theory or functional programming in
general.

I can't promise a huge amount of updates on my side (I'm just a guy
learning how to use Haskell, not a researcher) but hopefully this
great community can make it happen :)

If you're a publishing author, and you know of such updates to your
papers, please consider starting a page for your paper. It's also a
good place to track the implementations of ideas described in such
papers, especially in case there are multiple ones or the
implementation hasn't been discussed in the paper itself.

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


Re: [Haskell-cafe] Categories (cont.)

2012-12-21 Thread Chris Smith
It would definitely be nice to be able to work with a partial Category
class, where for example the objects could be constrained to belong to a
class.  One could then restrict a Category to a type level representation
of the natural numbers or any other desired set.  Kind polymorphism should
make this easy to define, but I still don't have a good feel for whether it
is worth the complexity.
On Dec 21, 2012 6:37 AM, Tillmann Rendel ren...@informatik.uni-marburg.de
wrote:

 Hi,

 Christopher Howard wrote:

 instance Category ...


 The Category class is rather restricted:

 Restriction 1:
 You cannot choose what the objects of the category are. Instead, the
 objects are always all Haskell types. You cannot choose anything at all
 about the objects.

 Restriction 2:
 You cannot freely choose what the morphisms of the category are. Instead,
 the morphisms are always Haskell values. (To some degree, you can choose
 *which* values you want to use).


 These restrictions disallow many categories. For example, the category
 where the objects are natural numbers and there is a morphism from m to n
 if m is greater than or equal to n cannot be expressed directly: Natural
 numbers are not Haskell types; and is bigger than or equal to is not a
 Haskell value.

   Tillmann

 __**_
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Fighting research paper bit-rot

2012-12-21 Thread Patrick Mylund Nielsen
Thanks, this had me pretty confused too. STM.check itself also differs from
in earlier versions of the library where it returned () or undefined.


On Fri, Dec 21, 2012 at 8:35 PM, cheater cheater cheate...@gmail.comwrote:

 Hi guys,
 after yet another episode of trying to figure out why library code
 doesn't make any sense when reading the related paper, I decided to
 start a small wiki just for the purpose of describing differences
 between what's in the paper and what's in the code.

 The first article can be found at:


 http://functionalpapersupdated.wikia.com/wiki/Transactional_memory_with_data_invariants

 This one was tricky: it was the check from stm-invariants.pdf. There
 is a check in the STM library which is a completely different
 function. The check from the paper is in another module and library
 and is called alwaysSucceeds.

 Everyone's more than welcome to add their favourite papers and
 describe the differences. The wiki is freely editable.

 Hopefully it can, with time, grow to be of help to anyone trying to
 learn about Haskell or category theory or functional programming in
 general.

 I can't promise a huge amount of updates on my side (I'm just a guy
 learning how to use Haskell, not a researcher) but hopefully this
 great community can make it happen :)

 If you're a publishing author, and you know of such updates to your
 papers, please consider starting a page for your paper. It's also a
 good place to track the implementations of ideas described in such
 papers, especially in case there are multiple ones or the
 implementation hasn't been discussed in the paper itself.

 ___
 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] Fighting research paper bit-rot

2012-12-21 Thread cheater cheater
Wow. Learning that there's anyone out there who finds this useful is
one thing.. getting that after 3 minutes is another level of
satisfying :)

On Fri, Dec 21, 2012 at 8:39 PM, Patrick Mylund Nielsen
hask...@patrickmylund.com wrote:
 Thanks, this had me pretty confused too. STM.check itself also differs from
 in earlier versions of the library where it returned () or undefined.


 On Fri, Dec 21, 2012 at 8:35 PM, cheater cheater cheate...@gmail.com
 wrote:

 Hi guys,
 after yet another episode of trying to figure out why library code
 doesn't make any sense when reading the related paper, I decided to
 start a small wiki just for the purpose of describing differences
 between what's in the paper and what's in the code.

 The first article can be found at:


 http://functionalpapersupdated.wikia.com/wiki/Transactional_memory_with_data_invariants

 This one was tricky: it was the check from stm-invariants.pdf. There
 is a check in the STM library which is a completely different
 function. The check from the paper is in another module and library
 and is called alwaysSucceeds.

 Everyone's more than welcome to add their favourite papers and
 describe the differences. The wiki is freely editable.

 Hopefully it can, with time, grow to be of help to anyone trying to
 learn about Haskell or category theory or functional programming in
 general.

 I can't promise a huge amount of updates on my side (I'm just a guy
 learning how to use Haskell, not a researcher) but hopefully this
 great community can make it happen :)

 If you're a publishing author, and you know of such updates to your
 papers, please consider starting a page for your paper. It's also a
 good place to track the implementations of ideas described in such
 papers, especially in case there are multiple ones or the
 implementation hasn't been discussed in the paper itself.

 ___
 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] Troubles with DLLs

2012-12-21 Thread Henk-Jan van Tuyl


L.S.,

I am having troubles with DLLs; my application (Haskell, C and C++) gives  
several messages about DLLs not being found. I added these one by one to  
the current directory. At a certain point there are just error messages  
about null pointers and Segmentation fault/access violation in generated  
code. When I try to load my application in GHCi, I get more messages  
about missing DLLs, up to a point where GHCi refuses to load a library  
because of an unknown section (a bug to be solved in GHC 7.6.2). (Several  
other programs have the same problem.)


Now I am still stuck with a null pointer error message.
1) How can I find out which DLLs my application needs (and which  
package/library is to blame for it) and
2) how can I find the error location when the crash occurs in C/C++ code  
(it might be something else than a missing DLL of course)?


My system:
Windows XP + MinGW/MSYS
Haskell platform 2012.4.0.0

The application uses wxHaskell.

Regards,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

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


Re: [Haskell-cafe] arr considered harmful

2012-12-21 Thread Conal Elliott
Thanks, Kim-Ee. Adam M's garrows look very useful for what I'm doing.  --
Conal


On Fri, Dec 21, 2012 at 5:14 AM, Kim-Ee Yeoh k...@atamo.com wrote:

 Hey Conal,

  I have something (another circuits formulation) that's almost an arrow
 but doesn't support arr.

 Have you seen Adam Megacz's generalized arrows?

 http://www.cs.berkeley.edu/~megacz/garrows/



 -- Kim-Ee


 On Fri, Dec 21, 2012 at 7:55 AM, Conal Elliott co...@conal.net wrote:

 If you require the circuit to be parametric in the value types, you can
 limit the types of function you can pass to arr to simple plumbing.
 See the netlist example at the end of my Fun of Programming slides (
 http://www.soi.city.ac.uk/~ross/papers/fop.html).


 I'm running into this same issue: I have something (another circuits
 formulation) that's almost an arrow but doesn't support arr. I'd like to
 use arrow notation, but then I run afoul of my missing arr. I'd like to
 understand Ross's suggestion and how to apply it. (I've read the FoP
 slides.)

 Ross: do you mean to say that you were able to implement arr and thus run
 your circuit examples via the standard arrow desugarer?

 Ryan: did you get a working solution to the problem you described for
 your Circuit arrow?

 Thanks.  -- Conal



 On Mon, Oct 31, 2011 at 6:52 PM, Paterson, Ross r.pater...@city.ac.ukwrote:

 Ryan Ingram writes:
  Most of the conversion from arrow syntax into arrows uses 'arr' to
 move components around. However, arr is totally opaque to the arrow itself,
 and prevents describing some very useful objects as arrows.

  For example, I would love to be able to use the arrow syntax to define
 objects of this type:

  data Circuit a b where
  Const :: Bool - Circuit () Bool
  Wire :: Circuit a a
  Delay :: Circuit a a
  And :: Circuit (Bool,Bool) Bool
  Or :: Circuit (Bool,Bool) Bool
  Not :: Circuit Bool Bool
  Then :: Circuit a b - Circuit b c - Circuit a c
  Pair :: Circuit a c - Circuit b d - Circuit (a,b) (c,d)
  First :: Circuit a b - Circuit (a,c) (b,c)
  Swap :: Circuit (a,b) (b,a)
  AssocL :: Circuit ((a,b),c) (a,(b,c))
  AssocR :: Circuit (a,(b,c)) ((a,b),c)
  Loop :: Circuit (a,b) (a,c) - Circuit b c
  etc.

  Then we can have code that examines this concrete data representation,
 converts it to VHDL, optimizes it, etc.

  However, due to the presence of the opaque 'arr', there's no way to
 make this type an arrow without adding an 'escape hatch'
  Arr :: (a - b) - Circuit a b
  which breaks the abstraction: circuit is supposed to represent an
 actual boolean circuit; (Arr not) is not a valid circuit because we've lost
 the information about the existence of a 'Not' gate.

 If you require the circuit to be parametric in the value types, you can
 limit the types of function you can pass to arr to simple plumbing.
 See the netlist example at the end of my Fun of Programming slides (
 http://www.soi.city.ac.uk/~ross/papers/fop.html).
 ___
 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] Categories (cont.)

2012-12-21 Thread Jay Sulzberger



On Fri, 21 Dec 2012, Chris Smith cdsm...@gmail.com wrote:


It would definitely be nice to be able to work with a partial Category
class, where for example the objects could be constrained to belong to a
class.  One could then restrict a Category to a type level representation
of the natural numbers or any other desired set.  Kind polymorphism should
make this easy to define, but I still don't have a good feel for whether it
is worth the complexity.


Indeed this sort of thing can obviously be done.  But it will
require some work.  The question is where, when, and how much
effort, which may mean money, it will take.  One encouraging thing
is that recently more people understand that type
checking/inference in the style of ML/Haskell/etc. is not so
hard, and that general constraint solvers/SMT systems can do the
job.  Getting the compiler to make use of the results of such type
estimates/assignments is the hard part today I think.

Last night I discovered the best blurb for the program:

  http://www.cis.upenn.edu/~sweirich/plmw12/Slides/plmw12-Pierce.pdf

via the subReddit:

  http://www.reddit.com/r/dependent_types/

oo--JS.



On Dec 21, 2012 6:37 AM, Tillmann Rendel ren...@informatik.uni-marburg.de
wrote:


Hi,

Christopher Howard wrote:


instance Category ...



The Category class is rather restricted:

Restriction 1:
You cannot choose what the objects of the category are. Instead, the
objects are always all Haskell types. You cannot choose anything at all
about the objects.

Restriction 2:
You cannot freely choose what the morphisms of the category are. Instead,
the morphisms are always Haskell values. (To some degree, you can choose
*which* values you want to use).


These restrictions disallow many categories. For example, the category
where the objects are natural numbers and there is a morphism from m to n
if m is greater than or equal to n cannot be expressed directly: Natural
numbers are not Haskell types; and is bigger than or equal to is not a
Haskell value.

  Tillmann

__**_
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Layer on a layer of record syntax in the type synonym?

2012-12-21 Thread Christopher Howard
On 12/21/2012 04:52 AM, Daniel Trstenjak wrote:
 
 Why having a Socket3 in the first place, what's the point of it?
 

The idea was to have some generic structures (Sockets) which were
already instanced into the Monoids-within-Monoids abstraction, yet could
still be made concrete into anything more specific.

So, I have...

code:

data Socket3 a b c = Socket3 a b c
  deriving (Show)

instance (Monoid a, Monoid b, Monoid c) = Monoid (Socket3 a b c) where
mempty = Socket3 mempty mempty mempty
Socket3 a b c `mappend` Socket3 w x y =
Socket3 (a  w) (b  x) (c  y)

nullSocket3 :: (Monoid a, Monoid b, Monoid c) = Socket3 a b c
nullSocket3 = Socket3 mempty mempty mempty


...which allows me to have...

code:

type ShipSys = Socket3 (Last Engine) (Last RotThruster) [LinThruster]

nullShipSys :: ShipSys
nullShipSys = nullSocket3

setEngineSocket (Socket3 a b c) x = Socket3 x b c

engineSys :: Engine - ShipSys
engineSys a = setEngineSocket nullShipSys (Last (Just a))

mk1Engine = engineSys (Engine 100 1 Mark I)

-- etc.


And so, with each individual component being wrapped as a generic
ShipSys (ship system), I can make a complete system simply by composition:

code:

h :t mk1Engine
mk1Engine :: ShipSys
h :t stdRearThruster
stdRearThruster :: ShipSys
h :t stdFrontThruster
stdFrontThruster :: ShipSys
h :t stdRotThruster
stdRotThruster :: Power - ShipSys
h mk1Engine  stdRearThruster  stdFrontThruster  stdRotThruster 10
Socket3 (Last {getLast = Just (Engine 100.0 1.0 Mark I)}) (Last
{getLast = Just (RotThruster 10.0)}) [LinThruster 3.1415927
1.0,LinThruster 0.0 0.5]


This seems to work well enough so far. But the issue I was concerned
about is: if I can't layer record syntax onto the type synonym, then I
have to rewrite a whole bunch of getters / setters each time I want to
add an attribute (e.g., requiring a switch from a Socket3 to a Socket4.)
If this is the case, then perhaps it would be better just to define the
ShipSys type directly, and directly instance it into the monoid abstraction.

-- 
frigidcode.com



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


Re: [Haskell-cafe] category design approach for inconvenient concepts

2012-12-21 Thread wren ng thornton

On 12/21/12 3:27 AM, Oleksandr Manzyuk wrote:

On Fri, Dec 21, 2012 at 4:40 AM, Alexander Solla alex.so...@gmail.com wrote:

I don't see how associativity fails, if we mod out alpha-equivalence.  Can
you give an example?  (If it involves the value undefined, I'll have
something concrete to add vis a vis moral equivalence)


If you compute (f . g) . h, you'll get \x - (f . g) (h x) = \x - (\x
- f (g x)) (h x), whereas f . (g . h) produces \x - f ((g . h) x) =
\x - f ((\x - g (h x)) x).  As raw lambda-terms, these are distinct.
  They are equal if you allow beta-reduction in bodies of abstractions.
  That's what I meant when I said that we probably wanted to consider
equivalence classes modulo some equivalence relation.  That
hypothetical relation should obviously preserve beta-reduction in the
sense (\x - e) e' = [e'/x]e.


Surely if we have any interest in the semantics of Haskell, we should be 
considering things modulo the usual relations. Of course, this takes us 
directly to the question of what semantics we're actually trying to capture?


Considering terms modulo alpha is obvious. N.B., alpha just refers to 
locally bound variables, not to definitions. We can define multiple 
copies of the same type with different names for the data and type 
constructors, and Haskell will hold these things distinct. If they truly 
are the same then they'll be isomorphic in the category, which is 
something we deal with all the time.


Considering things modulo delta is also pretty obvious. That is, 
inlining (or outlining) of definitions shouldn't have any semantic 
effect. If it does, then referential transparency fails, and that's one 
of the things we've sworn to uphold.


When we turn to beta (and iota, sigma,...), things start getting 
complicated. On the one hand, we'd like to include beta since it's 
standard in PL semantics. Moreover, since GHC does a certain amount of 
beta at compile time, we sorta can't get away from including it--- if we 
want to believe that (modulo bugs) GHC is semantics preserving. However, 
on the other hand, that means we can't have our semantics say too much 
about the operational differences between Haskell terms. Again, this is 
standard in denotational semantics; but there are reasons to be 
interested in operational semantics as well...


Turning thence to eta, I'm not sure how things stand. It's known that 
eta breaks certain nice properties about type inference/checking, 
especially once you're in the land of full dependent types, but I don't 
recall whether there are any *semantic* issues to be worried about. 
Haskell98 isn't subject to the issues dependent types have, but modern 
GHC is perilously close. E.g., older implementations of GADTs did 
occasionally require outlining in order to provide the necessary type 
signatures, but that's been fixed IIRC. In any case, we do certainly 
need to be careful about the phrasing of eta, since seq can distinguish 
f from (\x - f x) if f happens to be bottom. So we don't get full eta, 
but how much of it can we salvage? Does it matter for the categorical 
treatment?


--
Live well,
~wren

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


Re: [Haskell-cafe] Categories (cont.)

2012-12-21 Thread wren ng thornton

On 12/20/12 7:07 PM, Christopher Howard wrote:

On 12/20/2012 03:59 AM, wren ng thornton wrote:

In order to fake this theory in Haskell we can do:

 newtype MonoidCategory a i j = MC a

 instance Monoid a = Category (MonoidCategory a) where
 id  = MC mempty
 MC f . MC g = MC (f `mappend` g)

This is a fake because technically (MonoidCategory A X Y) is a different
type than (MonoidCategory A P Q), but since the indices are phantom
types, we (the programmers) know they're isomorphic. From the category
theory side of things, we have K*K many copies of the monoid where K is
the cardinality of the kind *. We can capture this isomorphism if we
like:

 castMC :: MonoidCategory a i j - MonoidCategory a k l
 castMC (MC a) = MC a

but Haskell won't automatically insert this coercion for us; we gotta do
it manually. In more recent versions of GHC we can use data kinds in
order to declare a kind like:

 MonoidCategory :: * - () - () - *

which would then ensure that we can only talk about (MonoidCategory a ()
()). Unfortunately, this would mean we can't use the Control.Category
type class, since this kind is more restrictive than (* - * - * - *).
But perhaps in the future that can be fixed by using kind polymorphism...


Finally... I actually made some measurable progress, using these
phantom types you mentioned:


Yep, everything should work fine with the phantom types. The only 
problem is, as I mentioned, that you're not really getting the category 
associated with the underlying monoid, you're getting a whole bunch of 
copies of that monoid (one copy for each instantiation of the phantom 
types).


--
Live well,
~wren

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


Re: [Haskell-cafe] Categories (cont.)

2012-12-21 Thread wren ng thornton

On 12/21/12 2:35 PM, Chris Smith wrote:

It would definitely be nice to be able to work with a partial Category
class, where for example the objects could be constrained to belong to a
class.  One could then restrict a Category to a type level representation
of the natural numbers or any other desired set.  Kind polymorphism should
make this easy to define, but I still don't have a good feel for whether it
is worth the complexity.


Actually, what you really want is ConstraintKinds. The following works 
just fine in GHC 7.6.1:


{-# LANGUAGE KindSignatures
   , ConstraintKinds
   , PolyKinds
   , TypeFamilies
   , MultiParamTypeClasses
   , FunctionalDependencies
   , FlexibleInstances
   , FlexibleContexts
   #-}

class Category (c :: k - k - *) where

-- | The kind of domain objects.
type DomC c x :: Constraint

-- | The kind of codomain objects.
type CodC c x :: Constraint

-- | The identity morphisms.
id  :: (ObjC c x) = c x x

-- | Composition of morphisms.
(.) :: (DomC c x, ObjC c y, CodC c z) = c y z - c x y - c x z

-- | An alias for objects in the centre of a category.
type ObjC c x = (Category c, DomC c x, CodC c x)

-- | An alias for a pair of objects which could be connected by a
-- @c@-morphism.
type HomC c x y = (Category c, DomC c x, CodC c y)

Notably, we distinguish domain objects from codomain objects in order to 
allow morphisms into or out of the category, which is indeed helpful 
in practice.


Whether there's actually any good reason for distinguishing DomC and 
CodC, per se, remains to be seen. In Conal Elliott's variation[1] he 
moves HomC into the class and gets rid of DomC and CodC. Which allows 
constraints that operate jointly on both the domain and codomain, 
whereas the above version does not. I haven't run into the need for that 
yet, but I could easily imagine it. It does add a bit of complication 
though since we can no longer have ObjC be a derived thing; it'd have to 
move into the class as well, and we'd have to somehow ensure that it's 
coherent with HomC.


The above version uses PolyKinds as well as ConstraintKinds. I haven't 
needed this myself, since the constraints act as a sort of kind for the 
types I'm interested in, but it'll definitely be useful if you get into 
data kinds, or want an instance of functor categories, etc.



[1] 
https://github.com/conal/linear-map-gadt/blob/master/src/Control/ConstraintKinds/Category.hs


--
Live well,
~wren

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


Re: [Haskell-cafe] Substituting values

2012-12-21 Thread Kim-Ee Yeoh
This is reminiscent of the Either (exception) monad where Left values, the
exceptions, pass through unaltered, and Right values are transformable,
i.e. acted on by functions.

But I have no idea what you're trying to achieve in the bigger picture.
Help us help you by fleshing out your use case.

-- Kim-Ee


On Sat, Dec 22, 2012 at 12:46 AM, Radical radi...@google.com wrote:

 Sometimes I'll need something like:

   if value == Foo then Bar else value

 Or some syntactic variation thereof:

   case value of { Foo - Bar; _ - value }

 Is there a better/shorter way to do it? I'm surprised that it's more
 complicated to substitute a value on its own than e.g. in a list, using
 filter. Or perhaps I'm missing the right abstraction?

 Thanks,

 Alvaro




 ___
 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] Troubles with DLLs

2012-12-21 Thread Henk-Jan van Tuyl

On Fri, 21 Dec 2012 21:08:43 +0100, Henk-Jan van Tuyl hjgt...@chello.nl
wrote:

1) How can I find out which DLLs my application needs (and which  
package/library is to blame for it)


I have found a partial answer: cygcheck from Cygwin can list dependencies
on DLLs recursively, like this:


cygcheck.exe .\BouncingBalls.exe

.\BouncingBalls.exe
C:\WINDOWS\system32\KERNEL32.DLL
  C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\msvcrt.dll
C:\WINDOWS\system32\SHELL32.DLL
  C:\WINDOWS\system32\ADVAPI32.dll
C:\WINDOWS\system32\RPCRT4.dll
  C:\WINDOWS\system32\Secur32.dll
  C:\WINDOWS\system32\GDI32.dll
C:\WINDOWS\system32\USER32.dll
  C:\WINDOWS\system32\SHLWAPI.dll
C:\WINDOWS\system32\WSOCK32.DLL
  C:\WINDOWS\system32\WS2_32.dll
C:\WINDOWS\system32\WS2HELP.dll
C:\Haskell\Projects\X\wxc.dll
  C:\Haskell\Projects\X\libstdc++-6.dll
C:\Haskell\Projects\X\libgcc_s_dw2-1.dll
etcetera.


If a DLL is not found, you will get a message like:
Error: could not find wxc.dll

It will not always be apparent, which package is responsible for
the DLL dependency.

I am still left with the question:
how can I find the error location when the crash occurs in C/C++ code?

Regards,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

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