Re: [Haskell-cafe] Ix, Random, and overlapping instances
Hello Lambda, Monday, August 21, 2006, 1:20:26 AM, you wrote: Greetings Haskellers, I have recently found myself in a situation where I was needing to general tuples of randomized things; in my case, two coordinates and a custom data type, Direction. As it is always better to generalize, I decided to try to write some code which would generalize randomR to any type which is Ix-able: instance Ix i = Random i where random = error No supported instance for random randomR r g = let r' = range r (i, g') = randomR (0,length r'-1) g in (r' !! i, g') using of (!!) is very inefficient. i don't think that GHC will optimize such code to just arithmetic operations This works splendidly; with my given example above, I could do: data Dir = N | NE | E | SE | S | SW | W | NW deriving (Eq, Ord, Show, Ix) ghci newStdGen = print . take 10 . randomRs ((1,1,N),(10,10,NW)) [(5,4,S), (3,10,SE), (6,5,N), (6,6,NW), (10,8,SE), (3,10,W), (10,3,E), (1,6,NE), (10,10,SE), (3,3,S)] As you can see, this results in random tuple(s) of these indexable types. My implementation required -fallow-overlapping-instances and - fallow-undecidable-instances for the code to compile. A few questions: 1) How does the compiler determine how to choose a particular instance for those cases where they overlap? it selects most specific instance, preferring concrete types over type classes. but it don't take into account hierarchy of classes. afair, chapter 7 of GHC user's guide considers type system extensions I noticed that if I tried to generate a random :: Int, I was getting the error message defined in the above instance, indicating that the compiler was choosing my implementation over the default for Int (obviously because Int is an instance of Ix). Is there some way to exclude classes in the class qualifier, or to provide an instance as a default case without resorting to -fallow-overlapping-instances? it's better to show your complete code. as one possible workaround i can suggest the following: class Ix i = Random i instance Random Int ... instance Random (Int,Int) -- default definitions will be used 2) Is there a logical overlap between class Ix and class Bounded? It seems that we could use the ranges of data types of Bounded to generate a reasonably sane `random` implementation for all Ix, if we can guarantee that all Ix instances are Bounded. Would adding an additional class constraint be sufficient to catch the major cases? i.e., instance (HasBounds i, Ix i) = Random i where ... btw, how about the following: instance (Enum i, Bounded i) = Random i where ... and then defining instances for tuples? it will be efficient and overlappings-free 3) Is there some reason that Ix is restricted to the Int datatype? Is there anything preventing us from moving to a genericIx,or something along those lines which support any integral type (say Integer), or is it merely for performance reasons that we use Int? Is the expectation that if you are using spaces larger than what an Int can accommodate, you should be using a different mechanism? i think that this just because Ix was introduced solely for array indexing which 1) should be fast, 2) almost don't require indexes larger than Int can hold -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Useful: putCharLn {inspire by the Int-[Char] thread
On 8/19/06, Henk-Jan van Tuyl [EMAIL PROTECTED] wrote: Or you could use: putStrLn [head This and that] Gotta say I really like this ... running the head function inside of the list... Okay so I can really learn something here... what would that look like in raw monadic notation? using bind and such notation... = etc.. hey, mention was made of lists being monads.. so gene ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Useful: putCharLn {inspire by the Int-[Char] thread
yumagene: On 8/19/06, Henk-Jan van Tuyl [EMAIL PROTECTED] wrote: Or you could use: putStrLn [head This and that] Gotta say I really like this ... running the head function inside of the list... Okay so I can really learn something here... what would that look like in raw monadic notation? using bind and such notation... = etc.. hey, mention was made of lists being monads.. so Perhaps: putStrLn . return . head $ This and that -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: iterative algorithms: how to do it in Haskell?
Lennart and all, On 8/19/06, Lennart Augustsson [EMAIL PROTECTED] wrote: There are much better ways than storing strings on the stack. Like using a data type with constructors for the different types that you can store. -- Lennart Off topic, but this is important info for me! Okay then, by doing that you can define a new type that encodes the other types.. such that you can actually end up storing the different types such as Int, Integer,Real, String, etc into a list . using this new type to so that even though you are in effect storing differing types to a list.. they are actually of the same type and thus legal... without doing an explicit bunch of read/show combinations.. to actually convert.. like Num for example... and being able to use +,* on any of the numeric types... but can you have a list of type [Num] ?? I thought that it had to be the base types of Int, Integer, Float, Double etc.. No? thanks, gene ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Memoizing longest-common-subsequence
From: Jared Updike [mailto:[EMAIL PROTECTED]
Ian's LCS code looks like it works fine in terms of space usage, but
for large input (lengrh as == 4, length bs == 5) it seems to
be way too slow in terms of time complexity (GNU sdiff executes on
this same data in a few seconds, the Hunt-Szymanski LCS algorithm
didn't terminate, even after like 10 minutes).
If it's not too much trouble, could you send Myers STArray based code?
Thanks,
Jared.
(Sorry for the late reply; have been on holiday.)
Included below. I used to have a unit test module, and also a pure
DiffArray-based implementation for performance comparison (it was
slw), but I lost them when my laptop died (a harsh lesson in
infrequent backups), so all I have left is the implementation module
now.
I've used it to diff fairly large files (hundreds of K's, if not Megs)
where there were few differences. It seemed to perform OK, and in cases
where GNU diff (or whatever comes with MSYS) failed.
Alistair
module Diff (diff, diffArray, diffSTArray, Modification(..)) where
{-
See:
http://www.eecs.berkeley.edu/~gene/Papers/np_diff.pdf
http://www.cs.arizona.edu/~gene/PAPERS/np_diff.ps
(An O(NP) sequence comparison algorithm)
The algorithm in the paper is:
compare(src, dst)
M := length src; N := length dst; delta := N - M;
fp[-(M+1)..(N+1)] := -1;
p := -1;
repeat
p++;
for k := -p to delta-1 do
fp[k] := snake(k, max(fp[k-1] + 1, fp[k+1]));
for k := delta+p downto delta+1 by -1 do
fp[k] := snake(k, max(fp[k-1] + 1, fp[k+1]));
k := delta;
fp[k] := snake(k, max(fp[k-1] + 1, fp[k+1]));
until fp[delta] = N
print edit distance + (delta + 2*p)
end;
snake(k, y)
x := y - k;
while x M and y N and src[x+1] = B[y+1] do
x := x + 1; y := y + 1;
return y;
end;
Notes:
1. In the paper, y refers to the column position,
and x is the row number.
This is not conventional! i.e. x and y are swapped.
In this implementation we use x and y in the conventional
manner, and store the x value in the vertex array.
3. The algorithm as stated in the paper does not indicate
how to determine when a move down or right occurs.
I've assumed it's any update to a diagonal,
where the new x or y value is within the dst or src bounds.
4. We need to set vtx[0] = 0. This handles the case where the
destination string is empty.
In this case, the first move should be a delete i.e. a move down.
If vtx[0] = -1 then the nextEdit function would choose
a move right to diagonal 0 (this would put us further along
the diagonal than a move down), but we only want to move down,
so this is the wrong move. Hence we set vtx[0] = 0.
Note that the algorithm appears to work for all other cases
(including empty src and non-empty dst) when vtx[0] is
either 0 or -1.
All other entries of vtx[] are initialised to -1.
5. The algorithm in the paper only handles the case where
length dst = length src
i.e. where delta = 0.
How do we modify it to handle delta 0?
The rules for generating digaonals for delta = 0 are:
[-p up-to d-1] (below delta)
[p+d downto d+1] (above delta)
[d]
And the rules for delta 0:
[p downto d+1] (above delta)
[-d-p up-to d-1] (below delta)
[d]
These are derived from the recurrence relation which is:
x[k,p] =
k delta | snake( max( x[k-1,p ] + 1, x[k+1,p-1] ) )
k delta | snake( max( x[k-1,p ] + 1, x[k+1,p ] ) )
k = delta | snake( max( x[k-1,p-1] + 1, x[k+1,p ] ) )
Look at patterns for examining diagonals:
delta = 0:
0 | p=0: 0 p=1: -1,1,0 p=2: -2,-1,2,1,0 p=3: -3,-2,-1,3,2,1,0 p=4:
-4,...
delta 0:
1 | p=0: 0,1 p=1: -1,0,2,1 p=2: -2,-1,0,3,2,1 p=3: -3,-2,-1,0,4,3,2,1
p=3: -4,...
2 | p=0: 0,1,2 p=1: -1,0,1,3,2 p=2: -2,-1,0,1,4,3,2 p=3: -3,...
First iteration goes from 0 to delta (outside in).
Let's see what pattern is like for delta 0.
delta 0
-1| p=0: 0,-1 p=1: 1,0,-2,-1 p=2: 2,1,0,-3,-2,-1
-2| p=0: 0,-1,-2 p=1: 1,0,-2,-1 p=2: 2,1,0,-3,-2,-1
-}
import Data.Array.ST as STA
import Data.Array
import Control.Monad.ST
data Modification a = Ins !Int !a | Del !Int !a
deriving (Show, Eq)
inBounds arr i = case STA.bounds arr of (l, u) - i = l i = u
upperBound arr = case STA.bounds arr of (_, u) - u
isUpperBound arr i = i == upperBound arr
-- list interface
diff :: Eq a = [a] - [a] - [Modification a]
diff [] [] = []
diff src dst = runST ( do
srca - makeArray1 src
dsta - makeArray1 dst
diffSTArray srca dsta )
-- Array interface
diffArray :: Eq a = Array Int a - Array Int a - [Modification a]
diffArray src dst = runST ( do
-- We can use unsafeThaw because we don't modify src or dst
srca - unsafeThaw src
dsta - unsafeThaw dst
diffSTArray srca dsta )
-- STArray interface
diffSTArray :: Eq a = STArray s Int a - STArray s Int a - ST s
[Modification a]
diffSTArray src dst = do
let
boundLower = 1 + upperBound src
boundUpper = 1 + upperBound dst
delta =
Re: [wxhaskell-users] FW: Reviving wxHaskell (was: Re: [Haskell-cafe] Troublecompiling wxhaskell)
Hi all,First, thanks Daan for offering to stay involved. I'd much prefer to have you working on the project in whatever capacity is possible for you - as the main architect and the person with most knowledge of the wxHaskell implementation, this will be invaluable. Second thing, for those who are following this thread on Haskell Cafe, I think that we should move subsequent discussion to [EMAIL PROTECTED] - I will post a summary of any conclusions we reach back to Haskell Cafe for general interest.I am going to mail those who have replied offering help off-list to try to determine the realistic level of commitment they can make to the project, with the hope that we can come up with a viable set of core contributors with well-defined responsibilities. I don't think it's fair on the individuals concerned to perform such discussions on-list asitisabigthingtoasksomeonetocommittheirtimeandeffortfreely, and public discussion can place unfair pressure on individuals. My 'day job' involves managing software development teams and deliveries, so I'm prepared to take on this side of the project if there's general agreement. From everything I've seen and read, this is often a hard area to resource in Open Source projects (as it's not especially glamorous), as well as contributing patches and test effort on Windows and OSX. It sounds as though we have, in principle, people prepared to look at all of the major platforms, although as yet the commitments do not extend to helping with packaging for platforms, and I see this as vitally important to the success of wxHaskell. It's currently too difficult to build for the casual user (yes, I accept that 'casual user' is probably an oxymoron in the Haskell community ;-). Please watch this space (on wxhaskell-users) for updates.RegardsJeremyThanks to all who have repliedOn 01/08/06, Daan Leijen [EMAIL PROTECTED] wrote: Dear wxHaskell users, First of all, I apologize for not being responsive on the wxHaskell users mailing list. I recently changed jobs and countries and didn't properly take care of older email aliases. Anyway, even though I am motivated to support wxHaskell, practice proves that the project is too large for me to do alone. It would be great if someone or a group of people feel motivated enough to take over the project and release new versions that are compatible with the latest Ghc versions. One potential challenge is to find a group of testers that are willing to help compiling wxHaskell on different target systems: Windows, MacOS X, and Unix/GTK variations. I am happy to give volunteers administrator privileges on the sourceforge site and help out with the initial transition and building the initial new release (which is generally a lot of careful work in compiling and packaging correctly). All the best,-- Daan Leijen. Ps. Include me on the reply list as I am not subscribed properly to either mailing list at the moment. From: Simon Peyton-Jones Sent: Tuesday, August 01, 2006 4:46 AMTo: Daan LeijenSubject: FW: Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Troublecompiling wxhaskell) Daan Have you seen this thread? Would you care to respond to it? Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeremy O'DonoghueSent: 01 August 2006 09:37Cc: haskell-cafe@haskell.org; [EMAIL PROTECTED]Subject: Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Troublecompiling wxhaskell) Hi list, Apologies for continuing with the cross-posting, but wxhaskell-users is not exactly active. It seems like there may be enough interest in wxHaskell to justify trying to revive the project. At present, from what I can tell, Daan Leijen, the principal developer of wxHaskell, no longer has much interest in the project - the CVS log shows little activity for about 15 months now - and using wxHaskell with newer wxWidgets versions or on Unicode systems requires the application of various patches (for which the interested potential user must search diligently). Ideally, it would be best Daan for to enable new CVS committers to the project (or even to hand over project administration), but if this is not an option, is there a possibility of hosting a fork on hackage.haskell.org (I think there's a benefit in hosting Haskell-specific projects in a Haskell-friendly location). I don't have the time to nurture huge ambitions for wxHaskell, but I think it is realistic to aim for the following in the short term: * Patches to ensure that wxHaskell compiles against latest wxWidgets versions on Mac, Linux and Windows (exists today) * Add Eric Kow's Unicode patches (exist today) * Produce suitable binary packages for whatever targets we can get maintainers for, compatible with up-to-date versions of both GHC and wxWidgets. * Improve samples and documentation. In the longer term, we could look at: * Fixing operation with sash windows (a personal gripe ;-) - easy * Wrapping some of the more complex widgets - easy. * Subclassing of widgets in
Re: [wxhaskell-users] FW: Reviving wxHaskell (was: Re: [Haskell-cafe] Troublecompiling wxhaskell)
Hi Shelarcy,Thanks for volunteering to work on the Windows port. What I'd like to ask is this: we need someone to maintain the Windows port.I think, in practice, that this would mean maintaining the Windows build files (which should, generally, be a fairly straightforward job) as well as building and testing updates. With reasonable coordination from all concerned, I believe that this would mean doing a rebuild aned regression test at least once a month. You will understand that before I can take on work with wxHaskell, I need someone in place to lead each supported platform. I'm quite an active user of wxhaskell on Windows, and would probably be able to share the build file work and testing, so I think your commitment would be around 2-3 hours per month (with considerably more leading up to major releases - whichi should occur about every six months). If you are willing, please let me know, and I'll put your name in place as Windows Maintainer. If not, I understand, and will ask you to help with testing if I am able to get a core team together.Best regards JeremyOn 02/08/06, Jeremy O'Donoghue [EMAIL PROTECTED] wrote: Hi all,First, thanks Daan for offering to stay involved. I'd much prefer to have you working on the project in whatever capacity is possible for you - as the main architect and the person with most knowledge of the wxHaskell implementation, this will be invaluable. Second thing, for those who are following this thread on Haskell Cafe, I think that we should move subsequent discussion to [EMAIL PROTECTED] - I will post a summary of any conclusions we reach back to Haskell Cafe for general interest.I am going to mail those who have replied offering help off-list to try to determine the realistic level of commitment they can make to the project, with the hope that we can come up with a viable set of core contributors with well-defined responsibilities. I don't think it's fair on the individuals concerned to perform such discussions on-list asitisabigthingtoasksomeonetocommittheirtimeandeffortfreely, and public discussion can place unfair pressure on individuals. My 'day job' involves managing software development teams and deliveries, so I'm prepared to take on this side of the project if there's general agreement. From everything I've seen and read, this is often a hard area to resource in Open Source projects (as it's not especially glamorous), as well as contributing patches and test effort on Windows and OSX. It sounds as though we have, in principle, people prepared to look at all of the major platforms, although as yet the commitments do not extend to helping with packaging for platforms, and I see this as vitally important to the success of wxHaskell. It's currently too difficult to build for the casual user (yes, I accept that 'casual user' is probably an oxymoron in the Haskell community ;-). Please watch this space (on wxhaskell-users) for updates.RegardsJeremyThanks to all who have repliedOn 01/08/06, Daan Leijen [EMAIL PROTECTED] wrote: Dear wxHaskell users, First of all, I apologize for not being responsive on the wxHaskell users mailing list. I recently changed jobs and countries and didn't properly take care of older email aliases. Anyway, even though I am motivated to support wxHaskell, practice proves that the project is too large for me to do alone. It would be great if someone or a group of people feel motivated enough to take over the project and release new versions that are compatible with the latest Ghc versions. One potential challenge is to find a group of testers that are willing to help compiling wxHaskell on different target systems: Windows, MacOS X, and Unix/GTK variations. I am happy to give volunteers administrator privileges on the sourceforge site and help out with the initial transition and building the initial new release (which is generally a lot of careful work in compiling and packaging correctly). All the best,-- Daan Leijen. Ps. Include me on the reply list as I am not subscribed properly to either mailing list at the moment. From: Simon Peyton-Jones Sent: Tuesday, August 01, 2006 4:46 AMTo: Daan LeijenSubject: FW: Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Troublecompiling wxhaskell) Daan Have you seen this thread? Would you care to respond to it? Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeremy O'DonoghueSent: 01 August 2006 09:37Cc: haskell-cafe@haskell.org; [EMAIL PROTECTED]Subject: Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Troublecompiling wxhaskell) Hi list, Apologies for continuing with the cross-posting, but wxhaskell-users is not exactly active. It seems like there may be enough interest in wxHaskell to justify trying to revive the project. At present, from what I can tell, Daan Leijen, the principal developer of wxHaskell, no longer has much interest in the project - the CVS log shows little activity for about 15 months now - and using wxHaskell with
Re: [Haskell-cafe] Re: iterative algorithms: how to do it in Haskell?
On 2006 August 21 Monday 04:42, Gene A wrote: but can you have a list of type [Num] ?? I thought that it had to be the base types of Int, Integer, Float, Double etc.. No? See http://www.haskell.org/hawiki/ExistentialTypes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: iterative algorithms: how to do it in Haskell?
Hello Gene, Monday, August 21, 2006, 12:42:17 PM, you wrote: being able to use +,* on any of the numeric types... but can you have a list of type [Num] ?? I thought that it had to be the base types of Int, Integer, Float, Double etc.. No? you can, using existentials: data Number = forall a. (Num a, Show a) = Num a main = print [Num (1::Int), Num (1.1::Double), Num (1::Integer)] but that is not really very important. in my own practice, homogeneous lists are suffice in almost all cases you can read recent discussion on this in this topic, or look at http://haskell.org/haskellwiki/OOP_vs_type_classes, where John Meacham and me describes how existentials can partially emulate OOP classes -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] C++ class = neutered (haskell class + haskellexistential)
Hello Brian, Friday, August 18, 2006, 8:54:08 PM, you wrote: classes: lack of record extension mechanisms (such at that implemented in O'Haskell) and therefore inability to reuse operation implementation in an derived data type... You can reuse ops in a derived data type but it involves a tremendous amount of boilerplate. Essentially, you just use the type classes to simulate extendable records by having a method in each class that accesses the fixed-length record corresponding to that particular C++ class. btw, i just found the following in HWN: * HList updates . Oleg Kiselyov [17]announced that HList, the library for strongly typed heterogeneous lists, records, type-indexed products (TIP) and co-products is now accessible via darcs, [18]here. Additionally, Oleg pointed to some new features for HList, including a new representation for open records. Finally, he [19]published a note on how HList supports, natively, polymorphic variants: extensible recursive open sum datatypes, quite similar to Polymorphic variants of OCaml. HList thus solves the `expression problem' -- the ability to add new variants to a datatype without changing the existing code. 17. http://article.gmane.org/gmane.comp.lang.haskell.general/13905 18. http://darcs.haskell.org/HList/ 19. http://article.gmane.org/gmane.comp.lang.haskell.general/13906 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Writing binary files
Hi, I'm trying to write out a binary file, in particular I want the following functions: hPutInt :: Handle - Int - IO () hGetInt :: Handle - IO Int For the purposes of these functions, Int = 32 bits, and its got to roundtrip - Put then Get must be the same. How would I do this? I see Ptr, Storable and other things, but nothing which seems directly useable for me. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: iterative algorithms: how to do it in Haskell?
I don't know exactly what types you have as base types in your implementation, but here's a small code fragment that of what I had in mind. data Value = D Double | S String | B Bool type Stack = [Value] -- Add top stack elements plus :: Stack - Stack plus (D x : D y : vs) = D (x+y) : vs plus ( _ : _ : _) = error Bad operands to plus plus_ = error Not enough operands on stack equal :: Stack - Stack equal (D x : D y : vs) = B (x == y) : vs equal (S x : S y : vs) = B (x == y) : vs equal (B x : B y : vs) = B (x == y) : vs equal ( _ : _ : _) = error Bad operands to equal equal_ = error Not enough operands on stack -- Lennart On Aug 21, 2006, at 04:42 , Gene A wrote: Lennart and all, On 8/19/06, Lennart Augustsson [EMAIL PROTECTED] wrote: There are much better ways than storing strings on the stack. Like using a data type with constructors for the different types that you can store. -- Lennart Off topic, but this is important info for me! Okay then, by doing that you can define a new type that encodes the other types.. such that you can actually end up storing the different types such as Int, Integer,Real, String, etc into a list . using this new type to so that even though you are in effect storing differing types to a list.. they are actually of the same type and thus legal... without doing an explicit bunch of read/show combinations.. to actually convert.. like Num for example... and being able to use +,* on any of the numeric types... but can you have a list of type [Num] ?? I thought that it had to be the base types of Int, Integer, Float, Double etc.. No? thanks, gene ___ 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] Haddock/Cabal/base bug?
On Sun, 20 Aug 2006, Neil Mitchell wrote: Hi, I want to generate documentation for the base libraries, so I darcs get the base libraries, and a very basic (the sample default) Setup.hs, and try: runhaskell Setup configure runhaskell Setup build Pretty much no luck, but I'll leave that for someone else to sort out :) runhaskell Setup haddock First task is to remove errors about -fno-implicit-bangs, which are in a few files, relatively easy to do. After that it gets quite far (invokes haddock a fair bit) before failing with: haddock.exe: Main.all_subs_of_qname: unexpected unqual'd name:IOMode Sometimes such an error is a Haddock problem, sometimes one of the 'unliterate' procedure in Cabal. Does the problem remain if you start Haddock manually, maybe on manually unliterated modules? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock/Cabal/base bug?
Hi haddock.exe: Main.all_subs_of_qname: unexpected unqual'd name:IOMode Sometimes such an error is a Haddock problem, sometimes one of the 'unliterate' procedure in Cabal. Does the problem remain if you start Haddock manually, maybe on manually unliterated modules? Base is a bit too big and my shell skills are a bit too weak to try this out manually. I don't think its a .lhs problem, since the only .lhs files in base are under GHC, which haddock doesn't index when built with Cabal for the base. It does seem to invoke the preprocessor for all the other modules When I went into haddock and commented out the line that generates that error, it did work though. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing binary files
Neil Mitchell wrote: I'm trying to write out a binary file, in particular I want the following functions: hPutInt :: Handle - Int - IO () hGetInt :: Handle - IO Int For the purposes of these functions, Int = 32 bits, and its got to roundtrip - Put then Get must be the same. How would I do this? I see Ptr, Storable and other things, but nothing which seems directly useable for me. hPutInt h = hPutStr h . map chr . map (0xff ..) . take 4 . iterate (`shiftR` 8) hGetInt h = replicateM 4 (hGetChar h) = return . foldr (\i d - i `shiftL` 8 .|. ord d) 0 This of course assumes that a Char is read/written as a single low-order byte without any conversion. But you'd have to assume a lot more if you started messing with pointers. (Strange, somehow I get the feeling, the above is way too easy to be the answer you wanted.) Udo. -- Worrying is like rocking in a rocking chair -- It gives you something to do, but it doesn't get you anywhere. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing binary files
Hi hPutInt h = hPutStr h . map chr . map (0xff ..) . take 4 . iterate (`shiftR` 8) hGetInt h = replicateM 4 (hGetChar h) = return . foldr (\i d - i `shiftL` 8 .|. ord d) 0 This of course assumes that a Char is read/written as a single low-order byte without any conversion. But you'd have to assume a lot more if you started messing with pointers. (Strange, somehow I get the feeling, the above is way too easy to be the answer you wanted.) It's exactly the answer I was hoping for! Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] DiffArray is an unsaturated type?
Hi, I note that in the base libraries, Data.Array.Diff is defined as: type DiffArray = IOToDiffArray IOArray However, IOToDiffArray takes 3 parameters. I thought this was not allowed in Haskell 98? Its annoying from my point of view because Hoogle wants to know the arity of a type, and if it has to chase down the arity of the RHS to do it, I probably just won't bother. Is there any difference between the above definition and: type DiffArray a b = IOToDiffArray IOArray a b Is the first prefered for any reason? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: iterative algorithms: how to do it in Haskell?
Hi All,
I got up this morning {after not much sleep} to find these very
helpful suggestions/comments:
from Scott Turner:
{... See: http://www.haskell.org/hawiki/ExistentialTypes ...}
From Bulat Ziganshin:
{...
you can read recent discussion on this in this topic, or look at
http://haskell.org/haskellwiki/OOP_vs_type_classes
}
From Lennart Augustsson,
A wonderfully instructive code fragment:
{...
data Value = D Double | S String | B Bool
type Stack = [Value]
-- Add top stack elements
plus :: Stack - Stack
plus (D x : D y : vs) = D (x+y) : vs
plus ( _ : _ : _) = error Bad operands to plus
plus_ = error Not enough operands on stack
...} see his post for the continuation...
With these suggestions I have plenty to study now.. and probably a whole
redesign of some of the things that I have already implemented.. with
most likely a great boost in speed of execution, and much cleaner
code. I must admit that some of these concepts have not come as
easily to me as to some that have had formal education in these
matters... This list and the materials from Haskell.org, papers on
various websites, and documentation with GHC and it's libraries are my
entire exposure.. so when stuck, kind folks from the net community are
my, I guess mentors would be the word I am looking for... and for that
I am very greatful!
I am not in a real race... but I have to thank everyone that
participated in this spawned off of the main topic discussion... for
all their patience with my questions..
Thanks again to All for the clarification and links to more reading,
gene
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Useful: putCharLn {inspire by the Int-[Char] thread
This might be easier:
Prelude putStrLn $ return $ head this and that
t
Prelude
Gene A wrote:
The thread on the use of show and print to display an Int value,
brought up a problem I had early on... the one of cleanly displaying a
Char value, on a line all by itself.. My first attempts:
This was just plain hard to read: with the character t being where it
was:
Prelude putChar $ head this and that
tPrelude
---
So I tried this and of course ... type mismatch:
Prelude putStrLn $ head this and that
interactive:1:16:
Couldn't match `String' against `Char'
Expected type: [String]
Inferred type: [Char]
In the first argument of `head', namely `this and that'
In the second argument of `($)', namely `head this and that'
--
So I did this... to manually turn it to a string and it does work, but
a little cumbersome to work into other function calls:
Prelude putStrLn $ (head this and that):[]
t
-
so the definition of putCharLn came to life {may be in some library
already
and I just haven't found it yet.. but it is in my toolbox now}:
Prelude let putCharLn c = putStrLn (c:[])
Prelude
and an application of it:
Prelude putCharLn $ head this and that
t
---
now I also have the char to string conversion alone:
c2Str c = c:[]
Prelude let c2Str c = c:[]
Prelude c2Str 'A'
A
--
Now this is almost too trivial a thing to mention these gizmos...
what with all the monadic constructions that greater minds toss
about on this list.. and I am trying to get understanding of that
still, but
sometimes we just accept the unacceptable little irritants
rather than just code a solution, no matter how simple it is.
There are probably troves of simple workarounds out there
that seem too trivial to mention but hey, share 'em...
might hit a guy like me that says. now why didn't I think to do that?
happy days,
gene
___
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
[Haskell-cafe] Re: Useful: putCharLn {inspire by the Int-[Char] thread
hi, Now, is there a speed or cleaness of code advantage to using the function composition method using (.) : putStrLn . return . head $ This and that over the application method...using ($): putStrLn $ return $ head this and that some thoughts on that ... they both work.. but any advantage or disadvantage to one over the other.. I find a lot of these kind of things in Haskell, and it is purely wonderful.. but always go away wondering if I am really using the most efficient, or most acceptable method.. gene ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] A restricted subset of CPP included in a revisionof Haskell 98
On 8/20/06, Brian Hulley [EMAIL PROTECTED] wrote: Henning Thielemann wrote: On Thu, 17 Aug 2006, Brian Smith wrote: I find it strange that right now almost every Haskell program directly or indirectly (through FPTOOLS) depends on CPP, yet there is no effort to replace CPP with something better or standardize its usage in Haskell. I think there should be more effort to avoid CPP completely.I agree, especially as I'm trying to write an editor for Haskell which will certainly not cope with CPP at all! ;-)I agree with this sentiment. But, CPP also has some advantages over the other suggestions presented here. Using CPP, we can create libraries that work with GHC 5.x and old versions of Hugs. If an alternative to CPP were chosen, would we update fptools to use this alternative? If it involves new syntax, then updating FPTOOLS to use the new syntax would break backward compatibility. And, if (the vast majority of) FPTOOLS does not use the solution then it is not useful. The reason it would not cope is that CPP turns what would otherwise be one program/module/library into several programs/modules/libraries whichsimultaneously co-exist in the same text in a rather uneasy and vaguerelationship, and what's even worse: the same module can have multiple meanings in the *same* program depending on use of #ifdef #undef etc, thusmaking code navigation quite impossible: the meaning of each module nowdepends on how you got there and might even be different the second time round...Notice that with my suggestions none of these problems apply, because all external command line parameters have a single static value over the whole program (two modules cannot depend on differing values of a single macro, #undef is not allowed). Changing the bindings for these macros would invalidate any cached information the editor has. But, the editor has to support updating its caches anyway, to deal with switching libraries in/out, etc. I won't use an IDE effectively if it can't handle the libraries in FPTOOLS, which liberally use the preprocessor. Either the IDE has to handle the preprocessor or the libraries have to stop using them, or they have to meet somewhere in the middle. I think the acid test would be to reach a point where anyone can download the source for some large program such as GHC and just type ghc --make Main and expect the program to be built in one pass with no problems.I agree with this sentiment as well. Most of the little data processing programs I have written are built exactly like that already. How can we get the existing libraries to build like that though? - Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Description of Haskell extensions used by FPTOOLS
Simon,I am familiar with the GHC library as I had used it a year or so ago to create a very cheap Haddock knockoff. I used the GHC library to do the type inference (which Haddock didn't do at the time) and to deal with elements that didn't have source code available. I remember that I created it specifically because I couldn't get Haddock to work on the GHC API in a useful way. I am looking forward to the result of the SoC project. IIRC, the GHC API needs to be modified to provide (better) support for parsing and typechecking code with syntax errors. That is something that I can probably do when I get to that point.Even if a tool is implemented using the GHC library, it is likely that it would need to limit itself to some subset of GHC's features. For example, an IDE that had a define instance feature would need special code to deal with associated types. Similarly, it is better for a tool to refuse to operate on code using implicit parameters rather than (silently) fail to handle them properly, because people tend to hate tools that are really convenienty but occasionally mess up their programs. Regards, BrianOn 8/18/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Brian Great! You might like to consider using GHC as a library http://haskell.org/haskellwiki/GHC/As_a_library The advantage is that you just import GHC and then you can parse all of Haskell (including GHC's extensions). Then you can rename it to resolve lexical scopes, typecheck, and so on. It will certainly deal with all of Darcs… because GHC compiles Darcs. It's all supposed to be a good basis for tools that consume and analyse Haskell programs, which is exactly what you propose to do. Example, there's a summer-of-code project to use it for Haddock. That said, the API is really just what we needed to build GHC itself. It needs a serious design effort. One of the things that would motivate such an effort would be customers saying I needed to do X with the API and it was inconvenient/impossible. Still, it does work, today. Simon From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Brian Smith Sent: 17 August 2006 17:01 To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Description of Haskell extensions used by FPTOOLS Is there any design document for the FPTOOLS libraries or some description of language features that are (allowed to be) used in them? I am going to be taking some significant time off from my normal jobs in the upcoming months. During part of that time, I would like to do some work to improve the Haskell toolchain. This involves creating or improving tools that parse and analyze Haskell code. My goal is to have these tools support enough of Haskell to be able to handle at least the most important libraries used by Haskell programmers. In particular, this includes all or most of the libraries in FPTOOLS. Plus, I want these tools to operate on Darcs as it is an obvious poster-child for Haskell. Thus, I need to support Haskell 98 plus all the extensions being used in Darcs and FPTOOLS as of approx. March, 2007 (as I intened to start working again at that time). It would be very nice if there was some document that described Haskell 98 plus all the extensions being used in Darcs and FPTOOLS as of March, 2007. Besides being useful to me, it would be a useful guide for potential contributors to FPTOOLS. Regards, Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
