- Haskell-Cafe - Haskell.org

Cabal ^M bug
by Vyacheslav Akhmechet 19 Nov '06

19 Nov '06

Cabal appears to have an end-of-line bug. If the .cabal file is created on Windows and the project is installed on a Unix system, the resulting executable ends up having ^M at the end because Cabal doesn't properly handle Windows line termination. If the .cabal file is converted to Unix style, everything installs as expected. I tried to submit a ticket to Cabal via the wiki but couldn't authenticate (guest/haskell, as says on the web page, doesn't seem to work). Also HackageDB link seems to be down. I'm not sure who's maintaining the project, so I'm emaling here. Thanks, - Slava.

1 0

Type signatures in FFI exported functions
by Alfonso Acosta 19 Nov '06

19 Nov '06

Hi, The FFI doesn't allow using type signatures in exported functions. Imagine this simplified example class Foo a where action1 :: a -> IO() action2 :: a -> IO() exportable :: Foo a => StablePtr a -> IO() exportable ptr = do deref <- deRefStablePtr ptr action1 deref Currently the FFI doesn't allow to export exportable due to the type signature. But I don't really understand why isn't it feisable. In my code I solved the problem by quantifying existentially data CFoo = forall a.Foo a => CFoo a instance Foo CFoo where action1 (CFoo a) = action1 a action2 (CFoo a) = action2 a exportable' :: StablePtr CFoo -> IO() exportable' ptr = do deref <- deRefStablePtr ptr action1 a Another way to fix it would be, unlike standard Haskell98, allowing dictionaries to be packaged in data constructors data CFoo' a = Foo a => CFoo' a instance Foo (CFoo' a) where action1 (CFoo' x) = action1 x action2 (CFoo' x) = action2 x exportable'' :: StablePtr (CFoo' a) -> IO() exportable'' ptr = do deref <- deRefStablePtr ptr action1 deref As far as I know, the later option has only been recently made available for GADTs in GHC, does anyone know away of doing it with normal ADT? Does anyone know a better workaround? Thanks in advance, Alfonso Acosta

1 0

Debugging partial functions by the rules
by dons＠cse.unsw.edu.au 18 Nov '06

18 Nov '06

So all this talk of locating head [] and fromJust failures got me thinking: Couldn't we just use rewrite rules to rewrite *transparently* all uses of fromJust to safeFromJust, tagging the call site with a location? To work this requires a few things to go right: * a rewrite rule * assertions * and rewrite rules firing before assertions are expanded Let's try this. Consider the program: 1 import qualified Data.Map as M 2 import Data.Maybe 3 4 main = print f 5 6 f = let m = M.fromList 7 [(1,"1") 8 ,(2,"2") 9 ,(3,"3")] 10 s = M.lookup 4 m 11 in fromJust s When we run it we get the not so useful error: $ ./A A: Maybe.fromJust: Nothing Ok, so we have a few tricks for locating this, using LocH (http://www.cse.unsw.edu.au/~dons/loch.html) we can catch an assertion failure, but we have to insert the assertion by hand: 1 import Debug.Trace.Location 2 import qualified Data.Map as M 3 import Data.Maybe 4 5 main = do print f 6 7 f = let m = M.fromList 8 [(1,"1") 9 ,(2,"2") 10 ,(3,"3")] 11 s = M.lookup 4 m 12 in safeFromJust assert s 13 14 safeFromJust a = check a . fromJust Which correctly identifies the call site: $ ./A A: A.hs:12:20-25: Maybe.fromJust: Nothing Now, this approach is a little fragile. 'assert' is only respected by GHC if -O is *not* on, so if we happened to try this trick with -O, we'd get: $ ./A A: Debug.Trace.Location.failure So lesson one: you have to do the bug hunting with -Onot. Currently there's -fignore-asserts for turning off assertions, but no flag for turning them on with -O, Simon, could this be fixed? Could we get a -frespect-asserts that works even with -O ? Ok, assuming this assert trick is used, can we get the compiler to insert the asserts for us? If so, this would be a great advantage, you'd just be able to switch on a flag, or import a debugging module, and your fromJusts would be transparently rewritten. With rewrite rules we do just this! So, to our initial unsafe use of fromJust, we add a rewrite rule: -- -- rewrite fromJust to a located version, and hope that GHC expands -- 'assert' after the rule fires.. -- {-# RULES "located fromJust" fromJust = check assert . myFromJust #-} This just tells the compiler to replace every occurence of fromJust with a assertion-throwing fromJust, should it fail. We have to use myFromJust here, to avoid rule recursion. -- -- Inlined to avoid recursion in the rule: -- myFromJust :: Maybe a -> a myFromJust Nothing = error "Maybe.fromJust: Nothing" -- yuck myFromJust (Just x) = x Ok, so can we get ghc to rewrite fromJust to the safe fromJust magicaly? $ ghc --make -Onot A.hs -fglasgow-exts -ddump-simpl-stats [1 of 1] Compiling Main ( A.hs, A.o ) 1 RuleFired 1 located fromJust Linking A ... Yes, the rule fired! GHC *did* rewrite our fromJust to a more useful fromJust. Running it: $ ./A A: A.hs:19:36-41: Maybe.fromJust: Nothing Looks good! But that is deceiving: the assert was expanded before the rule fired, and refers to the rewrite rule source line (line 19), not the fromJust call site (line 12). Now if we could just have the 'assert' token inserted into the AST before it was expanded, we'd be home and dry. Could this be done with TH? Or could we arrange for asserts in rewrite rules not to be expanded till later? Note that this is still a useful technique, we can rewrite head/fromJust/... to some other possibly more useful message. And if we can constrain the rule to fire in only particular modules, we may be able to narrow down the bug, just by turning on a rule. For example, adding: {-# RULES "located fromJust" fromJust = safeFromJust #-} safeFromJust s = case s of Nothing -> "safeFromJust: failed with Nothing. Ouch" Just x -> x will produce: $ ./A "safeFromJust: failed with Nothing. Ouch" So rewrite rules can be used to transparently alter uses of partial functions like head and fromJust. So, further work: * have 'assert' respected when -O is on * think up a technique for splicing in 'assert' via rewrite rules (or TH ...) such that the src locations are expanded after the rewrite, and correctly reflect the location of the splice point. Any ideas? -- Don

6 10

Re: Debugging partial functions by the rules
by oleg＠pobox.com 18 Nov '06

18 Nov '06

Donald Bruce Stewart wrote: > So all this talk of locating head [] and fromJust failures got me > thinking: > > Couldn't we just use rewrite rules to rewrite *transparently* > all uses of fromJust to safeFromJust, tagging the call site > with a location? I'm sorry for shifting the topic: I'm wondering if, rather than trying to make an error message more informative, we ought to make sure that no error will ever arise? The fromJust and `head of empty list' errors are totally equivalent to the dereferencing of zero pointer in C++ or NullPointerException in Java. It pains me to see that exactly the same problem arises in Haskell -- keeping in mind that already in C++ and Java one may exterminate these errors given right encapsulations. Languages like Cyclone or Cw use the type system to eliminate such errors. Surely Haskell can do something about this? This topic has been discussed at length on this list. It seems that the discussion came to the conclusion that eliminating head of the empty list error is possible and quite easy in Haskell. http://www.haskell.org/pipermail/haskell-cafe/2006-September/017915.html http://www.haskell.org/pipermail/haskell-cafe/2006-September/017937.html As to fromJust: would the world come to an end if this function is just not available? Oftentimes when we get the value of the type |Maybe a|, the algorithm prescribes the actions for the case if this value is Nothing. Thus the function `maybe', the deconstructor, seems to be called for. And if we are dead sure that the |Maybe a| value is definitely |Just smth| and we need to extract this |smth|, we can always write maybe (assert False undefined) id value I like how this phrase stands out in the code, to remind me to double-check my certainty about the value (and perhaps, to re-factor the code). Similarly for empty lists: it is often algorithmically significant as it is the base case for our recursion/induction. Thus, we have to make the null check according to the algorithm anyway. The type system can carry the result of such a test, so we don't have to repeat it. The functions head and tail should operate on the newtype NonemptyList -- in which case they are total. Other list functions may remain as they are, because we can always `forget' the NonemptyList tag. The run-time overhead is zero, the notational overhead is not much: writing a few extra `fromNonemptyList'. Compare with writing `fromIntegral', especially in the FFI-related code. The Haskell type system can do far more complex things, for example, solve the pervasive SQL injections and cross-site scripting problems: http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-st… (This URL appeared on one of the recent Haskell Weekly News, btw). Surely we can do something about a far simpler problem of head [] and fromJust? We may have to adjust our coding styles a little. The adjustment doesn't appear extensive; besides, isn't the whole point of programming in Haskell is to think differently?

20 31

working with lists of couples
by Clara Zamolo 18 Nov '06

18 Nov '06

Hello, i'd like to write a function that given a list like [1,2,3,4...] returns a list of couple where the first element is the corresponding element of the string, and the second is the sum of the previous elements. An example: input: [1,2,3,4] output: [(1,0)(2,1)(3,3)(4,6)] The problem could seem trivial, and here's a first solution: buildCouples = snd . foldl op (0,[]) where op (v,xs) x = (v+x,xs++[(x,v)]) The problem is that this solution is quadratic, and I want a solution that take time n (2n is not good either). Any suggestion? Thanks, Clare.

4 4

Are associated types synonyms like type classes?
by Brian Smith 18 Nov '06

18 Nov '06

I read the easy parts of the "Associated Types with Class" and "Associated Type Synonyms" papers. An associated type synonym seems to kind of work similarly to a restricted form of class. In what way are the two following examples different? -- define a class with a type synonym, and a set of operations class A a where type B b foo :: a -> B b instance A Int where type B = Bool foo = (==0) -- define two classes, and an function that . class A a, B b where foo :: a -> b instance A Int, B Bool where foo = (==0) Also, has anybody written a paper on the differences between typeclasses + associated types and ML's module system + overloading? Thanks, Brian

4 5

Re[2]: [Haskell] I18N, external strings
by Bulat Ziganshin 18 Nov '06

18 Nov '06

Hello Axel, Friday, November 17, 2006, 11:27:00 AM, you wrote: > (l_ "Translate this") > is compiled into a C string constant, that GHC then turns lazily into a > list of characters, which l_ then turns into an array in C land to pass > to the gettext function, which, in turn, returns a new C string array > that has to be turned into a Haskell string again. So I'm glad Lennart > proposed to turn String into a class which would then make it possible > to pass a pointer to a contant C string to gettext. i'm not sure that you are right. GHC can perform compile-time computation of constant expressions. Don Bruce should know better, once he pointed out how a String constant can be turned into ByteString one at compile time -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

Updated School of Expression Sources?
by Justin Bailey 18 Nov '06

18 Nov '06

I downloaded the SOE sources from http://www.haskell.org/soe and found they were not compatible with the my version of WinHugs (Sep 2006). I have two questions: 1) Is an updated version of those sources available? 2) If not, would someone like to host mine? I updated all the source files so they at least load without error. Mostly it involved changing a few import statements. I also had to make some updates to the included Haskore files. Also, I found the some of the programs included crash Hugs without warning. For example, evaluating "test cball5" in the file "Fal.lhs" will crash Hugs after running for a few seconds, or if the mouse is moved over the window. Does anyone know why that may occur? Justin

3 2

Newbie; Can't Install Hat From Source
by Aditya Siram 18 Nov '06

18 Nov '06

Hi all, I have been trying to install Hat for the last couple of days but GHC does not recognize it as a package. I compiled 2.05 from source, but at the 'make install' step I see this error message: **Begin Output** ./configure --install Configuring for hat... [ 2.05 ] Starting with earlier config in targets/ix86-Linux/config.cache [ config: ix86-Linux/ by deech@ubuntu on 15 Nov 2006 ] (but cmdline options have precedence) -------- Looking for already-installed Haskell compilers: Looking for ghc... found 6.6 Looking for nhc98... (not found) Looking for hmake... found 3.13 You said you want to use ghc to build hat. Done. -------- Configuration report for hat. You are going to build hat with: ghc Executables need .exe suffix? no (detected) Testing for the glib library: no (using slower replacement) Installation directories are now created/checked. Install directory root is: /usr/local Hat interface files (.hx) go into: /usr/local/include/hat-2.05 (exists) Array.hx ...... Debug/Trace.hx Installing hat as a ghc package: Installing hat package for ghc under /usr/local/lib/hat-2.05/ix86-Linux/ghc-606 ghc-pkg: cannot find package hat <-----ERROR MESSAGE!!!!! Reading package info from stdin ... done. ghc-pkg: package hat-2.4 is already installed Scripts go into: /usr/local/bin (exists) hat-graph hat-trans hat-tools: hat-stack hat-check hat-observe hat-detect hat-delta hat-view hat-trail hat-anim hat-explore hat-cover black-hat hat-nonterm pretty-hat Executables go into: /usr/local/lib/hat-2.05/ix86-Linux (exists) config hat-anim hat-check hat-cover hat-delta hat-detect hat-explore hat-nonterm hat-observe hat-stack hat-trail hat-trans hat-view black-hat pretty-hat Man pages go into: /usr/local/man/man1 (exists) hat-anim.1 hat-delta.1 hat-detect.1 hat-observe.1 hat-stack.1 hat-trail.1 hat-trans.1 pretty-hat.1 Not (re-)installing html documents Saving current configuration in targets/ix86-Linux/config.cache Done. Please ensure /usr/local/bin is in your PATH variable. **End Of Output** The output of 'ghc-pkg list' is: /usr/local/lib/ghc-6.6/package.conf: Cabal-1.1.6, HUnit-1.1, QuickCheck-1.0, base-2.0, cgi-2006.9.6, fgl-5.2, (ghc-6.6), haskell-src-1.0, haskell98-1.0, html-1.0, mtl-1.0, network-2.0, parsec-2.0, readline-1.0, regex-base-0.71, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.0, time-1.0, unix-1.0, xhtml-2006.9.13 /home/deech/.ghc/i386-linux-6.6/package.conf: (hat-2.4) <----ERROR!!! For some reason it thinks that hat-2.4 is installed. I tried to run a test program saved in HatTest.hs: import Prelude main = do { print "Hello"; } When I compile it with 'hmake -hat HatTest' I get the following error: hat-trans HatTest.hs Wrote Hat/HatTest.hs ghc-6.6 -c -package hat -o Hat/HatTest.o Hat/HatTest.hs Hat/HatTest.hs:3:0: Bad interface file: /usr/local/imports/hat-2.05/ghc-606/Hat/PreludeBasic.hi Something is amiss; requested module hat-2.4:Hat.PreludeBasic differs from name found in the interface file hat:Hat.PreludeBasic I'm not really sure how to proceed. Any help is appreciated. BTW I get the ghc-package: cannot find package hat when I 'apt-get install' it too. Thanks.. Deech _________________________________________________________________ View Athletes Collections with Live Search http://sportmaps.live.com/index.html?source=hmemailtaglinenov06&FORM=MGAC01

2 2

Generalizing zip
by Jason Dagit 17 Nov '06

17 Nov '06

In #haskell on freenode we had a discussion about isPrefixOf, which is probably implemented roughly as so: isPrefixOf [] _ = True isPrefixOf _ [] = False isPrefixOf (x:xs) (y:ys) = x == y && isPrefixOf xs ys Well, this is basically just a zip with a special base case. But you can't just write it with zipWith because zipWith stops when it exausts either list. How about we define zipWith'' like this: zipWith'' _ [] _ l _ = [l] zipWith'' _ _ [] _ r = [r] zipWith'' f (x:xs) (y:ys) l r = f x y : zipWith'' f xs ys l r Then we can write: isPrefixOf xs ys = and (zipWith'' (==) xs ys True False) A point free reduction might look like the following and probably isn't worth it: isPrefixOf = (and .) . flip flip False . flip flip True . zipWith'' (==) Are there lots of other places where this zipWith'' would come in handy? It seems like I've found lots of times when I needed to manually code the recursion because of the way zip behaves when it exhausts one of its parameter lists. Jason

3 3

topEq for types
by Nicolas Frisby 17 Nov '06

17 Nov '06

I'm sharing what I think is a novel extension of TypeEq. Please 1) cope with my introduction of the motivating problem 2) inform me if something similar has already been presented 3) criticize the solution This presentation is quite a simplification of my actual problem/code, but I'm trying to just show the essence of the technique. Feel free to request the real story or for me to actually code this up. Disclaimer: the following is an untested presentation of correctly functioning code. Thanks for your time. Motivation: In the HList paper, a subtle example involved polymorphism and the singleton list. Because the list was a singleton, TypeCast can be used to resolve the polymorphism. Otherwise, the polymorphism (i.e. free type variables) would prevent crucial typeclass instances from firing. This has inspired a solution to a recent problem of mine. I essentially had an HList of functor values that share the same carrier type. Envision the type of such a list as [F0 Char, F1 Char, ..., Fn Char] where Fi is a functor. I occasionally wanted to "update" one of these values: fn :: F0 Char -> F0 Char fn (F0_CtorOfInterest c) = ...new value... fn f0_c = f0_c newList = specialHMap fn oldList This works fine; the specialHMap method/class is pretty easy to write using TypeEq. The problem arises when I introduce more interesting functors; consider [F Char, G Char, (BF Int) Char] where BF is a bifunctor. Targeting such an functor with an update operation will fail if the update does not specify t. fn2 :: (BF t) Char -> (BF t) Char fn2 (C0 _) = C1 'c' fn2 x = x When the typeclass instances traverse the HList and check each element for a type match, the polymorphism of t in fn2 precludes a successful match of any TypeEq instance. This was frustrating, because it prohibited me from writing modular code! Solution: My solution to the problem was to indicate to the typechecker that certain functors were unique in my HList. So if BF showed up in the HList with a first argument of t', then it would be safe to unify the free t from fn2 with t' (via TypeCast), because no other BF will show up in my list. This quickly generalized to types of various kind with various parameters free. The key to the solution is this class: > class TypeTopEq' () teq x y bn => TypeTopEq teq x y bn > | teq x y -> bn > class TypeTopEq' q teq x y bn > | q teq x y -> bn > class TypeTopEq'' q teq x y bn > | q teq x y -> bn > > instance TypeTopEq' () teq x y bn => TypeTopEq teq x y bn > > > instance TypeCast bn HTrue => TypeTopEq' () TEQ_ hd hd bn > > instance TypeCast bn HTrue => TypeTopEq' () TEQ_0 (hd a) (hd z) bn > instance TypeCast bn HTrue => TypeTopEq' () TEQ_1 (hd a) (hd a) bn > > instance TypeCast bn HTrue => TypeTopEq' () TEQ_00 (hd a b) (hd z y) bn > instance TypeCast bn HTrue => TypeTopEq' () TEQ_01 (hd a b) (hd z b) bn > instance TypeCast bn HTrue => TypeTopEq' () TEQ_10 (hd a b) (hd a y) bn > instance TypeCast bn HTrue => TypeTopEq' () TEQ_11 (hd a b) (hd a b) bn > > -- more instances and TEQ_* for higher kinds of hd TEQ stands for "top equality qualifier". Each 0 specifies that the corresponding argument to the functor is "soft" and not required to match while each 1 specifies that the type is "hard" and is required to match. For example, these instances result in TypeTopEq TEQ_ Int Char HFalse TypeTopEq TEQ_ Int Int HTrue TypeTopEq TEQ_0 (F Int) (F Int) HTrue TypeTopEq TEQ_0 (F Int) (F Char) HTrue TypeTopEq TEQ_0 (F Int) (F Char) HTrue TypeTopEq TEQ_1 (F Int) (F Char) HFalse TypeTopEq TEQ_0 (F Int) (G Int) HFalse TypeTopEq TEQ_1 (F Int) (G Int) HFalse TypeTopEq TEQ_00 (F2 Int Int) (F2 Char Char) HTrue TypeTopEq TEQ_01 (F2 Int Int) (F2 Char Char) HFalse TypeTopEq TEQ_10 (F2 Int Int) (F2 Char Char) HFalse TypeTopEq TEQ_11 (F2 Int Int) (F2 Char Char) HFalse TypeTopEq TEQ_01 (BF t x) (BF Int x) HTrue --- solves the problem above TypeTopEq TEQ_00 (F2 Int Char) (F2 Char Char) HTrue TypeTopEq TEQ_01 (F2 Int Char) (F2 Char Char) HTrue TypeTopEq TEQ_10 (F2 Int Char) (F2 Char Char) HFalse TypeTopEq TEQ_11 (F2 Int Char) (F2 Char Char) HFalse And so on. This class enables typecases based on the "top equality" of two type variables instead of requiring total equality. For example > class SpecialHMap a b l l' | a b l -> l' where specialHMap :: (a -> b) -> l -> l' > -- HNil case elided > instance ( TypeTopEq teq a head bn, HMap_Case bn a b (HCons teq head tail) l' > ) => SpecialHMap a b (HCons teq head tail) l' where > specialHMap = hmap_case (undefined :: bn) > > class HMap_Case a b l l' | a b l -> l' where hmap_case :: bn -> (a -> b) -> l -> l' > instance ( SpecialHMap a b tail tail' > , TypeCast head a > ) => HMap_Case HTrue a b (HCons teq head tail) (HCons teq b tail) where > hmap_case _ fn (HCons hd tl) = HCons (fn . typeCast $ hd) (specialHMap fn tail) > > -- HFalse/recursive instance elided Note that the HTrue instance uses TypeCast instead of multiple occurences of the same variable in the instance parameters. Unfortunately TypeTopEq wanders into the territory of varying kinds and gets a bit out of hand. It has, however, solved my problem. I used a variant of HCons that also has, as a phantom argument, the TEQ to be used for that element. When the typeclass instances traverse the HList, they use the TEQ for each element to decide how to check for a type match with the domain of the update function. Alternatively, I could try to write an overloaded uHCons function that will calculate the proper TEQ value for an element as it adds it to a list; but that was overkill at the moment. I hope that was interesting! I think this could be quickly expanded to other sorts of type-level pattern matching. Please share any thoughts. Thanks again, Nick

1 0

'type' for isomorphism [was poorly named: aggressiveness of functional dependencies]
by Nicolas Frisby 17 Nov '06

17 Nov '06

If anyone is interested, the solution to my problem was to use a type synonym instead of an isomorphism class. Pros: - Not susceptible to the functional dependencies/overlapping instances/open-world issue - Very simple (in fact that simplicity migrated into the rest of the system) Cons: - Obviously less flexible So it works, but it wasn't quite what I had hoped for. Has there been any work/proposals for specifying a "finalized" type class? I.E. Those not subject to overlap and thus "closed" to the world? Thanks, Nick On 11/11/06, apfelmus(a)quantentunnel.de <apfelmus(a)quantentunnel.de> wrote: > Nicolas Frisby wrote: > > First off, thanks for the reply. > > > > I am accustomed to GHC ignoring instance contexts as you mentioned. > > It's the "mostly" part that I'm curious about: mostly implies there's > > some phases that don't ignore context. Is that only the checking the > > type of the method definitions and absolutely nothing else? So it > > seems... > > I just said "mostly" because I don't know exactly... Though I strongly > suspect, like you, that the preconditions are only used in type > inference/checking and not for overlapping instances and similar > questions related to uniqueness of instance declarations. > > > > > My project is rather committed to GHC, but could you elaborate on your > > reference to Hugs being different? > > By tradition from Gofer, Hugs implements type classes more flexible than > GHC does. I once experimented with the following code using overlapping > instances: > > > data Lift a = Lift a > > type Test = Char > > > > class Message m o where > > send :: m -> o -> Test > > > > instance Message (o -> Test) o where > > send m o = m o > > > > instance Message m o => Message m (Lift o) where > > send m (Lift o) = send m o > > > > msg :: Test -> Test > > msg = id > > > > r1 = send msg 'a' > > r2 = send msg (Lift 'b') > > It implements some kind of subtyping. GHC won't typecheck this but "hugs > -98 +m" will. If I remember correctly, the problem was with > > instance Message (Lift a -> Test) (Lift a) > > Does this follow from the first or from the second instance declaration? > GHC ignores the precondition in the second declaration, thus believes it > follows from both and consequently rejects it. But Hugs has no problems > with that: it follows the precondition and sees that the second > declaration does not apply to the culprit because there is no (instance > (Lift a -> Test) a). Note that if you add this instance later on > (perhaps in a different module), things will break. > > The flexibility comes at a price: Gofer's type class system was unsound > and I don't know how much Hugs comes close to this. > > Regards, > apfelmus > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

ghc 6.2 and wxhaskell
by Leandro Maia 16 Nov '06

16 Nov '06

Hi Maybe this is not the best place to post this question, but here a lot of people will see and can direct me to the right place. I'm using Linux Slackware 10.2 and 11.0, GHC 6.2 and wxWidgets 2.6.X, 2.7.x I have already tried all kind of combinations but never worked. I tried: GHC 6.2 , 6.2.2, 6.4, 6.4.1, 6.6 wxWidgets 2.6.x, 2.7.x My best result was GHC 6.2 and wxwidgets 2.6.x. But all programs and samples using wxhaskell results in "segmentation fault" I would like to know how to solve this problem. I have to do my exercise but ... Thanks a lot. -- Leandro Maia

1 0

the case of the 100-fold program speedup
by Seth Gordon 16 Nov '06

16 Nov '06

One of Alan Perlis's "Epigrams in Programming" is "A language that doesn't affect the way you think about programming, is not worth knowing". I recently had an experience that demonstrated this principle. I had to write some code that took a polygon (encoded in WKT, a standard format for geographic information exchange), computed its intersection with several rectangles, and then compute the centroid of each one of these intersections. No problem, I thought. People who know more than me about this geometry stuff have written an open-source library, OGR, which has functions for parsing WKT, computing intersections, computing centroids, and computing all sorts of other things. And there are Python bindings for OGR so I don't have to wrestle with C++ to solve my problem. So I wrote a Python program that used OGR to crunch the numbers, ran it through the data set we needed to process, and...it took over sixteen hours to run. Since we want to have this program process this data set with every build of our software, adding sixteen hours to our build time was not a pleasant thought. Then I thought about some of the things I'd read about optimization of functional programming languages, and said, "Hey! The algorithm for clipping the polygon to the rectangle is producing a sequence of vertices, and the algorithm for computing the centroid is consuming a sequence of vertices. I can do some deforestation here!" It took me a week to figure out the right algorithm for combining these two procedures and write some almost-working code that implemented it. It took a co-worker of mine another few days to find the bugs that had eluded me. But after the program worked for my test cases, I ran it again on the full data set...and it took ten minutes. In other words, I sped up the code by two orders of magnitude. And I didn't even have to drop into C++ to do the number-crunching; I used OGR to parse the WKT strings and to look up the coordinates of each vertex of the polygon, but the algorithm itself was implemented in Python. w00t!

3 4

forall and a parse error
by Neil Mitchell 16 Nov '06

16 Nov '06

Hi, I was experimenting with forall and higher rank types briefly, in particular: x :: [forall a . a] This is illegal because of: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.htm… Which is fine, however its surprising to compare the error messages: [forall a . a] parse error on input `forall' [(forall a . a)] Illegal polymorphic or qualified type: forall a. a In the type signature: lst :: [(forall a. a)] In normal Haskell, I tend to view [x] as equivalent to [(x)] (provided that x is not a tuple) but in this case it has a different meaning - albeit both are erronous meanings. When running the example with Hugs, they both come out as syntax errors - the first on the forall, the second on the closing square bracket. Thanks Neil

5 6

Re: [Haskell-cafe] Re: Debugging partial functions by the rules
by John Hughes 16 Nov '06

16 Nov '06

> From: Robert Dockins <robdockins(a)fastmail.fm> > It seems to me that every possible use of a partial function has some > (possibly imagined) program invariant that prevents it from failing. > Otherwise it is downright wrong. 'head', 'fromJust' and friends > don't do anything to put that invariant in the program text. Well, not really. For example, I often write programs with command line arguments, that contain code of the form do ... [a,b] <- getArgs ... Of course the pattern match is partial, but if it fails, then the standard error message is good enough. This applies to "throw away" code, of course, and if I decide to keep the code then I sooner or later extend it to fix the partiality and give a more sensible error message. But it's still an advantage to be ABLE to write the more concise, but cruder version initially. This isn't a trivial point. We know that error handling code is a major part of software cost--it can even dominate the cost of the "correct case" code (by a large factor). Erlang's "program for the correct case" strategy, coupled with good fault tolerance mechanisms, is one reason for its commercial success--the cost of including error handling code *everywhere* is avoided. But this means accepting that code *may* very well fail--the failure is just going to be handled somewhere else. Haskell (or at least GHC) has good exception handling mechanisms too. We should be prepared to use them, and "let it fail" when things go wrong. The savings of doing so are too large to ignore. John

4 3

submenu doesn't seem to work properly in wxhaskell
by Maarten 16 Nov '06

16 Nov '06

Dear all, The following code doesn't seem to work properly. Either the main entry (m1/mp1) or it's sub menu entry (ms1/mps1) do not seem to propagate the event when pressed. It is possible to make it working by uncomments the lines where the menu commands are registered in the frame. I have the following two questions: 1. Why doesn't the plain code work. Am I missing something or doing something wrong? 2. Doesn't registering eventhandlers in the frame introduce a memory/resource leak, especially in the case of popups? Any suggestions or comments appreciated. Thanks. Kind regards, Maarten Code: <imports> gui :: IO () gui = do f <- frame [ text := "Hello world!" ] m <- menuPane [ text := "&Menu" ] m1 <- menuItem m [ text := "Menu m1", on command := putStrLn "menu m1"] -- set f [ on (menu m1) := putStrLn "menu m1" ] menuLine m sub <- menuPane [text := "Sub menu"] ms1 <- menuItem sub [ text := "submenu ms1", on command := putStrLn "submenu ms1" ] -- set f [ on (menu ms1) := putStrLn "submenu ms1" ] menuSub m sub [ text := "Sub" ] menuItem m [text := "E&xit", on command := close f] set f [menuBar := [m], on mouse := mouseEvent f, clientSize := sz 200 200 ] return () mouseEvent f eventMouse = do case eventMouse of MouseRightDown mousePoint _ -> doPopup f mousePoint _ -> return () doPopup f mousePoint = do m <- makePopupMenu f "&Popup" "Doesnt' work..." menuPopup m mousePoint f objectDelete m makePopupMenu f c t = do mp <- menuPane [ text := c ] mp1 <- menuItem mp [ text := "Popup mp1", on command := putStrLn "popup mp1"] -- set f [ on (menu mp1) := putStrLn "popup mp1" ] menuLine mp sub <- menuPane [text := "more text"] mps1 <- menuItem sub [ text := "Popup mps1", on command := putStrLn "popup mps1"] menuSub mp sub [ text := "Sub" ] -- set f [ on (menu mps1) := putStrLn "popup mps1" ] return mp

2 2

Haskell Debugging
by Valentin Gjorgjioski 16 Nov '06

16 Nov '06

I'm pretty new in Haskell, few days since I started learning it. I want to debu my programs. I'm currently using WinHugs, and I prefer debugger for this. I tried googling and I found Hugs.Observer. I like it how it works, but still I have one BIG problem with it. It doesn't work well with floats. Following example import Hugs.Observe ex8 :: [Float] ex8 = (observe "after reverse" ) reverse [10.0,7.0,3.0,0.0,4.0] gives me >ex8 [4.0,0.0,3.0,7.0,10.0] >>>>>>> Observations <<<<<< after reverse { \ ($-990871 : $-990888 : $-990905 : $-990922 : $-990939 : []) -> $-990939 : $-990922 : $-990905 : $-990888 : $-990871 : [] } Which is not useful. After that I try to install http://www.haskell.org/hat/ but for installing that I need hmake, and when I try to install hmake, I typed first configure -prefix, and then, make. cd src/hmake; make HC=ghc BUILDCOMP=ghc all config make[1]: Entering directory `/cygdrive/E/Haskell/hmake/src/hmake' Makefile:59: *** target pattern contains no `%'. Stop. make[1]: Leaving directory `/cygdrive/E/Haskell/hmake/src/hmake' make: *** [targets/ix86-CYGWIN_NT-5.1/hmake-ghc] Error 2 as you can see I'm using cygwin. I'm really stacked here, and I will kindly ask for help. Thanks, Valentin -- Valentin Gjorgjioski Bachelor of Computer Science Department of Knowledge Technologies, Jozef Stefan Institute Jamova 39, SI-1000 Ljubljana, Slovenia Phone: +386 1 477 3343 Fax: +386 1 477 3315 Web: http://kt.ijs.si/ValentinGjorgjioski/ Email: Valentin.Gjorgjioski(a)ijs.si

5 11

Re: Haskell custom search engine
by Alberto G. Corona 15 Nov '06

15 Nov '06

By the way, I have developped the core of a search engine completely in Haskell. It can index arbitrary objects (including files, of course) has definitions for filters, with predefined filters for plain text, HTML/XML and a general filter for Haskell data types It has basic search capabilities: it returns a list of identifiers (URIs) of the objects that contains all the entered keywords. But it is fairly easy to accept arbitrary AND OR and NOT conditions. Just query parsing is necessary. More info: http://haskell-web.blogspot.com/2006/11/search-engine-written-in-haskell.ht… The source of Search.hs can be found here<http://www.box.net/public/fdkami7jbk>

1 0

Re: [Haskell] I18N, external strings
by Bulat Ziganshin 15 Nov '06

15 Nov '06

Hello Johannes, Wednesday, November 15, 2006, 10:36:10 AM, you wrote: > What methods and tools are there for i18n of Haskell programs? > In Haskell, I see at least two problems: > a) reading the file is in IO if you need utf8 and other encodings support, you can use Streams lib: h <- openFile "test" ReadMode >>= withEncoding utf8 http://haskell.org/haskellwiki/Library/Streams > b) there are no "global variables". implicit parameters perhaps? there is a sort of global vars: ref_command = unsafePerformIO$ newIORef$ error "undefined ref_command" uiStartCommand command = do writeIORef ref_command command .. uiStartProcessing filelist = do command <- readIORef ref_command .. but implicit parameters, of course, are more intelligent approach -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

pleac, examples, etc
by brad clawsie 15 Nov '06

15 Nov '06

it would be great if some of the more informed posters here took a stab at filling in http://pleac.sourceforge.net/pleac_haskell/index.html a neat site for cookbook-style problem solving from looking over haskell documentation for a few months now, i would say what is missing is one central cookbook-style document (want to query a database? want to parse xml? etc etc) thanks

5 4

Great language shootout: reloaded
by dons＠cse.unsw.edu.au 14 Nov '06

14 Nov '06

So back in January we had lots of fun tuning up Haskell code for the Great Language Shootout[1]. We did quite well at the time, at one point ranking overall first[2]. After doing all we could with ghc 6.4.2, the Haskell entries have been left for the last 10 months, while we worked on new libraries (bytestring, regex-*). 1. http://shootout.alioth.debian.org/ 2. http://www.cse.unsw.edu.au/~dons/data/haskell_1.html Now the time has come to reload the shootout for another round! GHC 6.6 is on the 'sandbox' debian machine, and will soon be on the other shootout boxes[3], which means we can use: * Data.ByteString * regex-* libraries 3. http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=ghc&l… And thus greatly improve: fannkuch fasta k-nucleotide regex-dna reverse-complement sum-file While we're here we should fix: chameneos And anything else you want to take a look at. A community page has been set up to which you can submit improved entries: http://www.haskell.org/haskellwiki/Great_language_shootout So, install GHC 6.6, read up on Data.ByteString and the new regex libs, and submit faster code to the wiki! Our shootout-interface officer, musasabi, can then commit them to shootout cvs, once consensus is reached on the best code to submit. Let's take back first place! :) -- Don

6 7

deepSeq vs rnf
by Chad Scherrer 14 Nov '06

14 Nov '06

Hi, I had posted this question a while back, but I think it was in the middle of another discussion, and I never did get a reply. Do we really need both Control.Parallel.Strategies.rnf and deepSeq? Should we not always have x `deepSeq` y == rnf x `seq` y ? Maybe there's a distinction I'm missing, but it seems to me they're basically the same. -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

5 5

best Linux for GHC?
by Bulat Ziganshin 14 Nov '06

14 Nov '06

Hello haskell-cafe, Now i'm consider installation of some Linux version at my box. My friend offered me 3 variants: SuSe, Fedora Core 5, free variant of RedHat (i can't remember its name, may be Ubuntu?) what may be best for GHC-based development? in particular, i want to compile Haskell itself i suspect that it is a really dumb question, and GHC will work great just with any linux i can find :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

10 11

Testing non-exported functions using ghci
by John Ky 14 Nov '06

14 Nov '06

Hello, I have modules that don't export some functions. Is there a way I can access them from ghci without exporting them? Thanks -John

3 2

Re: [Haskell-cafe] Re: best Linux for GHC?
by Luis F. Araujo 14 Nov '06

14 Nov '06

Alex Queiroz wrote: >> Hallo, >> >> On 11/13/06, Mark T.B. Carroll <Mark.Carroll(a)aetion.com> wrote: >> >>> How up to date will Debian unstable's GHC be kept, though? It seems >>> pretty good at the moment, but there have been times when we've had to >>> install from source instead of via Debian earlier this year so that we >>> had GHC features and bugfixes in place - the Debian version has got >>> rather out of date at times with respect to stuff we needed. >>> >>> >> No OpenGL neither Gtk2hs in Debian Sid yet. :-( >> I'd recommend Gentoo for using these kind of packages. We even have darcs repository versions of Gtk2Hs in our gentoo haskell overlay. Regards,

1 0

Section Syntax Errors
by Aditya Siram 13 Nov '06

13 Nov '06

Hi all, I am learning about sections and currying from SOE. There are three functions below. The first is from SOE and the other two are my own practice functions. Why does the third function fail? --Test for negative numbers (from SOE pg 109). This works posInts :: [Integer] -> [Bool] posInts = map (> 0) --Add 1 to a list of numbers. This works. addOne :: [Integer] -> [Integer] addOne = map (+ 1) --Subtract 1 from a list of numbers. This does NOT work. --Fails in Hugs with: -- Instance of Num (Integer -> Integer) required for definition of testSections -- I tried : subOne :: Num a => [a] -> [a] -- and : subOne :: [Float] -> [Float] --in case the problem is with negative numbers. They both fail. --Without any type signature I get: -- Unresolved top level overloading subOne :: [Integer] -> [Integer] subOne = map (- 1) Thanks... Deech _________________________________________________________________ Add a Yahoo! contact to Windows Live Messenger for a chance to win a free trip! http://www.imagine-windowslive.com/minisites/yahoo/default.aspx?locale=en-u…

4 3

Great language shootout: reloaded
by tpledger＠ihug.co.nz 13 Nov '06

13 Nov '06

Donald Bruce Stewart wrote: [...] > While we're here we should fix: > chameneos > And anything else you want to take a > look at. > > A community page has been set up to > which you can submit improved entries: > http://www.haskell.org/haskellwiki/Great_language_shootout [...] Well, then! I've put a new chameneos solution up on the wiki, and will wait the recommended couple of days for Community Feedback. - Tom

2 1

ByteString FFI
by Donn Cave 13 Nov '06

13 Nov '06

How do people like to set up their foreign I/O functions to return ByteStrings? I was a little stumped over this yesterday evening, while trying to write ` recv :: Socket -> Int -> Int -> ByteString ' Doc says `Byte vectors are encoded as strict Word8 arrays of bytes, held in a ForeignPtr, and can be passed between C and Haskell with little effort.' Which sounds perfect - I'm always up for `little effort'! CString doesn't seem like the right thing for socket results, because the data shouldn't be NUL-terminated, and I might want to realloc when the returned data doesn't fill the buffer. I don't see any other Ptr-related function or constructor in the documentation - am I missing something there? Thanks, Donn Cave, donn(a)drizzle.com

3 4

GHCi 6.6 tab-completion of source file paths not working.
by Daniel McAllansmith 13 Nov '06

13 Nov '06

Hi. I've just installed GHC 6.6 on an amd64 running a gentoo linux distribution. With GHCi from 6.4.2 I could run "ghci" then do Prelude> :l Foo/Bar.hs by hitting tab after Foo to complete the path to Bar.hs This no longer works, hitting tab only shows what's in the pwd. If I run "ghci Foo/Bar.hs" then I can :r fine and I can do a :l Foo.Bar using tab-completion to complete the module name. Tab completion of in-scope functions looks to be working fine. Has anybody else experienced this problem? Thanks Daniel

2 1

A type class puzzle
by Yitzchak Gale 13 Nov '06

13 Nov '06

Consider the following sequence of functions that replace a single element in an n-dimensional list: replace0 :: a -> a -> a replace0 = const replace1 :: Int -> a -> [a] -> [a] replace1 i0 x xs | null t = h | otherwise = h ++ (replace0 x (head t) : tail t) where (h, t) = splitAt i0 xs replace2 :: Int -> Int -> a -> [[a]] -> [[a]] replace2 i0 i1 x xs | null t = h | otherwise = h ++ (replace1 i1 x (head t) : tail t) where (h, t) = splitAt i0 xs etc. Generalize this using type classes.

8 14

(twice head) && (twice tail)
by Greg Buchholz 13 Nov '06

13 Nov '06

Over on comp.lang.functional ( http://xrl.us/s6kv ), Toby Kelsey is wondering about writing a function "twice" that applies a function to an argument two times... > twice' :: (a -> a) -> a -> a > twice' f x = f (f x) ...that works for things like "twice succ 0" and "twice tail [1,2,3]", but the type signature means you can't try something like "twice head [[1]]". You can get the "twice head" case to work with a function like... > twice'' :: (forall a. (m a) -> a) -> (m (m b)) -> b > twice'' f x = f (f x) ...and if you want something like "twice (flip (:) [])", you'd use... > twice''' :: (forall a. a -> (m a)) -> b -> (m (m b)) > twice''' f x = f (f x) ...it seems like those type signatures have at least a passing resemblance, so I was wondering if you could use type classes to combine these functions. I tried something like... > class Twice a b c | a b -> c where > twice :: a -> b -> c > > instance Twice (a->a) a a where > twice f x = f (f x) > > instance Twice (forall a. (m a) -> a) (m (m b)) b where > twice f x = f (f x) ...but with ghc-6.6 it chokes with... Illegal polymorphic or qualified type: forall a. m a -> a In the instance declaration for `Twice (forall a. (m a) -> a) (m (m b)) b' ...I can't say I'm surprised, but I was wondering if anyone else has thoughts on how this limitation might be worked around. Curious, Greg Buchholz

2 1

Simple implementations of the lambda calculus
by Lennart Augustsson 12 Nov '06

12 Nov '06

Some time ago I made a little experiment and implemented an interpreter for the lambda-calculus in Haskell. The only reason was that I wanted to try different ways of doing it. So I did it using simple substitution (i.e., as the textbooks describe it), unique identifiers, deBruijn indicies, and higher order abstract syntax. You can get the code from http://darcs.augustsson.net/Darcs/Lambda/ or just check out small paper at http://darcs.augustsson.net/Darcs/ Lambda/top.pdf -- Lennart

1 0

Re: Livecoding music in Haskell
by Rohan Drape 12 Nov '06

12 Nov '06

On Tue Nov 7 16:32:11 EST 2006, alex wrote: > The way I see it there are two big issues - the first is drift and the > second is latency. As hinted at when Alex's work was discussed last November: "OSC messages can be timestamped, and SuperCollider has a sample accurate scheduling queue, so language timing jitter can easily be worked around." http://www.haskell.org/pipermail/haskell-cafe/2005-November/012483.html Currently Sound.SC3 has a procedure 'at' that can be used for scheduling. This procedure doesn't really belong in Sound.SC3, and ought probably be taken out. Still, with the current darcs repository the following makes a ping every second, on the second, sample accurately, for half a minute. If you run the binary twice the pings will be twice the amplitude, no phase errors - fingers crossed. import Sound.SC3 import Control.Concurrent (forkIO) ping f a = out 0 (sinOsc AR f 0 * e) where c = EnvNum (-4.0) e = envGen KR 1 a 0 1 removeSynth (envPerc 0.1 0.6 1 [c,c]) latency = 0.01 bundle t m = OscB (t + latency) m pinger = do now <- utc at (fromIntegral (ceiling now)) f where f t = do fd <- sc send' fd (bundle t [s_new "ping" (-1) AddToTail 1]) putStrLn "Sending ping" return 1.0 main = do fd <- sc putStrLn "Sending Ping Instrument" sync' fd (d_recv' "ping" (ping 440 0.1)) putStrLn "Resetting scsynth" reset fd putStrLn "Starting schedule thread" forkIO pinger putStrLn "Delaying main thread" pause 30 putStrLn "End of delay, exiting" The above assumes that scsynth is running on the local host at the standard port, 57110, and that the GHC runtime scheduler jitter plus localhost network latency for this task is below 0.01 seconds, which is true on my otherwise idle X31 at 600MHz - this is not at all bad, I am impressed in any case - setting latency to zero gives reports from scsynth of: > late 0.008414722 > late 0.006882722 > late 0.005348722 > late 0.003815721 > late 0.002282721 > late 0.000748721 Tacked on below, for interested readers, are some notes on a related scheme scheduler, the notes were written in response to a related query about scheme & scsynth some time ago. The relation to the haskell above is pretty straightforward, the haskell 'at' discards the notion of a mutable schedule - with cheap concurrency such a thing is of arguable use - and the haskell 'at' ought to allow the event generator to return Nothing to stop scheduling. Regards, Rohan ++ Simple sample accurate scheduling from runtimes with moderate scheduling jitter is straightforward using SuperCollider. One simple model is: (at Q TIME (lambda (t f) (EVENT t) (f DELTA))) at = the scheduler interface Q = a <schedule> value TIME = a UTC timestamp t = the scheduled UTC time (ie. TIME or subsequent delta), regardless of when the procedure actually runs f = a rescheduling function that in effect does (at Q (+ t DELTA) *SELF*) EVENT = the action, usually constructs an osc bundle and sends it to scsynth DELTA = the delta time to reschedule to, to not re-schedule just don't call f The EVENT sends a bundle to scsynth and adds latency as required so that the scheduled bundle arrives ahead of the timestamp, the actual sample-accurate scheduling is handled by a queue at scsynth. The example below will schedule a ping at each whole second, and the scheduling will be sample accurate so long as the scheme runtime jitter is less than 0.1 seconds minus the network latency to get a UDP packet to the scsynth address. Here (utc) gets the current time, (-> s p) sends an OSC packet p to the server s, (/s_new ...) makes a /s_new OSC message, & (bundle t m) makes an OSC packet converting the UTC timestamp to NTP. (define s (open-udp* "127.0.0.1" 57110)) (define Q (make-schedule*)) (define L 0.1) (define (ship t m) (-> s (bundle (+ t L) m))) (at Q (ceiling (utc)) (lambda (t f) (ship t (/s_new "ping" -1 1 1)) (f 1.0))) Obviously to schedule just one ping in five seconds time: (at Q (+ (utc) 5) (lambda (t _) (ship t (/s_new "ping" -1 1 1))))

2 3

Great language shootout: reloaded
by Isaac Gouy 12 Nov '06

12 Nov '06

Donald Bruce Stewart wrote: -snip- > I agree. Breaking the rules was mainly the reason for the drop. Entries > like chameneos and fasta. Also, the other language teams kept improving > things. Yes, I missed that opportunity for listing things in threes ;-) Over the year improved programs were contributed for other languages. In contrast to the last focussed effort by the Haskell community, many of the other programs are contributed by individuals working alone, over many weeks. > > Other language (perl, iirc) were affected far worse by the gzipping. > gzip is an interesting measurement, and it doesn't hurt Haskell too much > either way -- short Haskell programs stay short when compressed. > > As a result, rewriting verbose entries to ByteString will probably be > much more useful :) > > Btw, Isaac, are we going to have any new parallelism benchmarks? I'd > love to try out the SMP runtime ;) If we were to have a 'which is the silliest comparison on the computer language shootout' competition, I think chameneos and cheap-concurrency would be joint first - there are so many really really different approaches. Ideas for unicode text processing would be more welcome. ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com

1 0

Automatic fixity allocation for symbolic operators
by Brian Hulley 12 Nov '06

12 Nov '06

Hi - I'm wondering if it is possible to construct a methodical procedure to assign a fixity to symbolic operators so that we could get rid of the need for user defined fixites. User defined fixities are an enormous problem for an interactive editor, because it is not possible to construct a parse tree of some code if you don't know what the fixities are, and an editor must be able to do something useful with a code fragment without having to look inside other modules (because the other modules may not yet have even been written!). Also, the programmer or reader of code needs to be able to understand each code fragment independently as well. >From the Haskell98 report, the Prelude defines: infixr 9 ., !! infixr 8 ^, ^^, ** infixl 7 *, /, `quot`, `rem`, `div`, `mod` infixl 6 +, - infixr 5 :, ++ infix 4 ==, /=, <, <=, >=, > infixr 3 && infixr 2 || infixl 1 >>, >>= infixr 1 =<< infixr 0 $, $!, `seq` Suppose we ignore the varid operators and just consider the symbolic ops. What I'm trying to find is a systematic way to assign fixities to all other possible sequences of symbol characters that is consistent with what we've already got in the Prelude. As a first step, we could say that "mirrored" operators must share the same precedence ie: =<< >>= < > For associativity, we could assign each character an associativity weight: -1 left associative 0 neutral 1 right associative and say that the associativity is simply the sign of the sum of the associativity weights of the characters thus: > -1 = 0 < 1 =<< 0 + 1 + 1 ie infixr Note that I don't care about non-associative ops since the non-associativity of something should be a question for the type checker not the parser imho - ideally we should be able to create a parse tree for any possible operator expression. To form the precedence, we could assign each character a precedence value eg: 9 . ! 8 ^ 7 * / 6 + - 5 : 4 = 3 & 2 | 1 < > 0 $ A first attempt might be to say that the precedence is simply the decimal expansion of the precedence values eg >>= has precedence 1.14 and $! has precedence 0.9. However, as noted above, mirrored ops must share the same precedence so an alternative is to create some ordering of characters such that when the set of characters in an operator is sorted according to this ordering, the decimal expansion of the precedence digits will give the same relative ordering for operator precedences as the Prelude. For example, using $ | & + - * / ^ . ! : < > = as the ordering, we'd get: infixr 9 . !! 9 9.9 infixr 8 ^, ^^, ** 8 8.8 7.7 infixl 7 *, /, 7 7 infixl 6 +, - 6 6 infixr 5 : , ++ 5 6.6 infix 4 ==, /=, <, <=, >=, > 4.4 7.4 1 1.4 1.4 1 infixr 3 && 3.3 infixr 2 || 2.2 infixl 1 >>, >>= 1.1 1.14 infixr 1 =<< 1.14 infixr 0 $, $! 0 0.9 Although most existing ops get a similar precedence (eg ^ ^^ and ** are all still in the same group relative to the other ops despite the fact that within the group there is now an ordering) the main problem seems to be that < <= >= > get precedences that bind too loosely and /= is totally wrong. This problem aside, the above algorithm would give sensible precedences for such things as: :> <: 5.1 <+> <*> 6.11 6.11 where the use of <> neutralizes the associativity contribution of < or > respectively (since (-1) + 1 == 0), giving us the intuitive associativity we'd expect from the "interesting" character in the middle. (The problem of /= getting 7.4 could be solved by putting / after = in the order, to get 4.7, but unfortunately this would mean that since <> must be before =, <> would be before / so </> would get the wrong precedence compared to <*>) Another issue is that there is no assignment of associativity weights such that "*" is infixl but "**" is infixr (ditto + and ++) so perhaps we'd need to associate each character with an associativity function. Similar to precedences, we then define an associativity ordering and let the resulting associativity be the sign of the composition of the sorted functions applied to 1 eg: ^ const (-1) * \x -> x * (-1) = id & const (-1) < (+1) > (+ (-1)) Then * (\x -> x * (-1)) 1 === -1 ie left ** (\x -> x * (-1)) . (\x -> x * (-1)) $ 1 === +1 ie right >>= > > = (+ (-1)) . (+ (-1)) . id $ 1 === -1 <*> -- remember ordering * < > (\x -> x * (-1)) . (+1) . (+ (-1)) $ 1 === ((1 - 1) + 1) * (-1) === -1 ie left as required!!! :-) Anyway this is as far as I've got so far trying to rationally reconstruct the original Prelude precedences to achieve the golden aim of eliminating the infinite problem of fixity declarations from source code... :-) (Regarding `div` `seq` etc - I'd just assign them all the same precedence because use of multiple varid ops in the same expression with different precedences, or trying to combine them with symbolic ops, is just a highway to confusion city imho. Note also that (seq x $ exp) is not only clearer but is also one character shorter than (x `seq` exp)) The main open problem is finding an algorithm which assigns a good precedence to >>= as well as to >= and /= and </> and <*>.... ;-) Any ideas? Thanks, Brian. -- www.metamilk.com

