Re: [Haskell-cafe] graphics on mac os x
On Thu, 2006-02-23 at 18:19 -0800, jeff p wrote: Hello, I am running ghc 6.4.1 on mac os X (10.4.5). Can anyone give me some pointers for getting graphics functionality? I have tried wxhaskell, but it gives me the error HelloWorld.hs:4:0: Failed to load interface for `Graphics.UI.WX': Bad interface file: /usr/local/wxhaskell/lib/imports/Graphics/UI/WX.hi mismatched interface file versions: expected 6041, found 6040 when I try to compile the HelloWorld.hs program following the mac os x instructions. You need to use the same version of ghc as was used to complie the wx package. So in this case it looks like you're using ghc 6.4.1 but wx was complied with ghc 6.4. You can rebuild wx from source with ghc 6.4.1. I have also tried to run Graphics.HGL in X11, but I get the error: Loading package X11-1.1 ... can't load .so/.DLL for: X11 (dlopen(libX11.dylib, 10): image not found) Do you have X11 installed? when I try to run the obligatory Hello World program from inside ghci. Are there other high/medium level graphics options for haskell on macs? Gtk2Hs does work on macs though until the Gtk+ hackers have finished the native port (which is in progress) it doesn't look perfect. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell programming guidelines
On 20/02/06, John Meacham [EMAIL PROTECTED] wrote: There is a more straightforward way to get localized error messages rather than using 'maybe' and hand-writing an appropriate error, and that is to rely on irrefutable bindings. f x = ... y ... where Just y = Map.lookup x theMap now if the lookup fails you automatically get an error message pointing to the exact line number of the failure. or if the failure message of the routine is more important than the source location you can do f x = ... y ... where Identity y = Map.lookup x theMap it is anoying you have to make a choice between these two possibilities, but this can be mitigated with CPP magic or the SRCLOC_ANNOTATE pragma. John I look at the above as generating a proof obligation for me as the programmer that the lookup will never fail, or at least the ability to convince myself. :) If you want to handle errors, you should actually handle them, not let your users get Irrefutable pattern failed messages. Also, if someone else later comes along and wants to catch that error, they have to either do it in IO, which can be fiddly if the error occurs deep in the evaluation of some structure, or they refactor your code so that it returns the error explicitly. Sure, irrefutable pattern matches are useful, but they shouldn't be used if you expect they'll ever fail. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell programming guidelines
On Fri, Feb 24, 2006 at 12:39:27PM -0500, Cale Gibbard wrote: I look at the above as generating a proof obligation for me as the programmer that the lookup will never fail, or at least the ability to convince myself. :) If you want to handle errors, you should actually handle them, not let your users get Irrefutable pattern failed messages. Also, if someone else later comes along and wants to catch that error, they have to either do it in IO, which can be fiddly if the error occurs deep in the evaluation of some structure, or they refactor your code so that it returns the error explicitly. Sure, irrefutable pattern matches are useful, but they shouldn't be used if you expect they'll ever fail. Ah, perhaps I wasn't clear. I don't ever expect these to fail. The reason I prefer irrefutable pattern matches to handwritten 'error' messages (at first) is so many months later when I introduce a subtle heisenbug I don't get a error: This shouldn't happen or worse error: Prelude.undefined but rather a nice error pointing right to the line number. anything I ever expect to fail for any reason other than a bug I put in a failing Monad with a suitably user digestable error message. So, I was comparing them to handwritten 'error' messages for announcing programming bugs. not handwritten 'error' messages for users to see (which really should be using 'fail' in a monad anyway). John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (Un)termination of overloading resolution
On Wed, 2006-02-22 at 12:33 +0800, Martin Sulzmann wrote:
In case we have an n-ary type function T
(or (n+1)-ary type class constraint T)
the conditions says
for each
type T t1 ... tn = t
(or rule T t1 ... tn x == t)
then rank(ti) rank(t) for each i=1,..,n
I'm probably misunderstanding something but doesn't this imply that we
cannot declare any instances for
class C a b | a - b, b - a
which do not break the bound variable condition? This would remove one
of the main advantages fundeps have over associated types.
In general, wouldn't it be better to look at *all* visible instance
declarations when they are used instead of looking at each one
individually when it is defined? If the goal is to allow only primitive
recursion, then that would lead to much more permissive rules.
As to the non-termination of GHC's type checker, below is an example
which encodes a stripped-down version of the lambda calculus (with only
one variable) and then evaluates (\x. x x) (\x. x x). Loops nicely with
GHC 6.4.1, but the second Subst instance is invalid under your rule if I
understand correctly.
Roman
{-# OPTIONS -fglasgow-exts #-}
data X
data App t u
data Lam t
class Subst s t u | s t - u
instance Subst X u u
instance (Subst s u s', Subst t u t') = Subst (App s t) u (App s' t')
instance Subst (Lam t) u (Lam t)
class Apply s t u | s t - u
instance (Subst s t u, Eval u u') = Apply (Lam s) t u'
class Eval t u | t - u
instance Eval X X
instance Eval (Lam t) (Lam t)
instance (Eval s s', Apply s' t u) = Eval (App s t) u
x = undefined :: Eval (App (Lam (App X X)) (Lam (App X X))) u = u
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
