Re: [Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
Hi Niklas, > Apart from this, HSE now also parses any unrecognized pragma in option > (e.g. LANGUAGE), declaration (e.g. RULES) or expression (e.g. SCC) > position, allowing user-customized pragmas. Unrecognized pragmas in > other positions will (unfortunately) give a parse error. If this ever > means a problem for you - let me know! This is likely to be a problem for me :-) I certainly have OPTIONS_DERIVE and CATCH pragmas that I've inserted into various programs over time. I think failing on an unrecognised pragma is probably a bad idea, when ignoring a pragma is usually perfectly safe. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why does "instance Ord Pat" causes <>
I am storing the TH data types 'Exp' and 'Pat' in Maps and Sets. As a
first attempt to quickly get rid of typechecker's complaints I defined
some naive instances of Ord for Exp and Pat.
Now it took me about a week to realise, that 'instance Ord Pat' causes
ghc to loop. Apparently, there is a reason, why Pat and Exp are not
instances of Ord. What is so bad about it?
If Pat and Exp should not be instances of Ord, maybe a note in the
source code or haddock would be helpful. On the other hand, what would
argue against a lexicographic ordering (apart from the inefficient
implementation of the following one)?
Following some literate code to reproduce the <> (or stack
overflow in GHCi), by commenting and uncommenting the appropriate lines:
> {-# OPTIONS_GHC -fglasgow-exts -fth #-}
> module Test where
> import Language.Haskell.TH
> import Data.Set
---
naive Ord
> instance Ord Exp
> instance Ord Pat
---
lexicographic Ord
instance Ord Exp where
compare l r = compare (show l) (show r)
instance Ord Pat where
compare l r = compare (show l) (show r)
---
> mkVP s = VarP $ mkName s
> mkVE s = VarE $ mkName s
> rule1 = (,) [mkVP "x_14"] (mkVE "y_14")
> rule2 = (,) [InfixP (mkVP "x1_15") '(:) (mkVP "x_16")] (InfixE (Just (mkVE
> "y1_15")) (ConE '(:)) (Just (mkVE "ys_16")))
> stack_overflow = fromList [rule1,rule2]
Thanks,
Martin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does "instance Ord Pat" causes <>
On Mon, Dec 8, 2008 at 2:04 AM, Martin Hofmann <
[EMAIL PROTECTED]> wrote:
> I am storing the TH data types 'Exp' and 'Pat' in Maps and Sets. As a
> first attempt to quickly get rid of typechecker's complaints I defined
> some naive instances of Ord for Exp and Pat.
>
> Now it took me about a week to realise, that 'instance Ord Pat' causes
> ghc to loop. Apparently, there is a reason, why Pat and Exp are not
> instances of Ord. What is so bad about it?
>
> If Pat and Exp should not be instances of Ord, maybe a note in the
> source code or haddock would be helpful. On the other hand, what would
> argue against a lexicographic ordering (apart from the inefficient
> implementation of the following one)?
>
> Following some literate code to reproduce the <> (or stack
> overflow in GHCi), by commenting and uncommenting the appropriate lines:
Try this:
data Foo = Foo deriving Eq
instance Ord Foo
Then try Foo < Foo.
instance Ord Foo is not the same as "deriving Ord"; it declares an instance
using all default definitions, which are self-referential.
It would be nice if typeclass authors could somehow declare the minimal
complete definition, so we could get a warning in this case.
Luke
>
>
>
>
> > {-# OPTIONS_GHC -fglasgow-exts -fth #-}
> > module Test where
> > import Language.Haskell.TH
> > import Data.Set
>
>
> ---
> naive Ord
>
> > instance Ord Exp
>
> > instance Ord Pat
>
> ---
> lexicographic Ord
>
> instance Ord Exp where
> compare l r = compare (show l) (show r)
>
> instance Ord Pat where
> compare l r = compare (show l) (show r)
>
> ---
>
>
> > mkVP s = VarP $ mkName s
> > mkVE s = VarE $ mkName s
> > rule1 = (,) [mkVP "x_14"] (mkVE "y_14")
> > rule2 = (,) [InfixP (mkVP "x1_15") '(:) (mkVP "x_16")] (InfixE (Just
> (mkVE "y1_15")) (ConE '(:)) (Just (mkVE "ys_16")))
>
> > stack_overflow = fromList [rule1,rule2]
>
>
> Thanks,
>
> Martin
>
>
> ___
> 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] Why does "instance Ord Pat" causes <>
On Mon, Dec 8, 2008 at 2:04 AM, Martin Hofmann <
[EMAIL PROTECTED]> wrote:
> I am storing the TH data types 'Exp' and 'Pat' in Maps and Sets. As a
> first attempt to quickly get rid of typechecker's complaints I defined
> some naive instances of Ord for Exp and Pat.
>
> Now it took me about a week to realise, that 'instance Ord Pat' causes
> ghc to loop. Apparently, there is a reason, why Pat and Exp are not
> instances of Ord. What is so bad about it?
Oh, to answer this, my guess is that such an instance is just kind of
silly. It is a meaningless, arbitrary ordering, and is brittle to
splitting/combining cases.
To put them in sets and maps, go ahead an define an arbitrary ordering
however you can, but wrap it in a newtype like this:
newtype OrdExp = OrdExp Exp
instance Ord OrdExp where
compare (OrdExp a) (OrdExp b) = compare (show a) (show b)
An orphan instance is one which is defined in a module where neither the
class nor the type being instantiated is defined. This newtype wrapping
avoids orphan instances, and associates the arbitrary ordering to your own
wrapper so if somebody else defined a different arbitrary ordering, they
won't conflict.
Orphan instances (almost?) always indicate a nonmodular design decision.
Luke
>
>
> If Pat and Exp should not be instances of Ord, maybe a note in the
> source code or haddock would be helpful. On the other hand, what would
> argue against a lexicographic ordering (apart from the inefficient
> implementation of the following one)?
>
> Following some literate code to reproduce the <> (or stack
> overflow in GHCi), by commenting and uncommenting the appropriate lines:
>
>
>
> > {-# OPTIONS_GHC -fglasgow-exts -fth #-}
> > module Test where
> > import Language.Haskell.TH
> > import Data.Set
>
>
> ---
> naive Ord
>
> > instance Ord Exp
>
> > instance Ord Pat
>
> ---
> lexicographic Ord
>
> instance Ord Exp where
> compare l r = compare (show l) (show r)
>
> instance Ord Pat where
> compare l r = compare (show l) (show r)
>
> ---
>
>
> > mkVP s = VarP $ mkName s
> > mkVE s = VarE $ mkName s
> > rule1 = (,) [mkVP "x_14"] (mkVE "y_14")
> > rule2 = (,) [InfixP (mkVP "x1_15") '(:) (mkVP "x_16")] (InfixE (Just
> (mkVE "y1_15")) (ConE '(:)) (Just (mkVE "ys_16")))
>
> > stack_overflow = fromList [rule1,rule2]
>
>
> Thanks,
>
> Martin
>
>
> ___
> 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] Why does "instance Ord Pat" causes <>
Hello Martin, Monday, December 8, 2008, 12:04:06 PM, you wrote: > Now it took me about a week to realise, that 'instance Ord Pat' causes > ghc to loop. > naive Ord > >> instance Ord Exp >> instance Ord Pat i think you just don't learned this part of Haskell. empty instance declarations like these are possible but they doesn't mean automatic definition of some suitable compare. they just bring in some default definitions which may be mutual recursive, such as (==) and (/=) definitions in Eq class. this is intended to that your define either (==) or (/=), but compiler doesn't check this, so if you don't define anything, you will get endless loop if you want compiler to infer automatic instance definitions, the only way is to use GHC extension, smth like deriving instance Ord for Pat -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does "instance Ord Pat" causes <>
Thanks a lot for the quick replies. Indeed that was not clear to me. Cheers, Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pragmas (was: ANNOUNCE: haskell-src-exts 0.4.4)
* Neil Mitchell <[EMAIL PROTECTED]> [2008-12-08 08:29:03+] > > Apart from this, HSE now also parses any unrecognized pragma in option > > (e.g. LANGUAGE), declaration (e.g. RULES) or expression (e.g. SCC) > > position, allowing user-customized pragmas. Unrecognized pragmas in > > other positions will (unfortunately) give a parse error. If this ever > > means a problem for you - let me know! > > This is likely to be a problem for me :-) > > I certainly have OPTIONS_DERIVE and CATCH pragmas that I've inserted > into various programs over time. I think failing on an unrecognised > pragma is probably a bad idea, when ignoring a pragma is usually > perfectly safe. Even more, An implementation is not required to respect any pragma, but the pragma should be ignored if an implementation is not prepared to handle it.[1] Related question: why does not Language.Haskell.Syntax[2] (from haskell-src) represent comments or pragmas in any way? 1. http://www.haskell.org/onlinereport/pragmas.html 2. http://www.haskell.org/ghc/docs/latest/html/libraries/haskell-src/Language-Haskell-Syntax.html -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Deriving something else?
Hi,
I've defined a class and some instances, which I'm hoping would help me
"show" values of types that may include transactional elements.
class TShow a where
tshow :: a -> IO String
instance Show (TVar a) where
show = "%"
instance (Show a) => TShow a where
tshow a = return $ show a
instance (Show a) => TShow (TVar a) where
tshow ta = do
a <- readTVar ta
return $ show a
Having created a new class is it possible to do some magic so that it can be
put it into a deriving clause?
data Type = Type
{ field1 :: Int
, field2 :: Int
}
deriving Show
data AnotherType = AnotherType
{ field3 :: Int
, field4 :: TVar Type
}
deriving *TShow*
Thanks
-John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Overlapping instances
The problem is that Engine *could* be made an instance of Show (remember
that any user of the module can create that instance later).
What you need is the overlappinginstances extension:
{-# LANGUAGE OverlappingInstances #-}
With this extension, the most specific instance will be used, i.e.
"instance TShow Engine" for Enginge's, no matter if it is an instance of
Show.
/Tobias
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Ky
Sent: den 8 december 2008 13:32
To: Haskell Cafe
Subject: [Haskell-cafe] Overlapping instances
Hi,
I've got the following code which tries to implement a TShow class,
which is equivalent to Show, except it is supposed to work on TVar types
as well.
import GHC.Conc
createEngine :: String -> Int -> Int -> IO Engine
createEngine name major minor = do
tUsers <- newTVarIO []
return $ Engine
{ engineName = name
, version = EngineVersion
{ major = major
, minor = minor
}
, users = tUsers
}
class TShow a where
tshow :: a -> IO String
instance Show (TVar a) where
show a = "%"
instance (Show a) => TShow a where
tshow a = return $ show a
instance (Show a) => TShow (TVar a) where
tshow ta = do
a <- atomically (readTVar ta)
return $ show a
data User = User
{ userName :: String
}
deriving Show
data EngineVersion = EngineVersion
{ major :: Int
, minor :: Int
}
deriving Show
data Engine = Engine
{ engineName :: String
, version :: EngineVersion
, users :: TVar [User]
}
instance TShow Engine where
tshow a = do
users <- atomically (readTVar (users a))
return $
"Engine { " ++
"engineName = " ++ show (engineName a) ++ ", " ++
"version = " ++ show (version a) ++ ", " ++
"users = %" ++ show users ++ " }"
When I run it however, I get this:
*Main> te <- createEngine "Hello" 1 2
*Main> s <- tshow te
:1:5:
Overlapping instances for TShow Engine
arising from a use of `tshow' at :1:5-12
Matching instances:
instance (Show a) => TShow a -- Defined at
fxmain.hs:(26,0)-(27,27)
instance TShow Engine -- Defined at fxmain.hs:(51,0)-(58,41)
In a stmt of a 'do' expression: s <- tshow te
I'm not seeing how instance (Show a) => TShow a in the above error
message is applicable here since Engine is not an instance of Show. Why
is it complaining?
Thanks,
-John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Overlapping instances
Hi,
I've got the following code which tries to implement a TShow class, which is
equivalent to Show, except it is supposed to work on TVar types as well.
import GHC.Conc
createEngine :: String -> Int -> Int -> IO Engine
createEngine name major minor = do
tUsers <- newTVarIO []
return $ Engine
{ engineName = name
, version = EngineVersion
{ major = major
, minor = minor
}
, users = tUsers
}
class TShow a where
tshow :: a -> IO String
instance Show (TVar a) where
show a = "%"
instance (Show a) => TShow a where
tshow a = return $ show a
instance (Show a) => TShow (TVar a) where
tshow ta = do
a <- atomically (readTVar ta)
return $ show a
data User = User
{ userName :: String
}
deriving Show
data EngineVersion = EngineVersion
{ major :: Int
, minor :: Int
}
deriving Show
data Engine = Engine
{ engineName :: String
, version :: EngineVersion
, users :: TVar [User]
}
instance TShow Engine where
tshow a = do
users <- atomically (readTVar (users a))
return $
"Engine { " ++
"engineName = " ++ show (engineName a) ++ ", " ++
"version = " ++ show (version a) ++ ", " ++
"users = %" ++ show users ++ " }"
When I run it however, I get this:
*Main> te <- createEngine "Hello" 1 2
*Main> s <- tshow te
:1:5:
Overlapping instances for TShow Engine
arising from a use of `tshow' at :1:5-12
Matching instances:
instance (Show a) => TShow a -- Defined at fxmain.hs:(26,0)-(27,27)
instance TShow Engine -- Defined at fxmain.hs:(51,0)-(58,41)
In a stmt of a 'do' expression: s <- tshow te
I'm not seeing how instance (Show a) => TShow a in the above error message
is applicable here since Engine is not an instance of Show. Why is it
complaining?
Thanks,
-John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Animated line art
On 06/12/2008, at 6:32 AM, Andrew Coppin wrote: Tim Docker wrote: If you implement your drawing logic as a function from time to the appropriate render actions, ie | import qualified Graphics.Rendering.Cairo as C | | type Animation = Time -> C.Render () then you just need to call this function multiple times to generate sucessive frames. That was my initial idea... but I'm not sure how well it would work. I want to do stuff like fade elements in and out, move complex structures around on the screen, etc. I think it might end up being a little tangled if I go with this approach. I might be wrong though... This model of animation as "a function of time to a picture" is probably described in many places. I first saw it described in Paul Hudaks book "The haskell School of Expression: Learning functional programming through multimedia". It shows how primitive animations can be combined in various ways, including overlays and time transformations. You can download the code from the books web-site, which might be of interest even if you can't get hold of a copy of the book. It's intended for pedagogical purposes, rather than a comprehensive animation system, of course. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Deriving something else?
John Ky wrote: Having created a new class is it possible to do some magic so that it can be put it into a deriving clause? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/derive -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Problem with System.Random.randoms
Hi, I have a small problem with System.Random.randoms. I need a rather large number of random numbers but the following program consumes a huge amount of memory. I terminated it when it used up more than 2 Gb: Interesting. Well, if you don't solve this problem, I recently needed random numbers and it was very clean to use State and StateT to get them updated. Depending on your problem, this may be easier than using a list. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal: defaultMainNoRead and source file location
Hi, I've just seen this from Distribution.ModuleName (ghc 6.10): toFilePath $ ( simple "A.B.C" ) to which ghci answers: "A.B.C". Shouldn't it say "A/B/C"? The reason why I'm asking is that I've just created a Setup.hs with 'defaultMainNoRead', and 'Setup build' complains it can't find A.B.C. When I copy (move doesn't work) C.hs from /A/B to /A.B.C.hs, it doesn't complain, although it fails to generate my library saying: [1 of 1] Compiling A.B.C ( src/A/B/C.hs, dist/build/A/B/C.o) /usr/bin/ar: creating dist/build/libHSabc-0.a /usr/bin/ar: dist/build/A.B.C.o: No such file or directory Thanks for your tips, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Dr Dobbs: Time to get good at functional programming
> http://www.ddj.com/development-tools/212201710;jsessionid=3MQLTTYJRPL3CQSNDLRSKH0CJUNN2JVN Do they purposefully obfuscate names? I mean who are those "Martin Obersky" and "Don Sype"? Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Origins of '$'
Don Stewart wrote: Which suggests that $ was already in the 1.0 report going to SIGPLAN. Perhaps Paul or Simon could shed light on it? Anyone have the 1.0 report lying around to check if it was in earlier? As far as Haskell is concerned, the first "report"-ed occurrence of the $ operator was in the Haskell 1.2 report dated March 1992. I don't see any mention of the $ operator in either the 1.0 or the 1.1 reports (April 1990 and August 1991, respectively). The 1.0 report did define the following operator, which is a variant of $: let :: a -> (a -> b) -> b let x k = k x This was exported from the prelude, but its definition actually appeared in the PreludeIO section of the report, hinting at the main motivation for its introduction in support of continuation based I/O. (Monadic I/O didn't officially arrive until the 1.3 report in May 1996.) But the "let" operator was quickly promoted to a keyword in Haskell 1.1 with the introduction of let expressions, replacing the "where expressions" that Haskell 1.0 had provided for local definitions. With the move to 1.1, "where" became part of the syntax for definition right hand sides, able to scope across multiple guards and no longer part of the expression syntax. A little history can sometimes be fun. All the best, Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Origins of '$'
On Mon, 2008-12-08 at 09:58 -0800, Mark P. Jones wrote: > Don Stewart wrote: > > Which suggests that $ was already in the 1.0 report going to SIGPLAN. > > Perhaps Paul or Simon could shed light on it? Anyone have the 1.0 report > > lying around to check if it was in earlier? > > As far as Haskell is concerned, the first "report"-ed occurrence > of the $ operator was in the Haskell 1.2 report dated March 1992. > I don't see any mention of the $ operator in either the 1.0 or > the 1.1 reports (April 1990 and August 1991, respectively). > > The 1.0 report did define the following operator, which is a > variant of $: > >let :: a -> (a -> b) -> b >let x k = k x > > This was exported from the prelude, but its definition actually > appeared in the PreludeIO section of the report, hinting at the > main motivation for its introduction in support of continuation > based I/O. (Monadic I/O didn't officially arrive until the 1.3 > report in May 1996.) Not officially, but `let' as above is in fact the unit of the Cont monad. And (>>>) from the PreludeIO section of the same report is the (>>=) for the Cont monad. So monadic I/O was there, it just seems that no-one noticed (or I haven't seen this explicitly pointed out)... jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to define Show [MyType] ?
On Sun, Dec 7, 2008 at 1:51 AM, Fraser Wilson <[EMAIL PROTECTED]> wrote:
> (I know you know this, I just have this weird fascination with the showList
> wart, although for the life of me I can't think of a better way of doing it)
Well, if you extend the compiler's core language with "typecase", you
can solve a lot of these problems. Then the implementation of
typeclasses changes from "dictionary-passing" to "type-passing", and
overlapping instances can be resolved by dynamic dispatch.
For example, the following program:
class C a where view :: a -> String
instance C Char where view x = viewChar x -- primitive
instance C String where view x = viewString x -- primitive
instance C a => C [a] where
view [] = "[]"
view (x:xs) = concat $
[ "[", view x ] ++ concatMap (\y -> [ ", ", view y ]) xs ++ [ "]" ]
would compile to this "core":
view :: Type a -> a -> String
view t = typecase t of
Char -> viewInstanceChar
[t'] -> typecase t' of
Char -> viewInstanceString
_ -> viewInstanceList t'
_ -> error ("no instance for View " ++ show t)
viewInstanceChar x = viewChar x
viewInstanceString x = viewString x
viewInstanceList t x = concat $
[ "[", view t x ] ++ concatMap (\y -> [ ", ", view t y ]) xs ++ [ "]" ]
I think at least one Haskell compiler implements typeclasses this way.
One nice property of this solution is that you retain parametricity,
at least unless you also include "typeof"; any function with a
typeclass constraint takes an additional type argument. Passing
"Type a" around in this way is like using Typeable in current Haskell
except it would have to be supported at the compiler level.
And of course all of the standard optimizations apply, so if you
statically know that the type is [Char] you inline "view" and get the
correct answer. If you statically know that the type is [x] but you
don't know x, you can still specialize the case down to just the
typecase on the inside of the list.
The biggest wart is that "view" is not a total function; the compiler
needs to be extra careful to only call it on types that are instances
of "View". I wonder if there is a good way to solve this problem?
-- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Overlapping instances
On Mon, Dec 8, 2008 at 4:43 AM, Tobias Bexelius
<[EMAIL PROTECTED]> wrote:
> {-# LANGUAGE OverlappingInstances #-}
>
> With this extension, the most specific instance will be used, i.e.
> "instance TShow Engine" for Engine's, no matter if it is an instance of
> Show.
Of course, down this way madness lies :)
For example, this code:
> uhoh :: Show a => a -> IO String
> uhoh x = tshow x
won't compile. The question is, what should this code do?
> instance Show (TVar a) where show _ = "TVAR"
> broken :: TVar a -> String
> broken x = uhoh x
"broken" will construct the Show dictionary for TVars and pass it to
"uhoh", which no longer knows that it is getting called on a TVar.
Then uhoh will construct a TShow (TVar a) dictionary using the Show
(TVar a) dictionary and the instance "Show a => TShow a", even though
there is a more specific instance.
So the compiler will just not let "uhoh" compile if overlapping is allowed.
You can force it to compile using the wrong instance with the
"IncoherentInstances" extension, but it's aptly named; the result is
bad because each type is supposed to only have one instance for a
particular typeclass. It's worse because it breaks referential
transparency; if you inline "uhoh" into "broken", now you get the
specific instance!
-- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Origins of '$'
On Sun, Dec 7, 2008 at 2:05 AM, Hans Aberg <[EMAIL PROTECTED]> wrote: > As for the operator itself, it appears in Alonzo Church, "The Calculi of > Lambda-Conversion", where it is written as exponentiation, like x^f That's reminiscent of the notation in Lambek and Scott where (roughly speaking) the function converting an element of an object A^B to an arrow B->A (something Haskellers don't normally have to think about) is written as a superscript integral sign. Presumably this comes from the same source. Both $ and the integral sign are forms of the letter 's'. Don't know why 's' would be chosen though. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Origins of '$'
On 8 Dec 2008, at 19:36, Dan Piponi wrote: On Sun, Dec 7, 2008 at 2:05 AM, Hans Aberg <[EMAIL PROTECTED]> wrote: As for the operator itself, it appears in Alonzo Church, "The Calculi of Lambda-Conversion", where it is written as exponentiation, like x^f That's reminiscent of the notation in Lambek and Scott where (roughly speaking) the function converting an element of an object A^B to an arrow B->A (something Haskellers don't normally have to think about) is written as a superscript integral sign. Presumably this comes from the same source. Both $ and the integral sign are forms of the letter 's'. Don't know why 's' would be chosen though. In set theory, and sometimes in category theory, A^B is just another notation for Hom(B, A), and the latter might be given the alternate notation B -> A. And th reason is that for finite sets, computing cardinalities result in the usual power function of natural numbers - same as Church, then. And the integral sign comes from Leibnitz: a stylized "S" standing for summation. Also, it is common to let "s" or sigma stand for a section, that is, if given functions s: A -> B pi: B -> A such that the composition pi o s: A -> B -> A is the identity on A, then s is called a section and pi a projection (as in differential geometry). Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Cabal: defaultMainNoRead and source file location
> (...) The reason why I'm asking is that I've just created a
> Setup.hs with 'defaultMainNoRead', and 'Setup build' complains
> it can't find A.B.C. When I copy (move doesn't work) C.hs from
> /A/B to /A.B.C.hs, it doesn't complain,
> although it fails to generate my library saying:
I'm changing to normal defaultMain, but just in case someone wants
to check the problem I'm appending a 'darcs whatsnew' over an
empty repo.
Is this the right place to report that? Does Distribution.Simple
or cabal have a bug tracking of its own?
Best,
Maurício
addfile ./Setup.hs
hunk ./Setup.hs 1
+#!/usr/bin/env runhaskell
+
+module Main (main) where { import Distribution.Simple ; import
+Distribution.PackageDescription ; import Distribution.ModuleName
+hiding ( main ) ; import Distribution.PackageDescription.Check ;
+
+ main = defaultMainNoRead pkg ;
+
+ pkg :: PackageDescription ;
+
+ oneLineSynopsis =
+ "bla ble bli" ;
+
+ longDescription = "\
+ \blabla bleble blibli\
+ \" ;
+
+ modules = map simple [ "A.B.C" ] ;
+
+ pkg = emptyPackageDescription {
+ package = PackageIdentifier {
+ pkgName = PackageName "abc" ,
+ pkgVersion = Version {
+versionBranch = [0] ,
+versionTags = [ "" ]
+ }
+ } ,
+ license = PublicDomain ,
+ maintainer = "Me" ,
+ author = "Me" ,
+ synopsis = oneLineSynopsis ,
+ description = longDescription ,
+ category = "any" ,
+ buildDepends = [ Dependency ( PackageName "base" ) AnyVersion ] ,
+ descCabalVersion = orLaterVersion $ Version {
+versionBranch = [ 1 , 2 ] ,
+versionTags = [ "" ]
+ } ,
+ buildType = Just Custom ,
+ library = Just ( Library {
+ exposedModules = modules ,
+ libExposed = True ,
+ libBuildInfo = emptyBuildInfo {
+hsSourceDirs = [ "./src" ] ,
+extensions = [ ]
+ }
+ } )
+ }
+
+}
adddir ./src
adddir ./src/A
addfile ./src/A.B.C.hs
hunk ./src/A.B.C.hs 1
+module A.B.C where {
+
+ a = "asdf" ;
+
+ b = "qwer" ;
+
+ c = "zxcv"
+
+}
adddir ./src/A/B
addfile ./src/A/B/C.hs
hunk ./src/A/B/C.hs 1
+module A.B.C where {
+
+ a = "asdf" ;
+
+ b = "qwer" ;
+
+ c = "zxcv"
+
+}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Origins of '$'
> > >> In set theory, and sometimes in category theory, A^B is just another > notation for Hom(B, A), and the latter might be given the alternate notation > B -> A. And th reason is that for finite sets, computing cardinalities > result in the usual power function of natural numbers - same as Church, > then. > > Hans Slightly off topic, but the A^B notation for hom-sets also makes the natural isomorphism we call currying expressable as A^(BxC) = (A^B)^C. Nathan Bloomfield ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Origins of '$'
Hi, Am Montag, den 08.12.2008, 15:59 -0600 schrieb Nathan Bloomfield: > Slightly off topic, but the A^B notation for hom-sets also makes the > natural isomorphism we call currying expressable as A^(BxC) = (A^B)^C. So A^(B+C) = A^B × A^C ? Oh, right, I guess that’s actually true: uncurry either:: (a -> c, b -> c) -> (Either a b -> c) (\f -> (f . Left, f . Right)) :: (Either a b -> c) -> (a -> c, b -> c) It’s always nice to see that I havn’t learned the elementary power calculation rules for nothing :-) Greetings, Joachim PS: For those who prefer Control.Arrow to points: (.Left) &&& (.Right) :: (Either a b -> c) -> (a -> c, b -> c) (found by trial and error :-)) -- Joachim "nomeata" Breitner mail: [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Key: 4743206C JID: [EMAIL PROTECTED] | http://www.joachim-breitner.de/ Debian Developer: [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Dr Dobbs: Time to get good at functional programming
That "article" is an incredibly half-assed job. It reads like a high-school essay, thrown together in a hurry before a 1 hour deadline. Maybe it's a good sign that people think they have to do this, but it really doesn't help anyone who wants to know why FP might be worth learing. 2008/12/8 Stefan Monnier <[EMAIL PROTECTED]>: >> http://www.ddj.com/development-tools/212201710;jsessionid=3MQLTTYJRPL3CQSNDLRSKH0CJUNN2JVN > > Do they purposefully obfuscate names? > I mean who are those "Martin Obersky" and "Don Sype"? > > >Stefan > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Dr Dobbs: Time to get good at functional programming
It's just there so you can show your boss it was in Dr. Dobbs, and so your boss can think "Wow, I know what FP is -- thank you, Dr. Dobbs!". For this purpose, the only thing better is if we could somehow get them to mention Microsoft everywhere they mention Haskell. Any actual explaining would just get in the way :) -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Origins of '$'
2008/12/8 Joachim Breitner <[EMAIL PROTECTED]>: > So A^(B+C) = A^B × A^C ? That's part of the basis for Hinze's paper on memoization: http://www.informatik.uni-bonn.de/~ralf/publications/WGP00b.ps.gz > It's always nice to see that I havn't learned the elementary power > calculation rules for nothing :-) More generally, all of Tarski's "high school algebra" axioms carry over to types. You can see the axioms here: http://math.bu.edu/people/kayeats/papers/saga_paper4.ps That proves type theory is child's play :-) -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building "plugins" from Hackage
solistic: > Hello List, > when I try to install the package "plugins" with cabal i get the following > error. > > cabal: dependencies conflict: ghc-6.8.3 requires Cabal ==1.2.4.0 however > Cabal-1.2.4.0 was excluded because plugins-1.3.1 requires Cabal ==1.4.* > > Is there a way to resolve this? Any ideas? > Rebuild Cabal 1.4, then build plugins. Cheers, Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Dr Dobbs: Time to get good at functionalprogramming
For this purpose, the only thing better is if we could somehow get them to mention Microsoft everywhere they mention Haskell. Any actual explaining would just get in the way :) Doesn't quite work without explaining, because one would have to be very careful not to mis-represent financial support by some as endorsement by the whole; but if one were to ask those who have contributed financially to Haskell development in some form or other for their permissions, one could make quite an interesting little list (not to mention the vastly larger list of people who have contributed their time, efforts, and ideas). There have been occasional discussions of language-specific or FP-in-general industry consortiums. Perhaps the simpler form of "Haskell sponsorship" with mutual bragging rights for haskell.org and sponsor could be a seed corn for such organisations. These days, being associated with FP is no longer something that needs explaining, let alone defending, so sponsors could get something out of their contribution, such as cute little logos, tea-cups and t-shirts (apart from the prime motive of better Haskell;-). Imagine all the students that universities could attract by being a "Haskell campus", not just turning out "Haskell engineers", but "supporting Haskell development" by contributing staff time. Imagine all the competent developers and major customers companies could attract by being a "Haskell sponsor", being actively involved in "Haskell frontline development&research". Imagine all those pretty Haskell logos on all those webpages. oops, wrong universe again;-) Claus PS. Of course, if you do go down that route, your next Haskell job in industry might be representing your company on a committee to decide the internationalization of an XML-based interchange format for unicode lambda characters, with the usual sub-committees for upper-, lower-, and othercase variants, each with at least two spin-off standards representing minority preferences or implementors' we-just-did-it decisions. So be careful what you wish for. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Dr Dobbs: Time to get good at functionalprogramming
claus.reinke: > > For this purpose, the only thing better is if we could somehow > > get them to mention Microsoft everywhere they mention Haskell. > > Any actual explaining would just get in the way :) > > Doesn't quite work without explaining, because one would have > to be very careful not to mis-represent financial support by some > as endorsement by the whole; but if one were to ask those who > have contributed financially to Haskell development in some form > or other for their permissions, one could make quite an interesting > little list (not to mention the vastly larger list of people who have > contributed their time, efforts, and ideas). > > There have been occasional discussions of language-specific or > FP-in-general industry consortiums. Perhaps the simpler form > of "Haskell sponsorship" with mutual bragging rights for haskell.org > and sponsor could be a seed corn for such organisations. These > days, being associated with FP is no longer something that needs > explaining, let alone defending, so sponsors could get something > out of their contribution, such as cute little logos, tea-cups and > t-shirts (apart from the prime motive of better Haskell;-). > > Imagine all the students that universities could attract by being a > "Haskell campus", not just turning out "Haskell engineers", but > "supporting Haskell development" by contributing staff time. > Imagine all the competent developers and major customers > companies could attract by being a "Haskell sponsor", being > actively involved in "Haskell frontline development&research". > Imagine all those pretty Haskell logos on all those webpages. I suggest any industrial group interested in an Industrial Haskell Group please contact Andy Adams-Moran at Galois. Things are in the pipeline, and the more participants the better. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reading showables
2008/12/7 John Ky <[EMAIL PROTECTED]>: > Thanks for the clarification. > > They're all the same, as you've explained: > > Prelude> putStrLn $ (show . read) "123" > *** Exception: Prelude.read: no parse > > Prelude> putStrLn $ show $ read "123" > *** Exception: Prelude.read: no parse > > Prelude> putStrLn $ (\x -> show (read x)) "123" > *** Exception: Prelude.read: no parse Luke explained why the Exception is raised, I'll try to explain why this kind of problem happens in general: First two ways that work: Prelude> putStrLn $ (show :: Int -> String) . read $ "123" 123 Prelude> putStrLn $ show . (read :: String -> Int) $ "123" 123 In these examples we explicitly typed either the polymorphic producer (i.e. read) or the producer (i.e. show) so ghci can unify the type variables and figure out what is the right instance of the type class. Generally this happen wherever the type class member has a type variable only to the right of the type (either foo :: a or foo :: Something ->a). This kind of member is polymorphic on the result so the caller must define what it's expecting. "show . read" is saying to ghc both the result of read will define the type and the argument of show will define the type, which is a (kind of) mutually recursive typing issue. > -John Best regards, Daniel Yokomizo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does "instance Ord Pat" causes <>
Luke Palmer wrote: It would be nice if typeclass authors could somehow declare the minimal complete definition, so we could get a warning in this case. Or the minimal complete definitions. Since there can be more than one covering set. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