21 57

Announcement: new maintainers forr wxHaskell
by Jeremy O'Donoghue 11 Nov '06

11 Nov '06

Hi all, I'd like to announce that we have a new team of maintainers in place for wxHaskell, so we're hoping that this list will see a significant increase in activtiy in the future. We have several near-term objectives, which will likely occur in roughly the order below: * Pull together all of the patches for various wxHaskell functionalities which are 'out there' into the core distribution. * Enhance support for Unicode. * Ensure that we support GHC 6.4.2 and GHC 6.6. * Add support for wxWidgets 2.6.3 and maintain support for wxWidgets 2.4.2. There are very good reasons why many wxHaskell users will want to continue to use 2.4.2. * 'Cabalize' the wxHaskell build system. * Add new examples and increase the coverage of different wxWidgets functionalities. * Create binary releases / installable packages for popular platforms (Windows, Mac, Debian are current favourites) The maintainers will work mainly on a public Darcs repository at http://darcs.haskell.org/wxhaskell, which will always contain the latest patches, but which may not always be stable. I will, from time to time, release reasonably stable updates of files to Sourceforge CVS, and we will aim for binary releases whenever this makes sense. I'd ask the community to send patches via this list. They will get added to the public Darcs repository once at least one of the maintainers has successfully integrated and built them. We will create a separate developers list if the volume of patches ever threatens to overwhelm the wxhaskell-users list :-) To go with the above, I hereby provide first patch to to the archive at http://darcs.haskell.org/wxhaskell as an attachment. This patch brings together patches from a number of sources (mainly Shelarcy and Eric) to provide some support for Unicode variants of wxWidgets, a couple of extra widgets, preliminary support for wxWidgets 2.6.3 and a patch to enable build with GHC 6.6. None of this would have been possible without a great bunch of volunteers who have come forward and shown great patience with the slow pace at which I have pulled this together. Eric Kow, Shelarcy, Mads Lindstrøm, Time Docker and Frank Berthold have all offered their assistance, and should take a virtual bow. Finally, none of this would have been possible without the assistance of Daan Leijen, the original author of most of wxHaskell, who has been gracious enough to offer advice, and to pass on everything we need to move forward.

