Re: [Haskell-cafe] Graph theory analysis of Haskell code
Tim Chevalier [EMAIL PROTECTED] writes: aka a call graph. This is called control flow analysis and the classic paper on it is Olin Shivers' dissertation This is very well-trodden ground, but if you familiarize yourself with the literature on the subject, then who knows, you may discover something new. I'll just add that having a tool visualizing this would be very useful for refactoring code. If you e.g. use color to distinguish nodes/functions from different modules, you could use that information to decide to merge or split modules to minimize external interfaces. You could also try to automatically cluster nodes, which would be more interesting theoretically, but IMO less likely to be practical. Another option would be to couple this with profiling or coverage information to visualize something about the usage of paths and nodes in the call graph. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc overlapping instances - solved
Hello,
Isaac, this works for me.
Thx a lot,
Steffen
2007/12/5, Isaac Dupree [EMAIL PROTECTED]:
Steffen Mazanek wrote:
Hi,
Stefan and Isaac, thx for providing quick advice.
@Stefan: Unfortunately I have to use a list.
@Isaac: I do not get it. Could you please provide a short example of
your
approach?
The question still remains. Which arguments do I have ghc to start with
to
get the same behavior than hugs with -98 +o (here it works).
I provide my example for testing purposes:
module Test where
import Test.QuickCheck
import Monad(liftM,liftM2)
type Program = [Stmt]
data Stmt = Text | IfElse Program Program | While Program deriving (Eq,
Show)
instance Arbitrary [Stmt] where
arbitrary = sized genProg
instance Arbitrary Stmt where
arbitrary = sized genStmt
genStmt::Int-Gen Stmt
genStmt 0 = return Text
genStmt 1 = return Text
genStmt 2 = oneof [return Text, return (While [Text])]
genStmt n | n2 = oneof ([return Text,
liftM While (genProg (n-1))]++
[liftM2 IfElse (genProg k) (genProg
(n-k-1))|k-[1..n-2]])
genProg::Int-Gen Program
genProg 0 = return []
genProg 1 = return [Text]
genProg n | n1 = oneof ((liftM (\x-[x]) (genStmt n)):[liftM2 (:)
(genStmt
k) (genProg (n-k))|k-[1..n-1]])
prop_ConstructParse progr = True
where types = progr::Program
main = mapM_ (\(s,a) - putStrLn s a) [(flowchart construct and
parse,
test prop_ConstructParse)]
is prop_ConstructParse the only thing that breaks when you remove the
instance Arbitrary [Stmt] where arbitrary = sized genProg, or have I
missed something? If that's all, try this (untested) :
prop_ConstructParse = forAll (sized genProg) (\progr - True)
and similarly for other properties.
Or, you _can_ use a newtype for quickcheck-only, something like this:
newtype P = P { unP :: Program }
instance Show P where show = show . unP
instance Arbitrary P where arbitrary = sized genProg . unP
prop_ConstructParse (P progr) = True
Isaac
--
Dipl.-Inform. Steffen Mazanek
Institut für Softwaretechnologie
Fakultät Informatik
Universität der Bundeswehr München
85577 Neubiberg
Tel: +49 (0)89 6004-2505
Fax: +49 (0)89 6004-4447
E-Mail: [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Nested guards?
[redirecting to Haskell Cafe] | It is clear that this situation must not stay this way. Bit by bit, | disciples of Perl and Python discover Haskell and demand that Haskell will | be plastered with syntactic sugar until the simplicity of the functional | approach isn’t visible anymore. Sadly, they seem to be successful with this | as syntax extensions like parallel list comprehensions show. I think it is helpful to distinguish superficial complexity from deep complexity. All of Haskell's syntactic sugar is just that: it can be translated into a small purely-functional language using straightforward translation schemes. Even something relatively complicated like the order by/group by extension that Phil and I proposed at this year's Haskell workshop, has an easy translation that takes a dozen or two lines to give in full detail. In contrast, something like higher order functions, or mutable state, is deep complexity. Both have a pervasive effect on the language semantics and on its implementation. (The effect of mutable state is much, much worse, but they are both deep.) Concerning Haskell, I'm quite relaxed about superficial complexity, as you'll have seen from what happens in GHC. Section 3.6 of the History of Haskell paper addresses this point specifically [1]. You may disagree with the choice made by the Haskell committee at the time, and with subsequent developments, but it was quite a conscious choice, and one not without its advantages. Simon [1] http://research.microsoft.com/%7Esimonpj/papers/history-of-haskell/history.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] IVar
Jan-Willem Maessen wrote: On Dec 5, 2007, at 3:58 AM, Simon Marlow wrote: Ah, so I was thinking of the following readIVar: readIVar = unsafePerformIO . readIVarIO But clearly there's a better one. Fair enough. Hmm, so unsafePerformIO doesn't deal with any operation that blocks? Well, operations that block inside unsafePerformIO do block the whole thread, yes, and that may lead to a deadlock if the blocking operation is waiting to be unblocked by its own thread. It sounds like you want to back off from any earlier-than-necessary evaluation at this point. Fortunately this problem doesn't arise, because GHC won't commute evaluation past an IO operation. I'm wondering about related sorts of examples now, as well: do x - newIVar y - unsafeInterleaveIO (readIVarIO x) writeIVar x 3 print y Or the equivalent things to the above with MVars. Yes, this suffers from the same problem. If the compiler were to eagerly evaluate y, then you'll get deadlock. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is this strict in its arguments?
Use of isNothing and fromJust and a cascade of ifs is generally a poor sign, much better to use case: findAllPath pred (Branch lf r rt) | pred r = case (findAllPath pred lf,findAllPath pred rt) of (Nothing,Nothing) - Nothing (Nothing,Just rtpaths) - Just (map (r:) rtpaths) (Just lfpaths,Nothing) - Just (map (r:) lfpaths) (Just lfpaths,Just rtpaths) - Just (map (r:) $ rtpaths ++ lfpaths) | otherwise = Nothing the general pattern is : replace isNothing with a case match on Nothing, replace fromJust with a case match on Just, don't be afraid to case two expressions at once. Nested Maybe cases put me in mind of the Maybe monad. Although in this case it''s not trivial; we also need to involve the Maybe [a] instance of Data.Monoid too (for the mappend function). I do wonder if I'm abusing the monadic instances of Maybe though; is this really any clearer than Jules' code? (BTW, this has probably come up before, but wouldn't it be a little bit nicer if when returned mzero rather than () in the do nothing case?) when' :: MonadPlus m = Bool - m a - m a when' pred action = if pred then action else mzero findAllPath :: (a - Bool) - (BTree a) - Maybe [[a]] findAllPath pred (Leaf l) = when' (pred l) (return [[l]]) findAllPath pred (Branch lf r rt) = when' (pred r) $ do x - mappend (findAllPath pred lf) (findAllPath pred rt) return (map (r:) x) Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Looking for largest power of 2 = Integer
| (2) Is it safe to assume an underlying implementation based on GMP? | (In Num.lhs there is an alternative definition for .NET. Is that ever | used?) Is it safe to assume the size of a GMP limb is the same as | the word size? (I'm assuming it is for now.) I think it's safe for now. In principle the impl of Integer could be anything, and various people would like it to be something other than gmp for licensing reasons. But as of today, it's always gmp. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Looking for largest power of 2 = Integer
Dan Piponi wrote: There's a bit of work required to make this code good enough for general consumption, and I don't know much about Haskell internals. (1) What is the official way to find the size of a word? A quick look at 6.8.1's base/GHC/Num.lhs reveals that it uses a #defined symbol. I'm not 100% sure what you mean by word in this context, but assuming you mean the same thing as we do in GHC when we say word (a pointer-sized integral type), then one way is Foreign.sizeOf (undefined :: Int) or Foreign.sizeOf (undefined :: Ptr ()) (in GHC these are guaranteed to be the same). There's also Data.Bits.bitSize (undefined :: Int) which might be more appropriate since you're using Data.Bits anyway. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is this strict in its arguments?
On Dec 6, 2007 9:30 AM, Alistair Bayley [EMAIL PROTECTED] wrote: Use of isNothing and fromJust and a cascade of ifs is generally a poor sign, much better to use case: findAllPath pred (Branch lf r rt) | pred r = case (findAllPath pred lf,findAllPath pred rt) of (Nothing,Nothing) - Nothing (Nothing,Just rtpaths) - Just (map (r:) rtpaths) (Just lfpaths,Nothing) - Just (map (r:) lfpaths) (Just lfpaths,Just rtpaths) - Just (map (r:) $ rtpaths ++ lfpaths) | otherwise = Nothing the general pattern is : replace isNothing with a case match on Nothing, replace fromJust with a case match on Just, don't be afraid to case two expressions at once. I have actually seen this pattern a lot recently. Recently I have started using a function: mergeMaybes :: (a - a - a) - Maybe a - Maybe a - Maybe a mergeMaybes f Nothing y = y mergeMaybes f x Nothing = x mergeMaybes f (Just x) (Just y) = Just (f x y) With which findAllPath could be written: finaAllPath pred (Branch lf r rt) | pred r= fmap (map (r:)) $ mergeMaybes (++) (findAllPath lf) (findAllPath rt) | otherwise = Nothing Or this more search-like feel: findAllPath pred (Branch lf r rt) = do guard (pred r) subpaths - mergeMaybes (++) (findAllPath lf) (findAllPath rt) return $ map (r:) subpaths Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: C Preprocessor
Bernd Brassel wrote: Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations? Yes, it is: http://hackage.haskell.org/trac/hackage/ticket/146 I ran into it lately. I was totally unaware of what caused GHC's parse error on a valid line until someone on the IRC channel pointed it out. According to the ticket, cpphs (a Haskell-oriented CPP replacement) does get it right. Regards, Reinier ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is this strict in its arguments?
Alistair Bayley wrote: Nested Maybe cases put me in mind of the Maybe monad. Although in this case it''s not trivial; we also need to involve the Maybe [a] instance of Data.Monoid too (for the mappend function). I do wonder if I'm abusing the monadic instances of Maybe though; is this really any clearer than Jules' code? I think the 'right' answer for this case is to drop the maybes and just use lists, which is what the OP himself realised. I often find that if I think I want a Monoid instance for Maybe [a], what I really want is to just use [a]. (Not always of course...). (BTW, this has probably come up before, but wouldn't it be a little bit nicer if when returned mzero rather than () in the do nothing case?) Yes and no. I've wanted your when' once or twice, but the return () version is useful too... Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: C Preprocessor
Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations? Yes, it is: According to the ticket, cpphs (a Haskell-oriented CPP replacement) does get it right. http://www.cs.york.ac.uk/fp/cpphs After installing, give ghc the options -cpp -pgmPcpphs -optP--cpp. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Nested guards?
Am Donnerstag, 6. Dezember 2007 10:03 schrieb Simon Peyton Jones: [redirecting to Haskell Cafe] | It is clear that this situation must not stay this way. Bit by bit, | disciples of Perl and Python discover Haskell and demand that Haskell | will be plastered with syntactic sugar until the simplicity of the | functional approach isn’t visible anymore. Sadly, they seem to be | successful with this as syntax extensions like parallel list | comprehensions show. I think it is helpful to distinguish superficial complexity from deep complexity. All of Haskell's syntactic sugar is just that: it can be translated into a small purely-functional language using straightforward translation schemes. Even something relatively complicated like the order by/group by extension that Phil and I proposed at this year's Haskell workshop, has an easy translation that takes a dozen or two lines to give in full detail. In contrast, something like higher order functions, or mutable state, is deep complexity. Both have a pervasive effect on the language semantics and on its implementation. (The effect of mutable state is much, much worse, but they are both deep.) The point is that higher order functions, type classes, etc. enable you to “extend the language yourself” to a large degree by just creating libraries. Such powerful concepts give you the ability to create domain specific languages by just writing Haskell code. So they serve the approach of having few concepts in the language which allow you to do many things. On the other hand, syntactic sugar often deals with very special cases. Guards are sugar for case distinction on just a single type (Bool), list comprehensions deal with specific operations (map, filter, etc.) of a specific type ([]). Parallel list comprehensions even sugar a function which is somehow broken in a language without dependent types (zip; because of the ad-hoc solution for zipping lists of different length). In my opinion, syntactic sugar is good if it is about more general things. do and proc expressions are really useful but they don’t deal with specific types but with whole classes of types which are rather large. The ability to define infix operators is really helpful, especially for creating DSLs. (Johannes Waldmann has a different opinion here.) Concerning Haskell, I'm quite relaxed about superficial complexity, as you'll have seen from what happens in GHC. Yes, I have seen what happens in GHC and it makes me very sad. I think, since you are a GHC developer, you have a different perspective. You can modify the compiler to provide language extensions. People like me cannot do this. And I think that the solution is not to make the language larger and larger everytime someone wants a feature but to give people the tools to provide features without language changes. Section 3.6 of the History of Haskell paper addresses this point specifically […]. I want to cite the first paragraph: A major source of tension both within and between members of the committee was the competition between beauty and utility. On the one hand we passionately wanted to design a simple, elegant language […] On the other hand, we also really wanted Haskell to be a useful language, for both teaching and real applications. This reasoning is really flawed, in my opinion. The claim is that a language without all kinds of syntactic sugar wouldn’t be useful, especially not for real applications. I claim that I’m writing really useful code in Haskell and I find myself not using many kinds of syntactic sugar. Not because I just have an opinion that syntactic sugar is bad but because I feel that my style of coding is sensible. I never consciously decided against syntactic sugar. My low-sugar style just emerged automatically over the years. As I already said, I definitely want do expressions, proc expressions and definable infix operators. However, I seldomly use where clauses. List comprehensions are more or less absent from my code and I’m even not interested in getting to know how pattern guards and parallel list comprehensions work in detail. And I don’t want to write SQL-like code in Haskell using the order-by/group-by extension. You may disagree with the choice made by the Haskell committee at the time, and with subsequent developments, but it was quite a conscious choice, and one not without its advantages. The choice of the Haskell committee might be okay, the subsequent developments in GHC are problematic, in my opinion. Simon Side note: I hope you can cope with my direct style of writing. After all, I’m just an unfriendly German. ;-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is this strict in its arguments?
Jules Bean wrote: I think the 'right' answer for this case is to drop the maybes and just use lists, which is what the OP himself realised. Yes, part of the fun of programming is when you realize that you have been re-implementing the right data type inside of a wrong one. Alistair Bayley wrote: (BTW, this has probably come up before, but wouldn't it be a little bit nicer if when returned mzero rather than () in the do nothing case?) No. We already have both of those: when pred action guard pred action -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type class question
Yes, the recursive calls of compCommand are supposed to be calls of compBlock. The intention of the program is a generic evaluator comp... of Sigma-terms in arbitrary Sigma-algebras. The signature Sigma is given by the first 4 types (and the corresponding functions in the class declaration), the terms are the objects of the types, and the algebras are the class instances. The problem with my implementation in terms of multiple-parameter classes seems to be - I conclude this from Ryan's comment - that the intended dependency among the parameters is not reflected here. But what are the alternatives? Roughly said, I need a construct that allows me gather several type variables such that an instance is always an instance of all of them. On Dec 3, 2007 7:43 AM, Peter Padawitz [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: What is wrong here? ghci tries (and fails) to deduce certain types for the comp functions that I did not expect. |type Block = [Command] data Command = Skip | Assign String IntE | Cond BoolE Block Block | Loop BoolE Block data IntE= IntE Int | Var String | Sub IntE IntE | Sum [IntE] | Prod [IntE] data BoolE = BoolE Bool | Greater IntE IntE | Not BoolE class Java block command intE boolE where block_ :: [command] - block skip :: command assign :: String - intE - command cond :: boolE - block - block - command loop :: boolE - block - command intE_ :: Int - intE var :: String - intE sub :: intE - intE - intE sum_ :: [intE] - intE prod :: [intE] - intE boolE_ :: Bool - boolE greater :: intE - intE - boolE not_ :: boolE - boolE compBlock :: Block - block compBlock = block_ . map compCommand compCommand :: Command - command compCommand Skip = skip compCommand (Assign x e) = assign x (compIntE e) compCommand (Cond be c c') = cond (compBoolE be) (compCommand c) (compCommand c') compCommand (Loop be c)= loop (compBoolE be) (compCommand c)-} compIntE :: IntE - intE compIntE (IntE i) = intE_ i compIntE (Var x)= var x compIntE (Sub e e') = sub (compIntE e) (compIntE e') compIntE (Sum es) = sum_ (map compIntE es) compIntE (Prod es) = prod (map compIntE es) compBoolE :: BoolE - boolE compBoolE (BoolE b) = boolE_ b compBoolE (Greater e e') = greater (compIntE e) (compIntE e') compBoolE (Not be) = not_ (compBoolE be) | Well, first of all, the definition of compCommand should use calls to compBlock, not recursive calls to compCommand. But that's not the main source of your problems. What exactly are you trying to accomplish? And why do you need a type class? -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: About -Wall option
Luis Cabellos wrote: I have a question, what's the best way to program? - put all the signatures in the Haskell Code? - Only put the type signatures needed to compile (like monomorphism errors or ambiguous signature)? Wolfgang Jeltsch wrote: Inserting all type signatures is definitely best practice. (Moving to the cafe from ghc-users...) My personal style is: o Put signatures on everything at the top-level o Inside let and where, only where necessary, BUT: Inside let and where, I try to make sure that every function I define there is such that I would never want to call it separately in ghci/hugs while debugging, or in a unit test. Besides making testing and debugging easier, that rule forces the overall structure of every function to be simple and easy to read. In that case, type signatures just clutter the code and make it less readable. Conversely, if the relationship between the type of the let/where function and the type of the outer function is complex and not obvious, I will likely need to test that function. So it will go into a separate top-level function with a type signature. (I don't think this style creates any problems in Cabal.) -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HOgg 0.3.0 Released
HOgg 0.3.0 Released --- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. HOgg is in hackage, or on the web at: http://www.kfish.org/~conrad/software/hogg/ This is the second public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on par with those of the oggz* [0] tools. Although hogg does not yet provide an equivalent to oggz-validate, it has subcommands for chopping out a section of a file, and for adding skeleton metadata. HOgg supports chained and multiplexed Ogg bitstreams conformant with RFC3533[1]. HOgg can parse headers for CMML, FLAC, OggPCM, Speex, Theora and Vorbis media codecs, and can read and write Ogg Skeleton bitstreams. [0] Oggz: http://www.annodex.net/software/liboggz/index.html [1] RFC3533: http://www.ietf.org/rfc/rfc3533.txt New in this release --- The hogg tool contains new subcommands: chop, addskel and list-codecs. Additionally, subcommands for inspecting streams (hogg dump, hogg pagedump) can now take start and end time options. $ hogg help chop chop: Extract a section (specify start and/or end time) Usage: hogg chop [options] filename ... Examples: Extract the first minute of file.ogg: hogg chop -e 1:00 file.ogg Extract from the second to the fifth minute of file.ogg: hogg chop -s 2:00 -e 5:00 -o output.ogg file.ogg Extract only the Theora video stream, from 02:00 to 05:00, of file.ogg: hogg chop -c theora -s 2:00 -e 5:00 -o output.ogg file.ogg Extract, specifying SMPTE-25 frame offsets: hogg chop -c theora -s smpte-25:00:02:03::12 -e smpte-25:00:05:02::04 -o output.ogg file.ogg Options: -h, -? --help Display this help and exit -V --versionOutput version information and exit -c Content-Type --content-type=Content-Type Select the logical bitstreams for a specified content type -s Timestamp --start=TimestampSpecify a start time -e Timestamp --end=Timestamp Specify an end time -o filename --output=filenameSpecify output filename Additionally, the HOgg package now contains support for building with GHC version 6.8, and the Codec.Container.Ogg library contains various internal improvements. Installation I am very interested in hearing about problems with building or installing the package, particularly from people who are not yet familiar with building from Haskell source. You need ghc instead of gcc; it compiles to a binary: $ ./Setup.hs configure $ ./Setup.hs build $ sudo ./Setup.hs install Building of this release has been tested with: * GHC versions 6.4, 6.6 and 6.8.1 [2] * The Haskell build system Cabal versions 1.1.3, 1.1.4, 1.1.6, and the current development trunk. [3] The GHC and Cabal versions listed above span the packages available in most current distributions. I've tested on Debian unstable and Ubuntu Feisty. I'm particularly interested to hear reports of build success or failure on other distributions or operating systems. [2] GHC: http://www.haskell.org/ghc/ [3] Cabal: http://www.haskell.org/cabal/ Usage - $ hogg help Usage: hogg subcommand [options] filename ... Commands: help Display help for a specific subcommand (eg. hogg help chop) Reporting: info Display information about the file and its bitstreams dump Hexdump packets of an Ogg file pagedump Display page structure of an Ogg file dumpraw Dump raw (unparsed) page data Extraction: rip Rip selected logical bistreams from an Ogg file (default: all) reconstruct Reconstruct an Ogg file by doing a full packet demux Editing: chop Extract a section (specify start and/or end time) merge Merge, interleaving pages in order of presentation time addskel Write a Skeleton logical bitstream Miscellaneous: known-codecs List codecs known by this version of hogg Please report bugs to [EMAIL PROTECTED] Source -- Source code is available from the darcs repository at: darcs get http://www.kfish.org/~conrad/software/hogg/ cheers, Conrad. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Clean Dynamics and serializing code to disk
if you want to make something like this for haskell (and i'd very much like to use it!-), there are several issues, including: 1 handling code: - going for a portable intermediate representation, such as bytecode, is most promising, especially if the code representation is fairly stable (if you're worried about performance, choose a representation that can be compiled further by the backend on the target machine) - shipping the code objects, and serializing only pointers into those, then linking into the objects dynamically on load, can work if platform and compiler (ghc versions aren't abi-compatible) don't change 2 handling types: - 'out e' needs a runtime representation of the static type of e; - 'e - in' needs to compare e's type representation at runtime against the static type expected by the usage context - types evolve, type representations evolve - haskell's Dynamic doesn't handle polymorphic types, and its type representations are not standardised, so they can change even if the types do not (there's no guarantee that reading an expression written by another program will work) - doing a proper integration of Dynamic raises other issues wrt interactions with other type system features (see the Clean papers for examples) or wrt parametricity (if any type can be wrapped in/extracted from a Dynamic, can you now have type-selective functions of type 'a-a'?) 3 handlings graphs: in a typical functional language implementation, there are several parts that need to do this already, although they tend to be specialised to their intended use, so they might not cover all needs for general serialization - a distributed implementation needs to ship graphs to other nodes (but often ships code in a separate setup phase..) - the memory manager needs to move graphs between memory areas (but often does not touch code at all) graph representations evolve, so if you can reuse code from one of the existing parts here, that will save you not only initial time but, more importantly, avoid a maintenance nightmare. 4 surviving evolution: if you got all of that working, the more interesting issues start popping up - implementations move on, can your code keep up? - programs move on, can your system handle versions? - the distinction between static/dynamic has suddenly become rather blurry, raising lots of interesting opportunities, but also pointing out limitations of tools that rely on a fixed single compile-time/ runtime cycle many of those issues were investigated long ago, in the area of orthogonally persistent systems (including types and first-class procedures), see a thread from earlier this year for a few references: http://www.haskell.org/pipermail/haskell-cafe/2007-June/027162.html non-trivial, but doable - you'd probably spend a lot more time thinking, investigating current code, prototyping options, and sorting out issues, than on the final implementation. it is the kind of problem where you either spend a lot of time preparing an overnight success, or you start hacking right away and never get anywhere!-) claus ps: i implemented first-class i/o for a pre-haskell functional language (long gone now) - i experimented with dynamic linking of object code, but went with byte code, didn't have to struggle with types, because the language had runtime types and checking anyway, and was able to reuse code from the distributed implementation for storage/retrieval. and saw only the very early stages of 4;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph theory analysis of Haskell code
On Thu, Dec 06, 2007 at 09:34:30AM +0100, Ketil Malde wrote: Tim Chevalier [EMAIL PROTECTED] writes: This is very well-trodden ground, but if you familiarize yourself with the literature on the subject, then who knows, you may discover something new. I'll just add that having a tool visualizing this would be very useful for refactoring code. If you e.g. use color to distinguish nodes/functions from different modules, you could use that information to decide to merge or split modules to minimize external interfaces. You could also try to automatically cluster nodes, which would be more interesting theoretically, but IMO less likely to be practical. Another option would be to couple this with profiling or coverage information to visualize something about the usage of paths and nodes in the call graph. Indeed, a visualization tool like this would be cool! -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph theory analysis of Haskell code
This sounds like a fun project and it is certainly feasible to do. I thought I'd give you some pointers to fun stuff that people have been doing in the past. Thomas Reps have been doing program analysis since the dawn of time, but one paper that seems particularly related to what you try to do is Identifying modules via concept analysis. You can find that and the rest of his papers on his homepage: http://pages.cs.wisc.edu/~reps/ There are many different characteristics of a program graph that can be of interest. One that has recently given rise to some interesting results is the notion of tree width. An example of it's is the following paper:http://citeseer.ist.psu.edu/601409.html Have fun, Josef On Dec 6, 2007 12:46 AM, Ivan Miljenovic [EMAIL PROTECTED] wrote: This isn't strictly Haskell related, but anyway. Next year I will be doing my honours in mathematics. One possible topic for my thesis that I've thought of - and my supervisor is quite enthused about - is to use graph theory to analyse various textual sources, starting with source code but leaving the framework open enough to be able to extend it to other sources (e.g. email address books). How I envisage it happening is that a parser would be used to find all functions in the given code, treat these as nodes in the graph and then use directed edges to indicate which functions call other functions. This resultant graph can then be analysed in various ways suitable to the context (e.g. find that a library module can be split into two since there are two completely separate trees present in the graph that don't interact at all, or if a function is only ever called by one other function then it can be subsumed into it). So, here is the question I ask of all of you: is this feasible? Do you know if anything like this has ever been attempted before? I know there are some other usages of graph theory related to source code (e.g. McCabes complexity metric [1]), but I couldn't seem to find anything related to what I'm proposing. I intend to code this up in Haskell (possibly using FGL: I know of it, but haven't really looked at it) and use Haskell as my primary target for analysis, so in a sense the resultant graph could be seen as a Haskell equivalent to UML. [1] http://en.wikipedia.org/wiki/Cyclomatic_complexity -- Ivan Lazar Miljenovic ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type class question
Peter Padawitz wrote: Yes, the recursive calls of compCommand are supposed to be calls of compBlock. The intention of the program is a generic evaluator comp... of Sigma-terms in arbitrary Sigma-algebras. The signature Sigma is given by the first 4 types (and the corresponding functions in the class declaration), the terms are the objects of the types, and the algebras are the class instances. The problem with my implementation in terms of multiple-parameter classes seems to be - I conclude this from Ryan's comment - that the intended dependency among the parameters is not reflected here. But what are the alternatives? Roughly said, I need a construct that allows me gather several type variables such that an instance is always an instance of all of them. well, given class Java a b c d where if it is true that everything is determined by choice of any one of them, you could write class Java a b c d | a - b, b - c, c - d, d - a where... otherwise, well you can express whatever dependency network you want... Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hoogle works once more
Hi, I've just finished updating Hoogle (http://haskell.org/hoogle/) to work with the latest GHC API, in particular all the base split that has occurred and the few functions that were added. It took rather longer than I would have liked, because of paper deadlines etc, but its now sufficiently automated that it should only take a few seconds next time the libraries move in new directions. So now, if there is a function you are looking for in the core libraries which you can't find, tell me. Equally, if any of the documentation links lead to a 404, please do tell me. Hoogle still doesn't search all the hackage packages (that is the ultimate intention), just a selection of packages. The darcs URL's of the packages it searches are: http://darcs.haskell.org/packages/base/ http://darcs.haskell.org/packages/array/ http://darcs.haskell.org/packages/bytestring/ http://darcs.haskell.org/packages/Cabal/ http://darcs.haskell.org/packages/containers/ http://darcs.haskell.org/packages/directory/ http://darcs.haskell.org/packages/filepath/ http://darcs.haskell.org/packages/mtl/ http://darcs.haskell.org/packages/old-locale/ http://darcs.haskell.org/packages/old-time/ http://darcs.haskell.org/packages/packedstring/ http://darcs.haskell.org/packages/parallel/ http://darcs.haskell.org/packages/parsec/ http://darcs.haskell.org/packages/process/ http://darcs.haskell.org/packages/random/ http://darcs.haskell.org/packages/stm/ http://darcs.haskell.org/packages/template-haskell/ http://darcs.haskell.org/packages/time/ I picked this list based on a couple of critera: 1) The library MUST have documentation under http://haskell.org/ghc/docs/latest/html/libraries 2) The library should have shipped with GHC at some point recently (6.6 or 6.8) 3) The library is generally useful, not task specific (Gtk2hs, OpenGL are task specific) 4) If a library is Core to GHC, it should probably be in that list Quite a few libraries were close decisions, aided by nothing more than my mood at the time. In particular things like packedstring might be worth removing, and things like cgi or html/xhtml might be worth adding. Since this is a tool for the whole community, it makes sense that the whole community has input on what that list should be. Whatever list is decided upon, it will only be for the near future. Once Hoogle 4 is finished, every library on Hackage will be searched as an equal. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle works once more
On 06/12/2007, Neil Mitchell [EMAIL PROTECTED] wrote: Hi, I've just finished updating Hoogle (http://haskell.org/hoogle/) to work with the latest GHC API, in particular all the base split that has occurred and the few functions that were added. It took rather longer than I would have liked, because of paper deadlines etc, but its now sufficiently automated that it should only take a few seconds next time the libraries move in new directions. This is great news. Hoogle is a fantastic tool. Is there a way to search on module names? If I put in Data.Map then the one thing that doesn't come up is a link to the library page for Data.Map. That would be a really good short-cut. Once again, thanks. Cheers, D. -- Dougal Stanton [EMAIL PROTECTED] // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle works once more
On Dec 6, 2007 10:50 AM, Neil Mitchell [EMAIL PROTECTED] wrote: So now, if there is a function you are looking for in the core libraries which you can't find, tell me. Equally, if any of the documentation links lead to a 404, please do tell me. Thanks for your work on Hoogle! It is an extremely useful tool. Not sure if this qualifies in any category above, but I just searched for: Monad m = m (m a) - m a And I couldn't find Control.Monad.join on any of the first 4 pages or so of results. If I search for join, of course, the first result is: Control.Monad. join:: Monad m = m (m a) - m a Is this a bug, or simply a known limitation? If the latter, is there a workaround, in case I happen not to know the name of join? -- Denis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Waiting for thread to finish
ChrisK wrote: A safer gimmick... Ben Franksen wrote: tickWhileDoing :: String - IO a - IO a tickWhileDoing msg act = do hPutStr stderr msg hPutChar stderr ' ' hFlush stderr start_time - getCPUTime tickerId - forkIO ticker ... an async exception here will leave the ticker runnning res - act `finally` killThread tickerId The best way to make this safe that I know of is: res - block $ do tickerId - forkIO ticker unblock act `finally` killThread tickerId ...but with a change that Simon M just checked in to GHC head, this will now spawn 'ticker' in blocked state, so you won't be able to kill it. You would therefore want unblock $ forkIO ticker or forkIO $ unblock ticker I'm not sure if there is a strong reason to prefer one over the other. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Waiting for thread to finish
david48 wrote: Threads won't give you a speedup unless you run the program on a multi-core/multi-proc machine. That's actually not true. Threads allow you managing your IO blocking better, and not making IO block your whole program can certainly speed it up by a couple of orders of magnitude. They help making the program simpler, IMHO. They can. They can make it more complex, too :) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle works once more
Dougal Stanton wrote: Is there a way to search on module names? If I put in Data.Map then the one thing that doesn't come up is a link to the library page for Data.Map. That would be a really good short-cut. You can already search for unqualified module names: http://haskell.org/hoogle/?q=Map shows module Data.Map as first result. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: type class question
Ryan Ingram wrote: On 12/5/07, Ben Franksen [EMAIL PROTECTED] wrote: You would have to use functional dependencies or associated types to eliminate this error. Alternatively, you can add a dummy argument of type block and pass undefined :: BlockType in to help choose the instance declaration. Sounds reasonable, and in fact that was what I tried first. However data Command = Skip class Java block command | command - block where block_ :: [command] - block compBlock :: [Command] - block compBlock = block_ . map compCommand compCommand :: Command - command still gives Could not deduce (Java block command1) from the context (Java block command) arising from use of `block_' at Bla.hs:7:14-19 Possible fix: add (Java block command1) to the class or instance method `compBlock' In the first argument of `(.)', namely `block_' In the expression: block_ . (map compCommand) In the definition of `compBlock': compBlock = block_ . (map compCommand) which is /exactly/ the same error as I get w/o the fundep. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Problems building and using ghc-6.9
Daniel Fischer wrote: Then I tried to build zlib-0.4.0.1: $ runghc ./Setup.hs configure --user --prefix=$HOME Configuring zlib-0.4.0.1... Setup.hs: At least the following dependencies are missing: base =2.02.2 ??? okay, there was something with flag bytestring-in-base, removed that, so that build-depends was base 2.0 || = 2.2, bytestring = 0.9, then $ runghc ./Setup.hs configure --user --prefix=$HOME Configuring zlib-0.4.0.1... Setup.hs: At least the following dependencies are missing: base 2.0||=2.2, bytestring =0.9 This turns out to be something that broke when we changed the command-line syntax for ghc-pkg in the HEAD. I've just posted a patch for Cabal on [EMAIL PROTECTED] Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: type class question
Ben Franksen wrote: Ryan Ingram wrote: On 12/5/07, Ben Franksen [EMAIL PROTECTED] wrote: You would have to use functional dependencies or associated types to eliminate this error. Alternatively, you can add a dummy argument of type block and pass undefined :: BlockType in to help choose the instance declaration. Sounds reasonable, and in fact that was what I tried first. However data Command = Skip class Java block command | command - block where block_ :: [command] - block compBlock :: [Command] - block compBlock = block_ . map compCommand compCommand :: Command - command still gives Could not deduce (Java block command1) from the context (Java block command) arising from use of `block_' at Bla.hs:7:14-19 Possible fix: add (Java block command1) to the class or instance method `compBlock' In the first argument of `(.)', namely `block_' In the expression: block_ . (map compCommand) In the definition of `compBlock': compBlock = block_ . (map compCommand) which is /exactly/ the same error as I get w/o the fundep. Yes, because command determines block but block doesn't determine command. So in a usage of 'compBlock' it has no way of deciding which 'command' to use, although it can choose the block from the return type. You could have command - block, block - command, if that is indeed true. Jule ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] parser
hi Can anyone advise me on how to check whether a string contains ints, chars, bools, etc 2345 + 6767 shoudl give IntAdd (2345) (6767) 2345 should give IntT 2345 Ryan _ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph theory analysis of Haskell code
Ivan Miljenovic wrote: How I envisage it happening is that a parser would be used to find all functions in the given code, treat these as nodes in the graph and then use directed edges to indicate which functions call other functions. This resultant graph can then be analysed in various ways suitable to the context (e.g. find that a library module can be split into two since there are two completely separate trees present in the graph that don't interact at all, or if a function is only ever called by one other function then it can be subsumed into it). It just occurred to me that this idea is more general than the control or data flow analysis that are the focus of similar ideas I've seen before. For example, you could trace type usage through the code (which would likely be a subset of the control flow for Haskell, but an interesting subset nonetheless). :-) -- Tommy M. McGuire [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle works once more
Hi Is there a way to search on module names? If I put in Data.Map then the one thing that doesn't come up is a link to the library page for Data.Map. That would be a really good short-cut. As Tillman says, you can search for Map alone to find Data.Map. The new version (Hoogle 4) already supports this properly, so searching for Data.Map is equivalent to searching for Map in the Data.* hierarchy - which does exactly what you want. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle works once more
Hi Dennis, Not sure if this qualifies in any category above, but I just searched for: Monad m = m (m a) - m a And I couldn't find Control.Monad.join on any of the first 4 pages or so of results. If I search for join, of course, the first result is: Control.Monad. join:: Monad m = m (m a) - m a Is this a bug, or simply a known limitation? If the latter, is there a workaround, in case I happen not to know the name of join? Unfortunately its a known bug, and there are no workarounds. Removing the Monad m = part of the query will actually make it more likely to give back join, but is still not great. The problem is that when I wrote Hoogle 3 I didn't understand higher-kinded type classes, and as a result, Hoogle 3 does a particularly bad job on them. The next version has been designed from the beginning to handle them properly, so once that's finished, you'll have no more problems. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pattern matching error
Hello!
I need to write a function which should is supposed to merge multiple
entries with the same
key (out of a sorted key-value-list) into one single entry.
However, I keep getting a pattern matching error.
(For example, for input [('b',[5]),('b',[4]),('b',[1]),('b',[6])]:
Program error: pattern match failure: kgroup
[('b',[5,4]),('b',[1]),('b',[6])])
Thank you very much for your help.
kmerge::Eq a = [(a,[b])]-[(a,[b])]
kmerge [] = []
kmerge ((x,[y]):[]) = [(x,[y])]
kmerge ((x,[y]):(u,[v]):xs) | x == u = kmerge ((x,[y,v]):xs)
| otherwise = (x,[y]):(u,[v]):kmerge xs
--
View this message in context:
http://www.nabble.com/Pattern-matching-error-tf4957268.html#a14196413
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern matching error
kmerge ((x,[y]):[]) = [(x,[y])] Matching on [y] like this will only match lists with a single element (and bind y to that element). You probably just want to say kmerge ((x,y):[]) = [(x,y)] etc., which will bind y to the entire list. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Waiting for thread to finish
Jules Bean wrote: ChrisK wrote: A safer gimmick... Ben Franksen wrote: tickWhileDoing :: String - IO a - IO a tickWhileDoing msg act = do hPutStr stderr msg hPutChar stderr ' ' hFlush stderr start_time - getCPUTime tickerId - forkIO ticker ... an async exception here will leave the ticker runnning res - act `finally` killThread tickerId The best way to make this safe that I know of is: res - block $ do tickerId - forkIO ticker unblock act `finally` killThread tickerId ...but with a change that Simon M just checked in to GHC head, this will now spawn 'ticker' in blocked state, so you won't be able to kill it. You would therefore want unblock $ forkIO ticker or forkIO $ unblock ticker I'm not sure if there is a strong reason to prefer one over the other. Jules That is new. Ah, I see GHC.Conc.forkIO now has a note: GHC note: the new thread inherits the /blocked/ state of the parent (see 'Control.Exception.block'). BUT...doesn't this change some of the semantics of old code that used forkIO ? I wanted a way to control the blocked status of new threads, since this makes it easier to be _sure_ some race conditions will never happen. And so my new preferred way of writing this is now: -- we are in parent's blocked state, so make the ticker explicit: res - bracket (forkIO (unblock ticker)) killThread const act -- act runs in parent's blocked state -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern matching error
If you add a third pattern, you can see exactly what it's failing to match:
kmerge x = error (show x)
In order to do this, you just need to add Show constraints for a and b in
the type of kmerge:
kmerge :: (Show a, Show b, Eq a) = [(a,[b])]-[(a,[b])]
You'll find that the pattern that it's failing to match is:
[('b',[5,4]),('b',[1]),('b',[6])]
Because you combined 5 and 4 and passed that on to your recursive 'kmerge'
call. Your patterns only cover the case where there is exactly one element
in the list.
- Phil
On Dec 6, 2007 9:39 AM, georg86 [EMAIL PROTECTED] wrote:
Hello!
I need to write a function which should is supposed to merge multiple
entries with the same
key (out of a sorted key-value-list) into one single entry.
However, I keep getting a pattern matching error.
(For example, for input [('b',[5]),('b',[4]),('b',[1]),('b',[6])]:
Program error: pattern match failure: kgroup
[('b',[5,4]),('b',[1]),('b',[6])])
Thank you very much for your help.
kmerge::Eq a = [(a,[b])]-[(a,[b])]
kmerge [] = []
kmerge ((x,[y]):[]) = [(x,[y])]
kmerge ((x,[y]):(u,[v]):xs) | x == u = kmerge ((x,[y,v]):xs)
| otherwise = (x,[y]):(u,[v]):kmerge
xs
--
View this message in context:
http://www.nabble.com/Pattern-matching-error-tf4957268.html#a14196413
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parser
you need to write a parser. Parser is a popular library on hackage that should do what you want. (I have never used it though.) Or read http://citeseer.ist.psu.edu/50754.html and adopt the code from there to your purposes. I found this paper extremely helpful when I needed to build a parser. t. Ryan Bloor [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/06/2007 12:06 PM To haskell-cafe@haskell.org cc Subject [Haskell-cafe] parser hi Can anyone advise me on how to check whether a string contains ints, chars, bools, etc 2345 + 6767 shoudl give IntAdd (2345) (6767) 2345 should give IntT 2345 Ryan Get closer to the jungle. I'm a Celebrity Get Me Out Of Here! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] regex package for yhc?
Is there some way to use any of the various regex packages on hackage via yhc? Has anyone installed one them successfully? I'd like regex-tdfa, but would settle for regex-posix, or really, anything that brings the convenience of regex to yhc. In general, is there a straightforward way to install extralibs type packages for universal import availability in yhc? Is there a cabal equivalent for yhc? Documentation pointer would be appreciated; I searched but couldn't find anything. Maybe not using the right keywords... t. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell examples?
On Tue, Dec 04, 2007 at 12:21:40PM -0500, Brent Yorgey wrote: I'm looking for good examples of using Template Haskell to evaluate CAFs at compile time, e.g. if I have some expensive-to-calculate lookup table which I'd rather have evaluated at comile time and included in the executable as a constant value, rather than having it computed every time the executable is run. I know I've seen examples of this before, but now that I would actually like to study such an example, I can't seem to find any. Any suggestions? Or can anyone make up a simple example on the spot? =) For any Lift'able type you can do something like this: import Language.Haskell.TH.Syntax foo = $( lift (not True) ) where not True is the CAF (and it cannot refer to functions defined in the current module due to restrictions in teh TH implementation). Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle works once more
Neil Mitchell wrote: I've just finished updating Hoogle (http://haskell.org/hoogle/) to work with the latest GHC API, in particular all the base split that has occurred and the few functions that were added. It took rather longer than I would have liked, because of paper deadlines etc, but its now sufficiently automated that it should only take a few seconds next time the libraries move in new directions. Brilliant news. I've felt slightly crippled the last few weeks due to ending up on 404 pages when using hoogle ;) I also like the new logo... it is new, right? Whatever list is decided upon, it will only be for the near future. Once Hoogle 4 is finished, every library on Hackage will be searched as an equal. This is great news. I've always missed System.Posix and Network.BSD in Hoogle. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: check if program uses haskell 98 only? Re: [Haskell-cafe] regex package for yhc?
On Thu, 6 Dec 2007, Thomas Hartman wrote:
On a related note... is there some easy way to be sure that a program I am
compiling uses only haskell 98? (Because any pure haskell 98 should always
compile on yhc... right?)
You can for instance use 'haskell98' as dependent package instead of
'base' in the Cabal description. If you import other modules, I don't know
how to check that these are Haskell 98. I weakly remember corner cases
where GHC accepts more than Haskell 98 in Haskell 98 mode. (At least it
sometimes suggests fixes for errors that are not Haskell 98, e.g. class
constraints in signatures. :-)
I compile this with ghc, no options, and iIt doesn't have any {-#-#}
options, so according to what I understand, it is using pure haskell 98.
So I might think this was a candidate for using on yhc.
I could not always pass a GHC-certified module to Hugs or even Haddock. I
remember there is some difference with respect to the trailing 'where' in
the 'instance' head, if the instance declaration is empty. Haddock expect
some spaces in infix operators (I believe ( # ) instead of (#)), which are
not required by Hugs and GHC.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern matching error
Philip Weaver [EMAIL PROTECTED] writes:
You'll find that the pattern that it's failing to match is:
[('b',[5,4]),('b',[1]),('b',[6])]
You could also use ghc with -Wall, which will tell you exactly which
cases you've omitted.
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Nested guards?
On 2007-12-06, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: list comprehensions deal with specific operations (map, filter, etc.) of a specific type ([]). Ah, so we should bring back monad comprehensions? -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: regex package for yhc?
Thomas Hartman wrote: Is there some way to use any of the various regex packages on hackage via yhc? Has anyone installed one them successfully? I'd like regex-tdfa, but would settle for regex-posix, or really, anything that brings the convenience of regex to yhc. In general, is there a straightforward way to install extralibs type packages for universal import availability in yhc? Is there a cabal equivalent for yhc? Documentation pointer would be appreciated; I searched but couldn't find anything. Maybe not using the right keywords... t. I put the regex-* packages on hackage. I have had no reports of use with yhc. Some of the convenience comes from the regex-base font end. The high level (=~) and 'match' regex API depends on the MPTC's of regex-base, and these currently use functional dependencies. This works on GHC and Hugs. I cannot quickly find on http://www.haskell.org/haskellwiki/Yhc what YHC supports. The regex-posix package is a backend, the oldest. It exposes the platform's POSIX regex.h library through the FFI calls in Text/Regex/Posix/Wrap.hsc. This C api is further layered in the data type specific modules: Text/Regex/Posix/String.hs Text/Regex/Posix/Sequence.hs Text/Regex/Posix/ByteString.hs Text/Regex/Posix/ByteString/Lazy.hs And all of that is re-exported in Text/Regex/Posix.hs A similar design is followed by the regex-pcre backend (and the deprecated regex-tre backend). One _could_ refactor regex-posix into two packages. One would give standalone accesses to the backend and simply be Haskell98 + FFI. The other would declare the instances to make this available though regex-base. The regex-tdfa backend is my own creation, and is not a wrapper for another library. It uses some non-Haskell98 syntax, such as the mdo syntactic sugar for MonadFix (aka recursive do). Cheers, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] who are the contributors to the Unix package?
Hello, Who started this effort? Who is currently doing work on the Unix package? Kind regards, Vasya ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is this strict in its arguments?
On 12/6/07, Luke Palmer [EMAIL PROTECTED] wrote: I have actually seen this pattern a lot recently. Recently I have started using a function: mergeMaybes :: (a - a - a) - Maybe a - Maybe a - Maybe a mergeMaybes f Nothing y = y mergeMaybes f x Nothing = x mergeMaybes f (Just x) (Just y) = Just (f x y) mergeMaybes = liftM2 -- from Control.Monad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is this strict in its arguments?
On 12/6/07, Ryan Ingram [EMAIL PROTECTED] wrote: On 12/6/07, Luke Palmer [EMAIL PROTECTED] wrote: I have actually seen this pattern a lot recently. Recently I have started using a function: mergeMaybes :: (a - a - a) - Maybe a - Maybe a - Maybe a mergeMaybes f Nothing y = y mergeMaybes f x Nothing = x mergeMaybes f (Just x) (Just y) = Just (f x y) mergeMaybes = liftM2 -- from Control.Monad Oh wait, not quite. Didn't realize you were returning the intermediate values in the not nothing case. mergeMaybes f x y = liftM2 f `mplus` x `mplus` y ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: who are the contributors to the Unix package?
vigalchin: Hello, Who started this effort? Who is currently doing work on the Unix package? Kind regards, Vasya It is maintained by [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is this strict in its arguments?
OK, last post. I clearly need more sleep. On 12/6/07, Ryan Ingram [EMAIL PROTECTED] wrote: mergeMaybes f x y = liftM2 f `mplus` x `mplus` y mergeMaybes f x y = liftM2 f x y `mplus` x `mplus` y ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Nested guards?
Aaron Denney wrote: On 2007-12-06, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: list comprehensions deal with specific operations (map, filter, etc.) of a specific type ([]). Ah, so we should bring back monad comprehensions? I don't miss monad comprehension much, but I'd like to have a way to use comprehension for other sequence types, notably ByteString, array types and Data.Sequence (other than converting to lists and back). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] regex package for yhc?
On Thu, 2007-12-06 at 15:21 -0500, Thomas Hartman wrote: Is there a cabal equivalent for yhc? One day we hope Cabal will support yhc. It currently supports ghc, hugs and has partial support for nhc98 and jhc. The main thing holding it back is dependency chasing in Cabal or the lack thereof. Cabal relies on the build-in dep chasing in hugs, ghc --make. It uses hmake for nhc98. We hope to replace this hodge-podge with proper dependency chasing support in Cabal, that's also extend to pre-processors etc. If anyone is interested in helping with this project, subscribe to cabal-devel and get involved. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is this strict in its arguments?
On Tue, Dec 04, 2007 at 03:07:01PM -0800, Ryan Ingram wrote: Is there a reason why strictness is defined as f _|_ = _|_ instead of, for example, forall x :: Exception. f (throw x) = throw x There's discussion along these lines in http://hackage.haskell.org/trac/ghc/ticket/1171 Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Nested guards?
Am Donnerstag, 6. Dezember 2007 22:47 schrieb Aaron Denney: On 2007-12-06, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: list comprehensions deal with specific operations (map, filter, etc.) of a specific type ([]). Ah, so we should bring back monad comprehensions? No, we already have do expressions. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph theory analysis of Haskell code
On 07/12/2007, Tommy McGuire [EMAIL PROTECTED] wrote: How I envisage it happening is that a parser would be used to find all functions in the given code, treat these as nodes in the graph and then use directed edges to indicate which functions call other functions. This resultant graph can then be analysed in various ways suitable to the context (e.g. find that a library module can be split into two since there are two completely separate trees present in the graph that don't interact at all, or if a function is only ever called by one other function then it can be subsumed into it). It just occurred to me that this idea is more general than the control or data flow analysis that are the focus of similar ideas I've seen before. For example, you could trace type usage through the code (which would likely be a subset of the control flow for Haskell, but an interesting subset nonetheless). :-) While I'd like to do this, for the purposes of ensuring that the project contains enough mathematics (and to keep my supervisor happy, since he is skeptical about why I keep bringing Haskell into everything, even though I've re-implemented in Haskell a program that he wrote in C which generated more/better answers, and we _still_ can't find where the bugs in his code are, but that's another story...), I'm not sure if I can delve too deeply into Haskell-specifics. Of course, if I can somehow turn the type usage into nodes on the graph, then that should be all right! :D On 06/12/2007, Ketil Malde [EMAIL PROTECTED] wrote: I'll just add that having a tool visualizing this would be very useful for refactoring code. If you e.g. use color to distinguish nodes/functions from different modules, you could use that information to decide to merge or split modules to minimize external interfaces. You could also try to automatically cluster nodes, which would be more interesting theoretically, but IMO less likely to be practical. Another option would be to couple this with profiling or coverage information to visualize something about the usage of paths and nodes in the call graph. This is partially what I was hoping to do. I do know that my supervisor was interested in examining C code and attaching cost information to the nodes (using some Unix profiling tool which he couldn't remember the name of), but I'm not sure how I'd go about adding compilation and profiling into such a program. -- Ivan Lazar Miljenovic ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hoogle works once more
Hoogle is an amazing tool, thanks for all your work on it! Let me put my vote in to include cgi and html/xhtml in the next revision. It might help dons convert another person or two to Haskell ... not that he needs any help. Thanks, - Hitesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph theory analysis of Haskell code
Ivan Miljenovic wrote: On 07/12/2007, Tommy McGuire [EMAIL PROTECTED] wrote: It just occurred to me that this idea is more general than the control or data flow analysis that are the focus of similar ideas I've seen before. For example, you could trace type usage through the code (which would likely be a subset of the control flow for Haskell, but an interesting subset nonetheless). :-) While I'd like to do this, for the purposes of ensuring that the project contains enough mathematics (and to keep my supervisor happy, since he is skeptical about why I keep bringing Haskell into everything, even though I've re-implemented in Haskell a program that he wrote in C which generated more/better answers, and we _still_ can't find where the bugs in his code are, but that's another story...), I'm not sure if I can delve too deeply into Haskell-specifics. Of course, if I can somehow turn the type usage into nodes on the graph, then that should be all right! :D I was actually thinking that something like that would be more valuable for a language like C, where types are not represented in the control flow. By the way, in a completely different context I just ran across a couple of references: Concrete Architecture of the Linux Kernel. Ivan T. Bowman, Saheem Siddiqi, and Meyer C. Tanuan. Conceptual Architecture of the Linux Kernel, Ivan T. Bowman. (The first is available on CiteSeer; I haven't found the second.) On 06/12/2007, Ketil Malde [EMAIL PROTECTED] wrote: I'll just add that having a tool visualizing this would be very useful for refactoring code. If you e.g. use color to distinguish nodes/functions from different modules, you could use that information to decide to merge or split modules to minimize external interfaces. You could also try to automatically cluster nodes, which would be more interesting theoretically, but IMO less likely to be practical. Another option would be to couple this with profiling or coverage information to visualize something about the usage of paths and nodes in the call graph. This is partially what I was hoping to do. I do know that my supervisor was interested in examining C code and attaching cost information to the nodes (using some Unix profiling tool which he couldn't remember the name of), prof and gprof? but I'm not sure how I'd go about adding compilation and profiling into such a program. -- Tommy M. McGuire [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph theory analysis of Haskell code
On 07/12/2007, Tommy McGuire [EMAIL PROTECTED] wrote: I was actually thinking that something like that would be more valuable for a language like C, where types are not represented in the control flow. By the way, in a completely different context I just ran across a couple of references: Concrete Architecture of the Linux Kernel. Ivan T. Bowman, Saheem Siddiqi, and Meyer C. Tanuan. Conceptual Architecture of the Linux Kernel, Ivan T. Bowman. (The first is available on CiteSeer; I haven't found the second.) OK, thanks. prof and gprof? That looks like them. Of course, us Haskellers have no need of such things, since our programs have profiling inbuilt into the RTS (at least when using GHC, anyway)! -- Ivan Lazar Miljenovic ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announce: PDXFunc: Portland FP Users Group
Who: Portland Functional Programmers Group Web: http://groups.google.com/group/pdxfunc Time and location: Monday, December 10th, 7pm at CubeSpace, 622 SE Grand, Portland, OR 97214. Directions: http://www.cubespacepdx.com/directions Topic Functional concurrency with Haskell Portland isn't going to miss out on the fun! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph theory analysis of Haskell code
On Fri, Dec 07, 2007 at 10:16:43AM +1000, Ivan Miljenovic wrote: On 07/12/2007, Tommy McGuire [EMAIL PROTECTED] wrote: I was actually thinking that something like that would be more valuable for a language like C, where types are not represented in the control flow. By the way, in a completely different context I just ran across a couple of references: Concrete Architecture of the Linux Kernel. Ivan T. Bowman, Saheem Siddiqi, and Meyer C. Tanuan. Conceptual Architecture of the Linux Kernel, Ivan T. Bowman. (The first is available on CiteSeer; I haven't found the second.) OK, thanks. prof and gprof? That looks like them. Of course, us Haskellers have no need of such things, since our programs have profiling inbuilt into the RTS (at least when using GHC, anyway)! prof derives most of its utility from special hooks baked into gcc and libc. So gcc/prof is not really that different from ghc/hp2ps. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] how to compile this in yhc?
Is there some way to compile the following function in yhc? works in ghc with glasgow exts deactivated, yhc complains context for Prelude.read needed (in final line) readfloat :: String - Maybe Float readfloat x | null parse || not (null leftover) = fail $ myRead: ++x | otherwise = return v where parse@((v,leftover):ps) = readsPrec 0 x thanks! --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] surprised by type class binding -- is this a bug?
Haskellians,
i'm sure i don't understand type classes, yet. Still, i was surprised at
ghci's response to the code below. Clues gratefully accepted.
Best wishes,
--greg
-- transcript
-- Prelude :l grn
-- [1 of 1] Compiling GeneticRegulatoryNetwork ( grn.hs, interpreted )
-- grn.hs:33:35:
--Couldn't match expected type `b1' (a rigid variable)
-- against inferred type `b' (a rigid variable)
-- `b1' is bound by the type signature for `sequence' at grn.hs:25:36
-- `b' is bound by the instance declaration at grn.hs:31:0
-- Expected type: [b1]
-- Inferred type: [b]
--In the expression: molecules
--In the definition of `sequence':
--sequence (Site l1 molecules) = molecules
-- Failed, modules loaded: none.
-- Prelude
{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
-- -*- mode: Haskell;-*-
-- Filename:grn.hs
-- Authors: lgm
-- Creation:Thu Dec 6 15:38:26 2007
-- Copyright: Not supplied
-- Description:
--
module GeneticRegulatoryNetwork
where
data Segment p =
Nil
| Section [p] (Segment p)
deriving (Eq, Show)
class BindingMolecule b l | b - l where
name:: b - l
complement :: b - b
complements :: b - Bool
class Locale s l1 l2 | s - l1 l2 where
label :: s - l1
sequence:: (BindingMolecule b l2) = s - [b]
provides:: (BindingMolecule b l2) = s - [b] - Bool
matches :: (BindingMolecule b l2) = s - [b] - Bool
data (BindingMolecule b l2) = Site b l1 l2 = Site l1 [b] deriving (Eq,
Show)
instance (BindingMolecule b l2) = Locale (Site b l1 l2) l1 l2 where
label(Site l1 _) = l1
sequence (Site l1 molecules) = molecules
provides (Site l1 molecules) molecules' = False -- tbd
matches (Site l1 molecules) molecules' = False -- tbd
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
505 N 72nd St
Seattle, WA 98103
+1 206.650.3740
http://biosimilarity.blogspot.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: surprised by type class binding -- is this a bug?
Haskellians,
Belay that. i see the problem.
Best wishes,
--greg
On Dec 6, 2007 11:11 PM, Greg Meredith [EMAIL PROTECTED]
wrote:
Haskellians,
i'm sure i don't understand type classes, yet. Still, i was surprised at
ghci's response to the code below. Clues gratefully accepted.
Best wishes,
--greg
-- transcript
-- Prelude :l grn
-- [1 of 1] Compiling GeneticRegulatoryNetwork ( grn.hs, interpreted )
-- grn.hs:33:35:
--Couldn't match expected type `b1' (a rigid variable)
-- against inferred type `b' (a rigid variable)
-- `b1' is bound by the type signature for `sequence' at grn.hs:25:36
-- `b' is bound by the instance declaration at grn.hs:31:0
-- Expected type: [b1]
-- Inferred type: [b]
--In the expression: molecules
--In the definition of `sequence':
--sequence (Site l1 molecules) = molecules
-- Failed, modules loaded: none.
-- Prelude
{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
-- -*- mode: Haskell;-*-
-- Filename:grn.hs
-- Authors: lgm
-- Creation:Thu Dec 6 15:38:26 2007
-- Copyright: Not supplied
-- Description:
--
module GeneticRegulatoryNetwork
where
data Segment p =
Nil
| Section [p] (Segment p)
deriving (Eq, Show)
class BindingMolecule b l | b - l where
name:: b - l
complement :: b - b
complements :: b - Bool
class Locale s l1 l2 | s - l1 l2 where
label :: s - l1
sequence:: (BindingMolecule b l2) = s - [b]
provides:: (BindingMolecule b l2) = s - [b] - Bool
matches :: (BindingMolecule b l2) = s - [b] - Bool
data (BindingMolecule b l2) = Site b l1 l2 = Site l1 [b] deriving (Eq,
Show)
instance (BindingMolecule b l2) = Locale (Site b l1 l2) l1 l2 where
label(Site l1 _) = l1
sequence (Site l1 molecules) = molecules
provides (Site l1 molecules) molecules' = False -- tbd
matches (Site l1 molecules) molecules' = False -- tbd
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
505 N 72nd St
Seattle, WA 98103
+1 206.650.3740
http://biosimilarity.blogspot.com
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
505 N 72nd St
Seattle, WA 98103
+1 206.650.3740
http://biosimilarity.blogspot.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] distinguish functions from non-functions in a class/instances
Ryan Ingram wrote: No, that doesn't work; it's close, but not quite. liftM doesn't have the right type signature. liftM :: Monad m = (a - r) - (m a1 - m r) What would work is if you could define a function liftLast :: Monad m = (a0 - a1 - ... - aN - r) - (a0 - a1 - ... - aN - m r) then nary' f = runIdentity . nary (liftLast f) -- ryan I don't see a way to implement liftLast or nary for functions like (a - b - ... - r) where r is not of the form (m s). Of course one can use the Identity Monad for m, but in either case you have to modify functions like (Int - Int) to something like (Int - m Int) for a fixed type m (e.g. Identity). -- philipp n. -- View this message in context: http://www.nabble.com/distinguish-functions-from-non-functions-in-a-class-instances-tf4952209.html#a14208302 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
