RE: API function to check whether one type fits "in" another
Philip If you develop a function that does what you want, and want to make it part of the GHC API, we'd definitely consider including it. But I don't want to promise to develop something just for you; I'm just too snowed under with other stuff. I really think the "holes" that Thijs is working on might be good for you. He has a prototype already I think. Simon | -Original Message- | From: "Philip K. F. Hölzenspies" [mailto:p...@st-andrews.ac.uk] | Sent: 28 June 2012 11:11 | To: Simon Peyton-Jones | Cc: thijsalkem...@gmail.com; glasgow-haskell-users@haskell.org | Subject: Re: API function to check whether one type fits "in" another | | Dear Simon, et al, | | Thank you very much for your reply. Some of the pointers you gave, I wouldn't | have come across, for not knowing to have to browse through the module Inst, for | example. | | I read the OutsideIn paper (JFP), but that's a fair while back. I was pointed to | Thijs's work in progress at an Agda talk recently. The front-end we're working on | should be portable to any lambda-language with strong types, so the availability | of holes in Agda and Idris makes the implementation for those back-ends a | breeze. | | There is one limiting consideration, however: We want to get this up and running | the next few weeks and we would like to keep things in-sync with the | developments on the different back-ends. This is why I'm trying to stay as close | as possible to the more "public" API parts (the things that are documented and | haven't changed significantly since at least 7.0.4). | | In this light, I was wondering whether it's not worth having a function that does | all this plumbing in the API that is persistent through future versions, much like | pure interface to the parser (GHC.parser). Preferably it would look something like: | | typeCheck | :: DynFlags -- the flags | -> FilePath -- for source locations | -> Type -- expected | -> Type -- actual | -> Either | SomeSortOfErrorStructure | SomeSubstitutionAndOrConstraintTable | | The implementation would have to make sure the pre-conditions of the type | arguments are met. Is this worth pursuing? Would be a significant amount of | work? Am I being pushy if I make this a feature-request? | | Regards, | Philip | | PS. I'm going to study the Trac you pointed to in more detail; browsing it was | already a learning experience about the whats and wheres of the GHC API. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Strange behavior when using stable names inside ghci?
On 27/06/12 22:41, Facundo Domínguez wrote:
Hi,
The program below when loaded in ghci prints always False, and when
compiled with ghc it prints True. I'm using ghc-7.4.1 and I cannot
quite explain such behavior. Any hints?
Thanks in advance,
Facundo
{-# LANGUAGE GADTs #-}
import System.Mem.StableName
import Unsafe.Coerce
import GHC.Conc
data D where
D :: a -> b -> D
main = do
putStr "type enter"
s<- getLine
let i = fromEnum$ head$ s++"0"
d = D i i
case d of
D a b -> do
let a' = a
sn0<- pseq a'$ makeStableName a'
sn1<- pseq b$ makeStableName b
print (sn0==unsafeCoerce sn1)
GHCi adds some extra annotations around certain subexpressions to
support the debugger. This will make some things that would have equal
StableNames when compiled have unequal StableNames in GHCi. You would
see the same problem if you compile with -fhpc, which adds annotations
around every subexpression.
For your intended use of StableNames I imagine you can probably just
live with this limitation - others are doing the same (e.g. Accelerate
and Kansas Lava).
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC Users] Dictionary sharing
I say "usually" because while I believe this to be true for the current implementation of GHC, I don't think we necessary give this operational guarantee. But yes, your real problem is that there is a world of difference between functions and non-functions. You will need to use one of the usual tricks for memoising functions, or forgo using a function altogether and lean on laziness. Edward Excerpts from Jonas Almström Duregård's message of Fri Jun 29 11:21:46 -0400 2012: > Thank you for your response Edward, > > You write that it is usually only evaluated once, do you know the > circumstances under which it is evaluated more than once? I have some > examples of this but they are all very large. > > The real issue I was having was actually not with a list but with a > memoised function i.e. something like: > >>> > class C a where > memoised :: Int -> a > <<< > > Perhaps functions are treated differently? > > Regards, > Jonas > > On 29 June 2012 15:55, Edward Z. Yang wrote: > > Hello Jonas, > > > > Like other top-level definitions, these instances are considered CAFs > > (constant applicative forms), so these instances will in fact usually > > be evaluated only once per type X. > > > > import System.IO.Unsafe > > class C a where > > dflt :: a > > instance C Int where > > dflt = unsafePerformIO (putStrLn "bang" >> return 2) > > main = do > > print (dflt :: Int) > > print (dflt :: Int) > > print (dflt :: Int) > > > > ezyang@javelin:~/Dev/haskell$ ./caf > > bang > > 2 > > 2 > > 2 > > > > Cheers, > > Edward > > > > Excerpts from Jonas Almström Duregård's message of Fri Jun 29 07:25:42 > > -0400 2012: > >> Hi, > >> > >> Is there a way to ensure that functions in a class instance are > >> treated as top level definitions and not re-evaluated? > >> > >> For instance if I have this: > >> >>> > >> class C a where > >> list :: [a] > >> > >> instance List a => List [a] where > >> list = permutations list > >> <<< > >> How can I ensure that list :: [[X]] is evaluated at most once for any > >> type X (throughout my program)? > >> > >> I assume this is potentially harmful, since list can never be garbage > >> collected and there may exist an unbounded number of X's. > >> > >> I currently have a solution that uses Typeable to memoise the result > >> of the function based on its type. Is there an easier way? > >> > >> Regards, > >> Jonas > >> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC Users] Dictionary sharing
Thank you for your response Edward, You write that it is usually only evaluated once, do you know the circumstances under which it is evaluated more than once? I have some examples of this but they are all very large. The real issue I was having was actually not with a list but with a memoised function i.e. something like: >>> class C a where memoised :: Int -> a <<< Perhaps functions are treated differently? Regards, Jonas On 29 June 2012 15:55, Edward Z. Yang wrote: > Hello Jonas, > > Like other top-level definitions, these instances are considered CAFs > (constant applicative forms), so these instances will in fact usually > be evaluated only once per type X. > > import System.IO.Unsafe > class C a where > dflt :: a > instance C Int where > dflt = unsafePerformIO (putStrLn "bang" >> return 2) > main = do > print (dflt :: Int) > print (dflt :: Int) > print (dflt :: Int) > > ezyang@javelin:~/Dev/haskell$ ./caf > bang > 2 > 2 > 2 > > Cheers, > Edward > > Excerpts from Jonas Almström Duregård's message of Fri Jun 29 07:25:42 -0400 > 2012: >> Hi, >> >> Is there a way to ensure that functions in a class instance are >> treated as top level definitions and not re-evaluated? >> >> For instance if I have this: >> >>> >> class C a where >> list :: [a] >> >> instance List a => List [a] where >> list = permutations list >> <<< >> How can I ensure that list :: [[X]] is evaluated at most once for any >> type X (throughout my program)? >> >> I assume this is potentially harmful, since list can never be garbage >> collected and there may exist an unbounded number of X's. >> >> I currently have a solution that uses Typeable to memoise the result >> of the function based on its type. Is there an easier way? >> >> Regards, >> Jonas >> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC Users] Dictionary sharing
Hello Jonas, Like other top-level definitions, these instances are considered CAFs (constant applicative forms), so these instances will in fact usually be evaluated only once per type X. import System.IO.Unsafe class C a where dflt :: a instance C Int where dflt = unsafePerformIO (putStrLn "bang" >> return 2) main = do print (dflt :: Int) print (dflt :: Int) print (dflt :: Int) ezyang@javelin:~/Dev/haskell$ ./caf bang 2 2 2 Cheers, Edward Excerpts from Jonas Almström Duregård's message of Fri Jun 29 07:25:42 -0400 2012: > Hi, > > Is there a way to ensure that functions in a class instance are > treated as top level definitions and not re-evaluated? > > For instance if I have this: > >>> > class C a where > list :: [a] > > instance List a => List [a] where > list = permutations list > <<< > How can I ensure that list :: [[X]] is evaluated at most once for any > type X (throughout my program)? > > I assume this is potentially harmful, since list can never be garbage > collected and there may exist an unbounded number of X's. > > I currently have a solution that uses Typeable to memoise the result > of the function based on its type. Is there an easier way? > > Regards, > Jonas > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[GHC Users] Dictionary sharing
Hi, Is there a way to ensure that functions in a class instance are treated as top level definitions and not re-evaluated? For instance if I have this: >>> class C a where list :: [a] instance List a => List [a] where list = permutations list <<< How can I ensure that list :: [[X]] is evaluated at most once for any type X (throughout my program)? I assume this is potentially harmful, since list can never be garbage collected and there may exist an unbounded number of X's. I currently have a solution that uses Typeable to memoise the result of the function based on its type. Is there an easier way? Regards, Jonas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