4 3

aggressiveness of functional dependencies
by Nicolas Frisby 11 Nov '06

11 Nov '06

I have a question about functional dependencies, instance contexts, and type inference. A specific example and question is in the attached code. In brief the question is: to what degree does type inference use the functional dependencies of an instance's class and context? I believe I am wishing it were more aggressive than it is. Please note that I have not enabled overlapping instances. Any suggestions regarding how to get the inferred type of |rite_t1| to be the one I anticipated would be much appreciated. Of course, I would also appreciate explanations of why I shouldn't anticipate it! The rest of this message is a copy of the attached code. Thanks, Nick I'm using GHC 6.6, but I see the same inferred types with 6.4.1. > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-undecidable-instances #-} -- for the coverage condition > > module FunDepEx where A plain ole' isomorphism class. > class Iso a b | a -> b, b -> a where > rite :: a -> b > left :: b -> a Isomorphism lifts through the sum bifunctor. > bifmap_either f g = either (Left . f) (Right . g) > > instance ( Iso f f', Iso g g' > ) => Iso (Either f g) (Either f' g') where > rite = bifmap_either rite rite > left = bifmap_either left left Some types to play around with. > newtype MyChar = MyChar Char deriving (Show, Eq) > > instance Iso MyChar Char where > rite (MyChar c) = c > left c = MyChar c > instance Iso Char MyChar where > rite c = MyChar c > left (MyChar c) = c My type inference confusion follows; the unit arguments are just to suppress the monomorphism restriction. > t1 :: Either Char a > t1 = Left 'c' > > rite_t1 () = rite t1 The inferred type for rite_t1 is rite_t1 :: (Iso (Either Char a) (Either f' g')) => () -> Either f' g' Why isn't the inferred type of rite_t1 the same as the ascribed type of rite_t1'? > rite_t1' :: Iso b b' => () -> Either MyChar b' > rite_t1' () = rite t1

2 5

Great language shootout: reloaded
by Isaac Gouy 11 Nov '06

11 Nov '06

> On 11/10/06, Henk-Jan van Tuyl <hjgtuyl at chello.nl> wrote: >> >> Haskell suddenly dropped several places in the overall socre, when the >> size measurement changed from line-count to number-of-bytes after >> gzipping. Maybe it's worth it, to study why this is; Haskell programs >> are >> often much more compact then programs in other languages, but after >> gzipping, other languages do much better. One reason I can think of, is >> that for very short programs, the import statements weigh heavily. Before this gets out-of-hand, my memory is certainly fallible but as I recall Haskell /did not/ drop several places because size measurement changed from line-count to gzip byte-count. 1) Check the webpage that Don Stewart cached and note the values for the memory use and code-lines multipliers, and note the values for the benchmark weights http://www.cse.unsw.edu.au/~dons/data/haskell_1.html Now go to the computer language shootout website and note the multipliers and benchmark weights. 2) Some Haskell programs were pushed into 'interesting alternative implementations' because they'd strayed so far from the spirit of the benchmark. (It takes a while for people to notice and complain, but eventually they do.) ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

3 2

Template Haskell.
by szefirov＠ot.ru 11 Nov '06

11 Nov '06

Why doesn't reify return function body? reify (mkName "somefunction") for a function defined in the same module returns constructor VarI (of data type Info) that does not contain function declaration in (Maybe Dec) part. What actions should I perform to get a function body with patterns, expressions and all that?

2 1

Haskell Quiz Solution - Haskell Newbie Requesting Review
by Justin Bailey 11 Nov '06

11 Nov '06

As part of the Ruby Quiz in Haskell solutions appearing on the wiki recently, I just a solution to Ruby Quiz #100 - create a bytecode interpreter for a simple expression language. Like I said, the code below parses simple integer arithmetic expressions and generates byte codes for a hypothetical stack-based intepreter that would evaluate the expressions. To run it, save it as a literate haskell file and run "interpret_tests". That just shows correctness, though. Other output can be obtained by running "compile_tests" (shows bytes for all tests), "generate_tests" (symbolic bytecodes for all tests), and "eval_tests" (evaluate ASTs for all tests). To see the AST generated for a example expression, try something like 'parse "2-2-2"'. I'm just learning Haskell (about a month in) and if anyone has time and desire to critique the code below, I'd love to hear it. I come from an OOP (primarily C# & Ruby) background, so I'm really interested in getting a handle on the functional/Haskell "way" of coding. Thanks for any feedback! Justin p.s. This code is also available on the wiki: http://www.haskell.org/haskellwiki/Haskell_Quiz/Bytecode_Compiler/Solution_… p.p.s. The original ruby quiz is available at: http://www.rubyquiz.com/quiz100.html \begin{code} import Text.ParserCombinators.Parsec hiding (parse) import qualified Text.ParserCombinators.Parsec as P (parse) import Text.ParserCombinators.Parsec.Expr import Data.Bits import Data.Int -- Represents various operations that can be applied -- to expressions. data Op = Plus | Minus | Mult | Div | Pow | Mod | Neg deriving (Show, Eq) -- Represents expression we can build - either numbers or expressions -- connected by operators. This structure is the basis of the AST built -- when parsing data Expression = Statement Op Expression Expression | Val Integer | Empty deriving (Show) -- Define the byte codes that can be generated. data Bytecode = NOOP | CONST Integer | LCONST Integer | ADD | SUB | MUL | POW | DIV | MOD | SWAP deriving (Show) -- Using imported Parsec.Expr library, build a parser for expressions. expr :: Parser Expression expr = buildExpressionParser table factor <?> "expression" where -- Recognizes a factor in an expression factor = do{ char '(' ; x <- expr ; char ')' ; return x } <|> number <?> "simple expression" -- Recognizes a number number :: Parser Expression number = do{ ds <- many1 digit ; return (Val (read ds)) } <?> "number" -- Specifies operator, associativity, precendence, and constructor to execute -- and built AST with. table = [[prefix "-" (Statement Mult (Val (-1)))], [binary "^" (Statement Pow) AssocRight], [binary "*" (Statement Mult) AssocLeft, binary "/" (Statement Div) AssocLeft, binary "%" (Statement Mod) AssocLeft], [binary "+" (Statement Plus) AssocLeft, binary "-" (Statement Minus) AssocLeft] ] where binary s f assoc = Infix (do{ string s; return f}) assoc prefix s f = Prefix (do{ string s; return f}) -- Parses a string into an AST, using the parser defined above parse s = case P.parse expr "" s of Right ast -> ast Left e -> error $ show e -- Take AST and evaluate (mostly for testing) eval (Val n) = n eval (Statement op left right) | op == Mult = eval left * eval right | op == Minus = eval left - eval right | op == Plus = eval left + eval right | op == Div = eval left `div` eval right | op == Pow = eval left ^ eval right | op == Mod = eval left `mod` eval right -- Takes an AST and turns it into a byte code list generate stmt = generate' stmt [] where generate' (Statement op left right) instr = let li = generate' left instr ri = generate' right instr lri = li ++ ri in case op of Plus -> lri ++ [ADD] Minus -> lri ++ [SUB] Mult -> lri ++ [MUL] Div -> lri ++ [DIV] Mod -> lri ++ [MOD] Pow -> lri ++ [POW] generate' (Val n) instr = if abs(n) > 32768 then LCONST n : instr else CONST n : instr -- Takes a statement and converts it into a list of actual bytes to -- be interpreted compile s = toBytes (generate $ parse s) -- Convert a list of byte codes to a list of integer codes. If LCONST or CONST -- instruction are seen, correct byte representantion is produced toBytes ((NOOP):xs) = 0 : toBytes xs toBytes ((CONST n):xs) = 1 : (toConstBytes (fromInteger n)) ++ toBytes xs toBytes ((LCONST n):xs) = 2 : (toLConstBytes (fromInteger n)) ++ toBytes xs toBytes ((ADD):xs) = 0x0a : toBytes xs toBytes ((SUB):xs) = 0x0b : toBytes xs toBytes ((MUL):xs) = 0x0c : toBytes xs toBytes ((POW):xs) = 0x0d : toBytes xs toBytes ((DIV):xs) = 0x0e : toBytes xs toBytes ((MOD):xs) = 0x0f : toBytes xs toBytes ((SWAP):xs) = 0x0a : toBytes xs toBytes [] = [] -- Convert number to CONST representation (2 element list) toConstBytes n = toByteList 2 n toLConstBytes n = toByteList 4 n -- Convert a number into a list of 8-bit bytes (big-endian/network byte order). -- Make sure final list is size elements long toByteList :: Bits Int => Int -> Int -> [Int] toByteList size n = reverse $ take size (toByteList' n) where toByteList' a = (a .&. 255) : toByteList' (a `shiftR` 8) -- All tests defined by the quiz, with the associated values they should evaluate to. test1 = [(2+2, "2+2"), (2-2, "2-2"), (2*2, "2*2"), (2^2, "2^2"), (2 `div` 2, "2/2"), (2 `mod` 2, "2%2"), (3 `mod` 2, "3%2")] test2 = [(2+2+2, "2+2+2"), (2-2-2, "2-2-2"), (2*2*2, "2*2*2"), (2^2^2, "2^2^2"), (4 `div` 2 `div` 2, "4/2/2"), (7`mod`2`mod`1, "7%2%1")] test3 = [(2+2-2, "2+2-2"), (2-2+2, "2-2+2"), (2*2+2, "2*2+2"), (2^2+2, "2^2+2"), (4 `div` 2+2, "4/2+2"), (7`mod`2+1, "7%2+1")] test4 = [(2+(2-2), "2+(2-2)"), (2-(2+2), "2-(2+2)"), (2+(2*2), "2+(2*2)"), (2*(2+2), "2*(2+2)"), (2^(2+2), "2^(2+2)"), (4 `div` (2+2), "4/(2+2)"), (7`mod`(2+1), "7%(2+1)")] test5 = [(-2+(2-2), "-2+(2-2)"), (2-(-2+2), "2-(-2+2)"), (2+(2 * -2), "2+(2*-2)")] test6 = [((3 `div` 3)+(8-2), "(3/3)+(8-2)"), ((1+3) `div` (2 `div` 2)*(10-8), "(1+3)/(2/2)*(10-8)"), ((1*3)*4*(5*6), "(1*3)*4*(5*6)"), ((10`mod`3)*(2+2), "(10%3)*(2+2)"), (2^(2+(3 `div` 2)^2), "2^(2+(3/2)^2)"), ((10 `div` (2+3)*4), "(10/(2+3)*4)"), (5+((5*4)`mod`(2+1)), "5+((5*4)%(2+1))")] -- Evaluates the tests and makes sure the expressions match the expected values eval_tests = concat $ map eval_tests [test1, test2, test3, test4, test5, test6] where eval_tests ((val, stmt):ts) = let eval_val = eval $ parse stmt in if val == eval_val then ("Passed: " ++ stmt) : eval_tests ts else ("Failed: " ++ stmt ++ "(" ++ show eval_val ++ ")") : eval_tests ts eval_tests [] = [] -- Takes all the tests and displays symbolic bytes codes for each generate_tests = concat $ map generate_all [test1,test2,test3,test4,test5,test6] where generate_all ((val, stmt):ts) = (stmt, generate (parse stmt)) : generate_all ts generate_all [] = [] -- Takes all tests and generates a list of bytes representing them compile_tests = concat $ map compile_all [test1,test2,test3,test4,test5,test6] where compile_all ((val, stmt):ts) = (stmt, compile stmt) : compile_all ts compile_all [] = [] interpret_tests = concat $ map f' [test1, test2, test3, test4, test5, test6] where f' tests = map f'' tests f'' (expected, stmt) = let value = fromIntegral $ interpret [] $ compile stmt in if value == expected then "Passed: " ++ stmt else "Failed: " ++ stmt ++ "(" ++ (show value) ++ ")" fromBytes n xs = let int16 = (fromIntegral ((fromIntegral int32) :: Int16)) :: Int int32 = byte xs byte xs = foldl (\accum byte -> (accum `shiftL` 8) .|. (byte)) (head xs) (take (n - 1) (tail xs)) in if n == 2 then int16 else int32 interpret [] [] = error "no result produced" interpret (s1:s) [] = s1 interpret s (o:xs) | o < 10 = interpret ((fromBytes (o*2) xs):s) (drop (o*2) xs) interpret (s1:s2:s) (o:xs) | o == 16 = interpret (s2:s1:s) xs | otherwise = interpret (((case o of 10 -> (+); 11 -> (-); 12 -> (*); 13 -> (^); 14 -> div; 15 -> mod) s2 s1):s) xs \end{code}

3 5

Re: [Haskell-cafe] don't: a 'do' for comonads?
by dons＠cse.unsw.edu.au 10 Nov '06

10 Nov '06

hjgtuyl: > > don't :: whatever -> > > (whatever goes in, nothing comes out) So its: don't :: a -> Void ? -- Don

1 0

don't: a 'do' for comonads?
by dons＠cse.unsw.edu.au 10 Nov '06

10 Nov '06

As seen on #haskell, from an idea by Malcolm, 14:42 ?let top'n'tail = ("<pre>"++) . (++"</pre>") 14:42 lambdabot> Defined. 14:43 dons> > L.top'n'tail "foo me now" 14:43 lambdabot> "<pre>foo me now</pre>" 14:43 mauke> that reminds me, haskell needs don't 14:43 dons> yes! 14:44 pkhuong-> mm. the opposite of do, eh? do for comonads? :) So now a prize to the person who comes up with the best use for the identifier: don't :: ? -- Don

3 3

string to date?
by Magnus Therning 10 Nov '06

10 Nov '06

I've been staring my eyes out trying to find a function that converts a string into a ClockTime or CalendarTime. Basically something like C's strptime(3). I can't seem to find anything like it in System.Time, there are function that convert _to_ a string, but nothing that converts _from_ a string it seems. Where should I look? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus(a)therning.org Jabber: magnus.therning(a)gmail.com http://therning.org/magnus Software is not manufactured, it is something you write and publish. Keep Europe free from software patents, we do not want censorship by patent law on written works. Finagle's Sixth Law: Don't believe in miracles -- rely on them.

5 5

Sistema de Ecuaciones NO lineales
by Sebastian Gaviria 10 Nov '06

10 Nov '06

hola como estan!!!! Quiero preguntar quien puede resolver el sistemas de ecuaciones NO lineales de Newton y el codigo de Jacobi en Haskell me ayudarian mucho al poder implementar ese codigo por Favor es con urgencia tener estos codigos!! muchas gracias !!! -- "La sociedad debe juzgarse por su capacidad para hacer que la gente sea feliz."" SEBASTIAN GAVIRIA J. INGENIERIA SISTEMAS UNIVERSIDAD EAFIT

4 3

Newbie Q: composeMaybe :: (a -> Maybe b) -> (b -> Maybe c) -> (a -> Maybe c)
by Dmitri O.Kondratiev 09 Nov '06

09 Nov '06

I am trying to solve a problem from "The Craft of Functional Programming" book: 14.38 ... define the function: data Maybe a = Nothing | Just a composeMaybe :: (a -> Maybe b) -> (b -> Maybe c) -> (a -> Maybe c) using functions: squashMaybe :: Maybe (Maybe a) -> Maybe a squashMaybe (Just (Just x)) = Just x squashMaybe _ = Nothing mapMaybe :: (a -> b) -> Maybe a -> Maybe b mapMaybe f Nothing = Nothing mapMaybe f (Just x) = Just (f x) As a first step to the solution I defined auxilary function: f1 f g x = mapMaybe f (g x) GHCi gives the following type for this function: f1 :: (a -> b) -> (t -> Maybe a) -> t -> Maybe b ^^^ Q: I don't quite understand this signature. I would expect this instead (by mapMaybe definition): f1 :: (a -> b) -> (t -> Maybe a) -> Maybe b >From where does the second 't' come from? What are the arguments and what f1 returns in this case?

2 2

StateT and modify
by Peter Steiner 09 Nov '06

09 Nov '06

hi haskellers, i have a basic question regarding StateT encapsulating IO and the modify function. my scenario is similar to the following simple code snippet: > import Control.Monad.State > > type MyState = StateT Int IO > > test = evalStateT foo 0 > > foo = do > modify $ (+) 1 > get i would like to be able to debug what's happening inside the modifier function. that's why i want to be able to use a modifier that's in the IO monad, like in the following, obviously defunct snippet: > test = evalStateT bar 0 > > bar = do > modify $ myAdd 1 > get > > myAdd :: Int -> Int -> IO Int > myAdd x y = do > putStr "in myAdd\n" > return $ x + y this fails because (myAdd :: Int -> Int -> IO Int) does not match the required modify argument type (Int -> Int -> Int) for MyState. Couldn't match expected type `Int' against inferred type `IO Int' In the second argument of `($)', namely `myAdd 1' In the expression: modify $ (myAdd 1) In a 'do' expression: modify $ (myAdd 1) is it possible to 'lift' StateT modify into the inner monad (IO in my case)? regards, peter.

5 9

How to design default implementations of type class methods?
by Henning Thielemann 09 Nov '06

09 Nov '06

I like to hear some opinions about how to implement class method defaults. Let's consider the following example: I want to classify types which allow for computation of the greatest common divisor. The greatest common divisor can be computed by Euclid's algorithm in some cases (integers, univariate polynomials) but not in all cases (integer matrices, multivariate polynomials). So maybe it's a good idea to set the Euclidean algorithm as default implementation for the GCD method. Say, I have already implemented both the normal Euclidean algorithm as "euclid", which only emits the GCD, and the extended Euclidean algorithm "extendedEuclid" which also determines a and b in "gcd(x,y) = a*x + b*y" for given x and y. Now I have two choices for implementing default methods: 1. Implement a method by calling other methods of the same class. class (Units a) => PID a where extendedGCD :: a -> a -> (a,a,a) extendedGCD = extendedEuclid divMod gcd :: a -> a -> a gcd x y = let (g,_,_) = extendedGCD x y in g Advantage: User must implement only few methods, here extendedGCD, the other ones work automatically. Disadvantage: User must know, how the default methods call each other, in order to not introduce cycles. 2. Implement a method by calling custom code, preferably a public function according to http://www.haskell.org/haskellwiki/Slim_instance_declaration class (Units a) => PID a where extendedGCD :: a -> a -> (a,a,a) extendedGCD = extendedEuclid divMod gcd :: a -> a -> a gcd = euclid mod Advantages/Disadvantages are negated with respect to the first item. :-) Ok, this example class is not well chosen, because in the case of multivariate polynomials, not only extended Euclidean algorithm fails, but it is in many cases not possible to represent the GCD of x and y as a linear combination of x and y. My question is not limited to this case: I want to know, what reasons exist pro and cons each alternative. Currently I prefer the first way, because it reduces the work of implementing instances to the things that are essential for the particular type. People who want specialized and more efficient methods, must implement all methods.

3 2

Re: ANN: System.FilePath 0.10
by Ashley Yakeley 09 Nov '06

09 Nov '06

Neil Mitchell wrote: > I am hereby announcing System.FilePath 0.10, which hopefully is pretty > close to final now. This library manipulates FilePath's correctly on > both Posix and Windows. How do I manipulate a Windows file path on a POSIX machine (something relating to Samba, for instance)? -- Ashley Yakeley

2 1

Re: Fractional/negative fixity?
by Robert Dockins 08 Nov '06

08 Nov '06

On Nov 8, 2006, at 3:58 AM, apfelmus(a)quantentunnel.de wrote: > Lennart Augustsson wrote: >> >> On Nov 7, 2006, at 11:47 , >> apfelmus(a)quantentunnel.de wrote: >> >>> Henning Thielemann wrote: >>>> On Tue, 7 Nov 2006, Simon Marlow wrote: >>>> >>>>> I'd support fractional and negative fixity. It's a simple >>>>> change to >>>>> make, but we also have to adopt >> [...] >>> >>> I think that computable real fixity levels are useful, too. A >>> further >>> step to complex numbers is not advised because those cannot be >>> ordered. >> >> But ordering of the computable reals is not computable. So it could >> cause the compiler to loop during parsing. :) > > Actually, that's one of the use cases ;) A turing-complete type-checker isn't enough! Our work is not complete until the parser is a universal machine as well! > Regards, > apfelmus Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

1 0