Re: [GHC] #1541: No way at all to set fixity for infix operators defined in template haskell
#1541: No way at all to set fixity for infix operators defined in template haskell -+-- Reporter: guest |Owner: Type: bug | Status: new Priority: normal|Milestone: 6.10 Component: Template Haskell | Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | -+-- Changes (by simonpj): * milestone: 6.8 = 6.10 Comment: This seems like a reasonable feature request. Would anyone like to tackle it? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1541 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1330: Impredicativity bug: Church2 test gives a rather confusing error with the HEAD
#1330: Impredicativity bug: Church2 test gives a rather confusing error with the HEAD +--- Reporter: igloo|Owner: simonpj Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Church2 Architecture: Unknown | +--- Changes (by simonpj): * summary: Church2 test gives a rather confusing error with the HEAD = Impredicativity bug: Church2 test gives a rather confusing error with the HEAD -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1330 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1522: Make [n..] etc syntax rebindable
#1522: Make [n..] etc syntax rebindable +--- Reporter: guest|Owner: simonpj Type: feature request | Status: new Priority: normal |Milestone: 6.10 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | +--- Changes (by simonpj): * owner: = simonpj * type: bug = feature request Comment: The manual does not claim that this works. It's a perfectly reasonable feature request though. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1522 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1571: type of synthesize in Data.Generics.Schemes is too restrictive
#1571: type of synthesize in Data.Generics.Schemes is too restrictive --+- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base |Version: 6.6.1 Severity: normal | Keywords: synthesize,syb Difficulty: Easy (1 hr) | Os: Linux Testcase: | Architecture: x86 --+- The type of the synthesize function in Data.Generics.Schemes is unnecessarily restrictive. It's current type is synthesize :: s - (s - s - s) - GenericQ (s - s) - GenericQ s but it would be more useful if it were synthesize :: s - (t - s - s) - GenericQ (s - t) - GenericQ t Below is a contrived example demonstrating why one might want the more liberal type. module Main where import Data.Generics synthesize' :: s - (t - s - s) - GenericQ (s - t) - GenericQ t synthesize' z o f x = f x (foldr o z (gmapQ (synthesize' z o f) x)) -- The toTree function fails to type if synthesize' is replaced -- with synthesize. data ConstructorTree = ConstructorTree String [ConstructorTree] deriving (Show) toTree :: Data a = a - ConstructorTree toTree = synthesize' [] (:) (\a s - ConstructorTree (showConstr (toConstr a)) s) data Foo = Bar String | Baz Foo Int deriving (Data,Typeable) main = print (toTree (Baz (Bar 12) 5)) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1571 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Annotation for unfolding wanted
| I was wondering why we don't have an annotation or pragma for function to tell
| the compiler that we _need_ this particular recursive function to be unfolded.
| If the compiler cannot do this for some reason it should produce an error
| message to help you modifying your code. I have regularly problems that my
| code is either not strict enough or my functions are not unfolded. I find it
| annoying that this is a regular show stopper and consumes much time to fix.
| Here is an example: a search function for strings, which should return the
| index and the rest of the string after the first occurrence: search0 will not
| be unfolded by ghc -O even with {#- INLINE search0 -#} (I don't know why, it
| looks tail-recursive to me)
GHC never inlines recursive functions. Why not? Because doing so exposes a
new inline opportunity. How many times would you like it inlined? Not
forever, I assume!
Some compilers unroll recursive functions by inlining them N times, for some
fixed N (say 3 or so). This reduces the loop overheads. GHC doesn't do this,
although it'd be nice, because it makes repeated traversals of the code, and
it's hard to spot when the function has been unrolled 3 times and then stop.
If you look at the code after unrolling 3 times, from scratch, there's another
call just waiting to be inlined.
I'm not saying this couldn't be improved -- but I don't see an easy way to
improve it.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: Annotation for unfolding wanted
Hello Simon, Tuesday, July 31, 2007, 1:22:14 PM, you wrote: GHC never inlines recursive functions. Why not? Because doing so exposes a new inline opportunity. How many times would you like it inlined? Not forever, I assume! really, state of things in this area is not pleasant. making polymorphic function recursive kills the performance because it's no more inlined nor specialized - it may be called only with real dictionary. because i'm wrote polymorphic i/o library, i had many situations when in rare cases functions should call itself recursively like this: getChar = if bufferEmpty then fillBuffer; getChar else return *p++ (sorry for some pseudocode) and it was very inefficient. at the last end, i was need to create special functions to handle recursive calls and call it when buffer empty so that main function becomes non-recursive: getChar = if bufferEmpty then getChar' else return *p++ getChar' = fillBuffer; getChar it will be great if specifying INLINE for recursive function will mean that it should be inlined at least once and then call to non-polymorphic specialized version should be made. at least it will be ideal for code like this -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Ticky Ticky profiling
Hi all!. I modified build.mk in order to allow Ticky-Ticky profiling (GhcLibWays=t). Now, when I try to make I get this error: == make way=t all; PWD = (the_whole_path)/ghc-6.6.1/rts ../compiler/ghc-inplace -H32m -O -fasm -W -fno-warn-unused-matches -fwarn-unused-imports -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -hisuf t_hi -hcsuf t_hc -osuf t_o -ticky -#include posix/Itimer.h -c PrimOps.cmm -o PrimOps.t_o ghc-6.6.1: panic! (the 'impossible' happened) (GHC version 6.6.1 for i386-unknown-linux): ToDo: tickyAllocThunk Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Any clue? Thanks in advance. Cristian Perfumo. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Annotation for unfolding wanted
| However my point was more on a semantic point of view: If I write a function | in a recursive way, but actually do nothing else than a loop, I would like | a) that the compiler unrolls it to a loop and | b) that I can specify such a requirement, while violating it emits an error. What does it mean to say the compiler unrolls it to a loop. If GHC sees a tail recursive function, it certainly compiles it to a loop! (But that's not called unrolling.) Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Annotation for unfolding wanted
On Jul 31, 2007, at 10:20 AM, Simon Peyton-Jones wrote:
| However my point was more on a semantic point of view: If I write
a function
| in a recursive way, but actually do nothing else than a loop, I
would like
| a) that the compiler unrolls it to a loop and
| b) that I can specify such a requirement, while violating it
emits an error.
What does it mean to say the compiler unrolls it to a loop. If
GHC sees a tail recursive function, it certainly compiles it to a
loop! (But that's not called unrolling.)
I think what's meant here is translating something like this:
{-# INLINE f #-}
f x y z = ... f x' y' z' ...
into this:
{-# INLINE f #-}
f x y z = f' x y z
where f' x y z = ... f' x' y' z' ...
That is, shoving (all of) the recursion in a level. Then inlining f
results in a fresh loop, which presumably can be specialized or
optimized in various ways. I did this in pH, mostly because it was
less irritating than performing the same transformation by hand on
key bits of the Prelude. Whether it's actually beneficial on a large
scale probably depends on the effectiveness of transformations that
can specialise f' to the site where it was inlined; invariant
argument elimination comes to mind here, and I never did a good job
with that. It does remove one irritant from performance tuning,
though, by letting us write a simple top-level recursive function and
have it inlined.
-Jan
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Annotation for unfolding wanted
On Tue, 2007-07-31 at 10:36 -0400, Jan-Willem Maessen wrote:
I think what's meant here is translating something like this:
{-# INLINE f #-}
f x y z = ... f x' y' z' ...
into this:
{-# INLINE f #-}
f x y z = f' x y z
where f' x y z = ... f' x' y' z' ...
That is, shoving (all of) the recursion in a level. Then inlining f
results in a fresh loop, which presumably can be specialized or
optimized in various ways.
This transformation is critical for performance of foldr and foldl(').
The versions in GHC's libraries are manually written in the latter
style.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Annotation for unfolding wanted
| {-# INLINE f #-}
| f x y z = ... f x' y' z' ...
|
| into this:
|
| {-# INLINE f #-}
| f x y z = f' x y z
| where f' x y z = ... f' x' y' z' ...
|
| That is, shoving (all of) the recursion in a level. Then inlining f
| results in a fresh loop, which presumably can be specialized or
| optimized in various ways.
|
| This transformation is critical for performance of foldr and foldl(').
| The versions in GHC's libraries are manually written in the latter
| style.
It's important if and only if one or more of the parameters is static -- that
is, passed on unchanged. HTis is not the case in the example above. If you have
g x y z = (g x y' z') x...
then indeed it's sometimes a good plan to transform to
g x y z = g' y z
where
g' y z = (g' y' z')...x
because now you can inline g, and thereby specialise for the value of x at the
call site. This is esp good if x is a function.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Ticky Ticky profiling
On 7/31/07, Cristian Perfumo [EMAIL PROTECTED] wrote: Hi all!. I modified build.mk in order to allow Ticky-Ticky profiling (GhcLibWays=t). Now, when I try to make I get this error: == make way=t all; PWD = (the_whole_path)/ghc-6.6.1/rts ../compiler/ghc-inplace -H32m -O -fasm -W -fno-warn-unused-matches -fwarn-unused-imports -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -hisuf t_hi -hcsuf t_hc -osuf t_o -ticky -#include posix/Itimer.h -c PrimOps.cmm -o PrimOps.t_o ghc-6.6.1: panic! (the 'impossible' happened) (GHC version 6.6.1 for i386-unknown-linux): ToDo: tickyAllocThunk Hi, Cristian-- To get ticky to work, you need the HEAD (or a recent nightly build snapshot). If it's still not working after that, post again. Cheers, Tim -- Tim Chevalier* catamorphism.org *Often in error, never in doubt More than at any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly.--Woody Allen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] 3-yr post for language person
Tim Griffin is advertising a 3-year research associate position at the Cambridge Computer Lab, working on a project that seeks to design and implement a meta-language for the specification and implementation of correct Internet routing protocols. He says A PL person would be perfect. Details here: http://www.admin.cam.ac.uk/offices/personnel/jobs/vacancies.cgi?job=2114 Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] type class instance selection search
I keep running into situations in which I want more powerful search in selecting type class instances. One example I raised in June, in which all of the following instances are useful. instance (Functor g, Functor f) = Functor (O g f) where fmap h (O gf) = O (fmap (fmap h) gf) instance (Cofunctor g, Cofunctor f) = Functor (O g f) where fmap h (O gf) = O (cofmap (cofmap h) gf) instance (Functor g, Cofunctor f) = Cofunctor (O g f) where cofmap h (O gf) = O (fmap (cofmap h) gf) instance (Cofunctor g, Functor f) = Cofunctor (O g f) where cofmap h (O gf) = O (cofmap (fmap h) gf) My understanding is that this sort of instance collection doesn't work together because instance selection is based only on the matching the head of an instance declaration (part after the =). I'm wondering why not use the preconditions as well, via a Prolog-like, backward-chaining search for much more flexible instance selection? Going further, has anyone investigated using Prolog as a model for instance selection? Better yet, how about LambdaProlog ( http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), which generalizes from Horn clauses to (higher-order) hereditary Harrop formulas, including (restricted but powerful) universals, implication, and existentials? Once search is in there, ambiguity can arise, but perhaps the compiler could signal an error in that case (i.e., if the ambiguity is not eliminated by further search pruning). My motivation: I've been playing with a programming style in which my type formulation leads to automatic construction of much of the code, thanks to use of Functor, Applicative, Monoid, and type composition. An example is http://haskell.org/haskellwiki/Applicative_data-driven_programming, and I'm trying now to do the same to create a much simpler implementation of Eros ( http://conal.net/papers/Eros). I think this programming style is what Conor was alluding to recently as types don't just contain data, types explain data (http://article.gmane.org/gmane.comp.lang.haskell.cafe/26520). (Conor: I hope you chime in.) My hunch is that this programming style tends to run up against the head-only instance matching mechanism and would work much better with a more powerful means of selecting instances. - Conal ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: type class instance selection search
Conal Elliott [EMAIL PROTECTED] wrote in article [EMAIL PROTECTED] in gmane.comp.lang.haskell.general: I keep running into situations in which I want more powerful search in selecting type class instances. I agree that it's quite useful for instance search to backtrack, if not desirable in all cases. Proof search is program search, after all. Of course, allowing undecidable instances, we can build backtracking into instance search ourselves by representing the state of a backtracking machine as a type. http://okmij.org/ftp/Haskell/poly2.txt -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig And if thou gaze into the abyss, the abyss...actually finds you pretty creepy. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: type class instance selection search
Here are some other instances that could work with backward chaining:
\begin{code}
instance Monad m = Applicative m where
pure = return
(*) = ap
instance (Applicative f, Monoid a) = Monoid (f a) where
mempty = pure mempty
mappend = liftA2 mappend
instance (Applicative f, Num a) = Num (f a) where
(+) = liftA2 (+)
fromInteger = pure . fromInteger
-- etc
\end{code}
Currently, I place such instance declarations in comments as boilerplate to
be instantiated manually. - Conal
On 7/31/07, Conal Elliott [EMAIL PROTECTED] wrote:
I keep running into situations in which I want more powerful search in
selecting type class instances. One example I raised in June, in which all
of the following instances are useful.
instance (Functor g, Functor f) = Functor (O g f) where
fmap h (O gf) = O (fmap (fmap h) gf)
instance (Cofunctor g, Cofunctor f) = Functor (O g f) where
fmap h (O gf) = O (cofmap (cofmap h) gf)
instance (Functor g, Cofunctor f) = Cofunctor (O g f) where
cofmap h (O gf) = O (fmap (cofmap h) gf)
instance (Cofunctor g, Functor f) = Cofunctor (O g f) where
cofmap h (O gf) = O (cofmap (fmap h) gf)
My understanding is that this sort of instance collection doesn't work
together because instance selection is based only on the matching the head
of an instance declaration (part after the =). I'm wondering why not use
the preconditions as well, via a Prolog-like, backward-chaining search for
much more flexible instance selection? Going further, has anyone
investigated using Prolog as a model for instance selection? Better yet,
how about LambdaProlog (
http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), which
generalizes from Horn clauses to (higher-order) hereditary Harrop formulas,
including (restricted but powerful) universals, implication, and
existentials? Once search is in there, ambiguity can arise, but perhaps the
compiler could signal an error in that case ( i.e., if the ambiguity is
not eliminated by further search pruning).
My motivation: I've been playing with a programming style in which my type
formulation leads to automatic construction of much of the code, thanks to
use of Functor, Applicative, Monoid, and type composition. An example is
http://haskell.org/haskellwiki/Applicative_data-driven_programming, and
I'm trying now to do the same to create a much simpler implementation of
Eros ( http://conal.net/papers/Eros). I think this programming style is
what Conor was alluding to recently as types don't just contain data, types
explain data (http://article.gmane.org/gmane.comp.lang.haskell.cafe/26520).
(Conor: I hope you chime in.) My hunch is that this programming style tends
to run up against the head-only instance matching mechanism and would work
much better with a more powerful means of selecting instances.
- Conal
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: type class instance selection search
Thanks for these pointers, Ken. And belated thanks to Oleg for his reply in June. Impressive tricks! Perhaps I'm not the only person who'd prefer a more straightforward formulation of backtracking search? Cheers, - Conal On 7/31/07, Chung-chieh Shan [EMAIL PROTECTED] wrote: Conal Elliott [EMAIL PROTECTED] wrote in article [EMAIL PROTECTED] in gmane.comp.lang.haskell.general: I keep running into situations in which I want more powerful search in selecting type class instances. I agree that it's quite useful for instance search to backtrack, if not desirable in all cases. Proof search is program search, after all. Of course, allowing undecidable instances, we can build backtracking into instance search ourselves by representing the state of a backtracking machine as a type. http://okmij.org/ftp/Haskell/poly2.txt -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig And if thou gaze into the abyss, the abyss...actually finds you pretty creepy. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: type class instance selection search
Hello, My understanding is that this sort of instance collection doesn't work together because instance selection is based only on the matching the head of an instance declaration (part after the =). I'm wondering why not use the preconditions as well, via a Prolog-like, backward-chaining search for much more flexible instance selection? Going further, has anyone investigated using Prolog as a model for instance selection? I have also wanted more powerful, Prolog-like search for instance selection; it would be particularly convenient to think of type variables as logic variables. I think the main argument against this is that it fundamentally changes the interpretation of constraints; in particular, if you really used a Prolog-style search, the order in which you place constraints can affect type checking. Is there a sensible way for instance selection to depend on the body which doesn't result in this? Better yet, how about LambdaProlog ( http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), which generalizes from Horn clauses to (higher-order) hereditary Harrop formulas, including (restricted but powerful) universals, implication, and existentials? Having hereditary Harrop formulas at the type level would be cool. It would also probably require type level lambdas. There was a recent discussion about type level lambdas in Haskell which ended with the observations that 1) it would mess up unification (i.e. make it undecidable and/or too hard) to have explicit type level lambdas; and 2) they are already implicitly there (this was pointed out by Oleg) since one can define a type level application and type level functions. I think 1) is a bit of a cop-out since you could always restrict to pattern unification (L-lamda unification) which is decidable and has MGUs. 2) is true, but these implicit lambdas don't play very well with instance selection and require that all reductions are spelled out via an Apply type class. I think it might be useful/interesting to have type level lambdas, and pattern unification, even without turning instance selection into proof search. Once search is in there, ambiguity can arise, but perhaps the compiler could signal an error in that case ( i.e., if the ambiguity is not eliminated by further search pruning). This seems like a slippery slope to me. Although I would like having a full fledged (higher-order) logic programming language in which to write type level programs, I am not sure it's a good idea for Haskell in general. I tend to get concerned when type class constraints get too big/complicated to be obviously correct-- what good is the type checker saying something satisfies a constraint if we're not sure that the specification of the constraint itself is correct? -Jeff ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Type Lambdas in Gofer
The code in Bananas in Space: Extending Fold and Unfold to Exponential Types http://citeseer.ist.psu.edu/293490.html mirror: http://www.cs.nott.ac.uk/~gmh/bananas.pdf uses Gofer, and has examples such as data Rec f = In (f (Rec f)) type P f a = f (Rec f, a) mapP :: Functor f = (a - b) - P f a - P f b mapP g = fmap (\(x,a) - (x, g a)) instance Functor f = Functor (P f) where fmap = mapP Why did Gofer have this power while Haskell does not? Jim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type Lambdas in Gofer
Jim Apple wrote: data Rec f = In (f (Rec f)) type P f a = f (Rec f, a) mapP :: Functor f = (a - b) - P f a - P f b mapP g = fmap (\(x,a) - (x, g a)) instance Functor f = Functor (P f) where fmap = mapP Why did Gofer have this power while Haskell does not? Haskell does have the same power as Gofer, it simply does not allow you to define instances for type synonyms (just in order to prevent overlapping instances, I guess). If you use a newtype instead of a type synonym everything works fine: data Rec f = In (f (Rec f)) newtype P f a = P (f (Rec f, a)) unP (P x) = x mapP :: Functor f = (a - b) - P f a - P f b mapP g = P . fmap (\((x,a)) - (x, g a)) . unP instance Functor f = Functor (P f) where fmap = mapP Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: infinite list of random elements
Chad Scherrer wrote: I prefer the purely functional approach as well, but I've been bitten several times by laziness causing space leaks in this context. I'm on a bit of a time crunch for this, so I avoided the risk. Well, space leaks won't magically disappear if you use IO a . Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Definition of the Haskell standard library
| On the other hand, it's not entirely true that there's no standard | library, it's just that it's borders are slightly fuzzy. For example, we | do have the library change submission process for modifying the standard | libraries. Up until now that has been taken to mean changes to the base | package. That package is now being split up, so we'll have to think | about what it'll apply to in the future. | | My opinion is that in the past it has been too difficult to get changes | into the base library, that there's been too much stability at the | expense of improving scope and quality. Making it easy to install new | packages and upgrade existing standard libraries should make it easier | to trial more major changes outside of the standard libs before | proposing getting those changes integrated. All true, but not so helpful for Joe User. For Joe, I think it might be helpful to have some easily-discoverable notion of which package quality and stability. - Package X is blessed; lots of people have argued over its design, it's stable, widely used, and actively maintained. Changes to this package goes through a quality-control process. - Package Y is a bit specialised, but it's the result of work by a small group, and it's actively maintained. - Package Z is designed, written, and maintained by one person. That person has kindly put it on Hackage so that others may share it, but you probably don't want to rely on it unless you are happy to help maintain it. Then, in effect, the standard library is all the X packages. I wonder if it'd help to have some descriptions such as those above (better worded), and use them? Cabal already has a stability indication, and that might serve, but we'd want to articulate much more clearly what it meant. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RLE in Haskell: why does the type variable get instantiated?
Hey Haskell-Cafe, I was trying out the code in Dons's article [1], and I noticed a weird thing when doing it in GHCi. When binding the function composition to a variable, the type suddenly changes. I'm not completely sure why this happens. Is this because GHCi is in a monad and wants to find an instance for the type variable? Here's my GHCi session: Prelude :m +Control.Arrow Prelude Control.Arrow :m + List Prelude Control.Arrow List :t map (length head) . group map (length head) . group :: (Eq a) = [a] - [(Int, a)] Prelude Control.Arrow List let encode = map (length head) . group Prelude Control.Arrow List :t encode encode :: [Integer] - [(Int, Integer)] Thanks, -chris [1]: http://cgi.cse.unsw.edu.au/~dons/blog/2007/07/31 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RLE in Haskell: why does the type variable get instantiated?
Chris Eidhof wrote: When binding the function composition to a variable, the type suddenly changes. Prelude Control.Arrow List :t map (length head) . group map (length head) . group :: (Eq a) = [a] - [(Int, a)] Prelude Control.Arrow List let encode = map (length head) . group Prelude Control.Arrow List :t encode encode :: [Integer] - [(Int, Integer)] You've tripped over the Monomorphism Restriction. http://haskell.org/haskellwiki/Monomorphism_restriction http://haskell.org/onlinereport/decls.html#sect4.5.5 In short, you have to supply a type signature encode :: (Eq a) = [a] - [(Int, a)] encode = map (length head) . group to get the polymorphic function type when type-classes like Eq or especially Num are involved. Without signature, the compiler will _default_ some the type variables mentioned in the class context to Integer or similar. Note that definitions on the GHCi prompt will receive more defaulting than those in Haskell source files. This is to make things like show [] 1+5 work at the prompt. Also note that the monomorphism restriction only applies to constant applicative forms, i.e. point-free definitions of values. In other words, encode x = map (length head) . group $ x will result in the proper polymorphic type. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Definition of the Haskell standard library
* Simon Peyton-Jones wrote: Then, in effect, the standard library is all the X packages. I wonder if it'd help to have some descriptions such as those above (better worded), and use them? Cabal already has a stability indication, and that might serve, but we'd want to articulate much more clearly what it meant. You need an external indicator, not an indicator from the package author. It might be interesting to transform the dependency graph of cabalized packaged at hackage into a ranking indicator. It's like the Google Pagerank: Same benefit, same illness. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC Laziness (was Re: HDBC or HSQL)
On Mon, 30 Jul 2007 00:56:30 +0200, John Goerzen [EMAIL PROTECTED] wrote: I have heard from a number of people that this behavior is not very newbie-friendly. I can see how that is true. I have an API revision coming anyway, so perhaps this is the time to referse the default laziness of HDBC calls (there would be a '-version of everything with laziness enabled, still). Thoughts? I would like the libraries as stable as possible; it seems to me that, if you make the functions strict, there should be a new set of functions for this. This prevents a lot of work on existing applications. I get the impression that the bit rot rate is very high for Haskell applications. -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RLE in Haskell: why does the type variable get instantiated?
On 31-jul-2007, at 11:38, Chris Eidhof wrote: Hey Haskell-Cafe, I was trying out the code in Dons's article [1], and I noticed a weird thing when doing it in GHCi. When binding the function composition to a variable, the type suddenly changes. I'm not completely sure why this happens. Is this because GHCi is in a monad and wants to find an instance for the type variable? Yes, that is mostly correct. GHCi does defaulting of types, and in this case the type variable defaults to Integer. With regards, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Conditional compilation of Setup.hs
I'd like to add a #ifdef to Takusen's Setup.hs, so that we can have a single source file that will compile with ghc-6.6 and ghc-6.6.1. With ghc-6.6 and Cabal-1.1.6.1 we use splitFileName and joinPaths from Distribution.Compat.FilePath. With ghc-6.6.1 (which includes Cabal-1.1.6.2) these have been moved to System.FilePath. I'd like to do something like the following: #ifdef __CABAL_VERSION__ 117 import System.FilePath (splitFileName, combine) joinPaths = combine #else import Distribution.Compat.FilePath (splitFileName, joinPaths) #endif Is something like this possible with Cabal? It's either that, or make Takusen's install depend on filepath. I'm not sure which is the least desirable, but I'm open to suggestions. To be fair, we already require our ghc-6.6 users to upgrade Cabal from 1.1.6 to 1.1.6.1, so making them install filepath instead perhaps isn't so bad, and is no more effort. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Conditional compilation of Setup.hs
On Tue, 2007-07-31 at 13:46 +0100, Bayley, Alistair wrote: I'd like to add a #ifdef to Takusen's Setup.hs, so that we can have a single source file that will compile with ghc-6.6 and ghc-6.6.1. With ghc-6.6 and Cabal-1.1.6.1 we use splitFileName and joinPaths from Distribution.Compat.FilePath. With ghc-6.6.1 (which includes Cabal-1.1.6.2) these have been moved to System.FilePath. I'd like to do something like the following: #ifdef __CABAL_VERSION__ 117 import System.FilePath (splitFileName, combine) joinPaths = combine #else import Distribution.Compat.FilePath (splitFileName, joinPaths) #endif Is something like this possible with Cabal? No, Cabal does not define any cpp defines like that. It's either that, or make Takusen's install depend on filepath. I'm not sure which is the least desirable, but I'm open to suggestions. To be fair, we already require our ghc-6.6 users to upgrade Cabal from 1.1.6 to 1.1.6.1, so making them install filepath instead perhaps isn't so bad, and is no more effort. I'd got with filepath in that case. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Definition of the Haskell standard library
On Tue, 2007-07-31 at 10:15 +0100, Simon Peyton-Jones wrote: All true, but not so helpful for Joe User. For Joe, I think it might be helpful to have some easily-discoverable notion of which package quality and stability. - Package X is blessed; lots of people have argued over its design, it's stable, widely used, and actively maintained. Changes to this package goes through a quality-control process. - Package Y is a bit specialised, but it's the result of work by a small group, and it's actively maintained. - Package Z is designed, written, and maintained by one person. That person has kindly put it on Hackage so that others may share it, but you probably don't want to rely on it unless you are happy to help maintain it. Then, in effect, the standard library is all the X packages. Yes. I wonder if it'd help to have some descriptions such as those above (better worded), and use them? Cabal already has a stability indication, and that might serve, but we'd want to articulate much more clearly what it meant. I'm not sure that belongs in the cabal file, afterall, being blessed is a central community consensus thing, not a distributed decision taken by each person writing the cabal file for their package. I can't make a blessed package by just saying that it is so. So it's clear at the moment that the base package is blessed, changes to it go through the library submissions process. It's not so clear for the other packages that ghc has distributed and have often been taken to be the standard library. Many of them look more like Y's above (like parsec, regex-*). So yes, I think we should make this clear, and that blessed packages that are covered by the library submission process should be clearly recorded and publicised centrally. Even then though, I think Chris was looking for something slightly wider. For example ghc has distributed quite a range of packages that would probably not be classified as X above, eg OpenGL, GLUT, OpenAL, FGL, HGL, etc. These are not necessarily blessed packages but are known to be of a high quality (ok, except HGL). Chris wanted to know this to distinguish from the many other packages on hackage. What is not clear to me yet is if we should just rely on mechanisms in hackage to distinguish the gems from the failed experiments or something more centralised. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Conditional compilation of Setup.hs
Hello Duncan, Tuesday, July 31, 2007, 5:06:35 PM, you wrote: #ifdef __CABAL_VERSION__ 117 Is something like this possible with Cabal? No, Cabal does not define any cpp defines like that. фафшкб one of this year GSOC projects is Cabal sections impelementation which should allow to make parts of cabal files specific, for example, for windows and unix. may be this new feature will allow to check library version too? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Definition of the Haskell standard library
Chris Smith wrote: Can someone clarify what's going on with the standard library in Haskell? As of right now, I can download, say, GHC from haskell.org/ghc and get a set of libraries with it. I can visit http://haskell.org/ghc/docs/latest/html/libraries/, linked from the haskell.org home page, and see descriptions of all of those libraries. I can build with --make (or if I'm feeling masochistic, add several lines of -package options) and it works. That's all great. I've seen some stuff lately on -libraries and this list indicating that there's an effort to change this. People asking whether something should be included in the standard library are being told that there is no standard library really. I'm hearing that the only distinction that matters is used by GHC or not used by GHC, and that being on hackage is as official as it gets. Am I misunderstanding? Is there something awesome about Hackage that I'm not seeing? My take on it is this: Hackage is a pre-requisite for a comprehensive well-maintained standard library. We don't have a comprehensive standard library yet, but from Hackage will emerge a large number of components that will someday be reviewed and filtered by a group of people who define the standard library. This might be part of the Haskell prime effort, or a subsequent library standardisation process. I agree that a standard library is important, I also believe it's vital that we have an effective distributed collaborative mechanism by which good libraries can emerge. In the early days of the hierarchical libraries I think we tried to define a defacto standard set of libraries which we shipped with the various compilers; I now believe the distributed model will achieve better results in the long run, and the rate at which Hackage is growing seems to back this up. This is why we developed the package system and Cabal, and why we no longer have a single global module namespace - every package author has the right to independently choose what their modules are called. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Conditional compilation of Setup.hs
On Tue, 2007-07-31 at 17:20 +0400, Bulat Ziganshin wrote: Hello Duncan, Tuesday, July 31, 2007, 5:06:35 PM, you wrote: #ifdef __CABAL_VERSION__ 117 Is something like this possible with Cabal? No, Cabal does not define any cpp defines like that. фафшкб one of this year GSOC projects is Cabal sections impelementation which should allow to make parts of cabal files specific, for example, for windows and unix. may be this new feature will allow to check library version too? This allows conditional compilation in the library/program code but not in Setup.hs itself. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RLE in Haskell: why does the type variable get instantiated?
On 7/31/07, Chris Eidhof [EMAIL PROTECTED] wrote: Hey Haskell-Cafe, I was trying out the code in Dons's article [1], and I noticed a weird thing when doing it in GHCi. When binding the function composition to a variable, the type suddenly changes. I'm not completely sure why this happens. Is this because GHCi is in a monad and wants to find an instance for the type variable? Here's my GHCi session: [ ... ] Apfelmus already explained why it happens. I'd like to add one thing. If you are experimenting with GHCi, you can turn the restriction off with the option -fno-monomorphism-restriction. In GHCi itself this is given as follows: Prelude :set -fno-monomorphism-restriction After giving this and entering the same things as in your original message, the type of encode came out to be as follows: Prelude Control.Arrow Data.List let encode = map (length head) . group Prelude Control.Arrow Data.List :t encode encode :: (Eq a) = [a] - [(Int, a)] This option also saves some typing (of the variety you do on the keyboard!) when you just want to use GHCi as a calculator: Prelude Control.Arrow Data.List let x = 5 Prelude Control.Arrow Data.List let y = 6.3 Prelude Control.Arrow Data.List x*y 31.5 Instead of Integer, the type of x is now x :: (Num t) = t without the restriction, and I don't need to add fromInteger to the multiplication. I don't recommend you to use this option all the time, of course. It's just a convenience. Pekka ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie question about automatic memoization
Bryan Burgers wrote: On 7/30/07, peterv [EMAIL PROTECTED] wrote: Does Haskell support any form of automatic memorization? For example, does the function iterate f x which expands to [x, f(x), f(f(x)), f(f(f(x))), … gets slower and slower each iteration, or can it take advantage of the fact that f is referentially transparent and hence can be memoized / cached? Thanks, Peter For 'iterate' the answer does not really need to be memoized. Or, another way of phrasing that answer is 'yes'. The definition of iteration does memoize - although normally one would say 'share' - the intermediate results. I imagine the definition of 'iterate' looks something like this: iterate f x = x : iterate f (f x) Haskell doesn't automatically memoize. But you are entitled to assume that named values are 'shared' rather than calculated twice. For example, in the above expression x, being a named value, is shared between (a) the head of the list and (b) the parameter of the function f inside the recursive call to iterate. Of course sharing x may not seem very interesting, on the outermost call, but notice that on the next call the new x is the old f x, and on the call after that the new x is f (f x) w.r.t the original x. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: Definition of the Haskell standard library
On Tue, 2007-07-31 at 10:15 +0100, Simon Peyton-Jones wrote: - Package X is blessed; lots of people have argued over its design, it's stable, widely used, and actively maintained. Changes to this package goes through a quality-control process. Then, in effect, the standard library is all the X packages. Duncan Coutts [EMAIL PROTECTED] wrote: I'm not sure that belongs in the cabal file, afterall, being blessed is a central community consensus thing, not a distributed decision taken by each person writing the cabal file for their package. I can't make a blessed package by just saying that it is so. Yes, pretty much. The ideas mentioned in this thread for Hackage sound great. I definitely was missing a lot there, as I thought of Hackage as just somewhere people could upload their libraries. If there could be built-in quality control in promoting certain packages, that would be great. Even greater would be if: 1. Hackage tracked which packages had this blessed status. 2. There were a simple automated way, as part of the GHC install or otherwise immediately visible without knowing about it ahead of time, to download the whole set and install them. 3. There were either (a) a single URL that can be used to see documentation for all of them without worrying about which package something is in first; or (b) something like Cabal's haddock and install steps would combine documentation for all installed packages into a single URL; or even better, (c) both. I see it as a really big deal that documentation becomes fragmented when one is using many packages, so that it's harder to find what you want. In fact, I'd classify that as the single biggest reason that I don't use many packages now; they aren't documented at http://haskell.org/ghc/docs/latest/html/libraries/, and it's a pain to keep open several windows with documentation for different libraries. (I already have done it a lot for gtk2hs and happs, but at least it's a Big Deal to be using those, so one can justify the extra window!) So it's clear at the moment that the base package is blessed, changes to it go through the library submissions process. It's not so clear for the other packages that ghc has distributed and have often been taken to be the standard library. Many of them look more like Y's above (like parsec, regex-*). I've always thought of at least these packages in the existing standard library as being pretty stable: base, arrows, stm, mtl, Cabal, haskell-src, template-haskell, network, process, directory, filepath, unix, random, parsec, and pretty. Perhaps my perception has been skewed... but given how often these things are recommended, I'd hope they are stable. Even then though, I think Chris was looking for something slightly wider. I'm not entirely sure I can articulate precisely what I'm looking for. It sounds like things are going in a reasonable direction. I'll try to get my head around it, and see if I can pitch in somehow. I was simply worried that from an outsider's perspective, several recent comments in various mailing list threads, IRC dicussions, etc. seemed to predict the demise of any standard library except for base -- which would be quite disturbing given that base is becoming smaller, not larger, over time. What is not clear to me yet is if we should just rely on mechanisms in hackage to distinguish the gems from the failed experiments or something more centralised. Good question. I would guess the best way to answer it is to simultaneously establish something centralized in the short term, and then try to develop the technological structures to make it obsolete. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Operational Semantics of Haskell
Hi Is there a good source for the operational semantics of Haskell? I am trying to squeeze the most efficiency out of a bit of code and am looking to remove unnecessary reductions. You probably aren't after operational semantics - the compiler takes your code and optimises it to something bearing little relation to the original. Are you passing -O2? Have you read the performance wiki page? http://haskell.org/haskellwiki/Performance Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On Tue, Jul 31, 2007 at 09:16:33AM -0600, Chris Smith wrote: If there could be built-in quality control in promoting certain packages, that would be great. it needs to be more fine grained. a new version of a package may indeed rollback some positive attributes (stability for example) that a previous version demonstrated...perhaps intentionally (when an author is choosing to break an api, etc), perhaps not (plain old bugs) we already have quality claims of two kinds for hackage packages: implicit (version number, 0.* indicating lack of maturity) and explicit (stability: experimental, stable, etc). allowing two scores to be maintained for stability - author score AND audience score, seems like a good way of moderating claims. simply allow people with haskell.org accounts to select a pulldown in the package listing with options for the stability score, with obvious safety features (one vote per account per package version, etc) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] RE: Definition of the Haskell standard library
| I see it as a really big deal that documentation becomes fragmented when | one is using many packages, so that it's harder to find what you want. | In fact, I'd classify that as the single biggest reason that I don't use | many packages now When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On Tue, Jul 31, 2007 at 05:26:31PM +0100, Simon Peyton-Jones wrote: | I see it as a really big deal that documentation becomes fragmented when | one is using many packages, so that it's harder to find what you want. | In fact, I'd classify that as the single biggest reason that I don't use | many packages now When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect. I don't think that would be terribly hard. We would need to modify Haddock with the ability to generate links following a schema like /usr/share/doc/libghc6-$lowercasepackagename/html/$modulepath.html; this would be fairly easy with Haddock-GHC's ability to access package names and ghc-pkg haddock data, assuming Cabal and Haddock-GHC are fixed to work on the same system... Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] RE: Definition of the Haskell standard library
On Tue, 2007-07-31 at 17:26 +0100, Simon Peyton-Jones wrote: | I see it as a really big deal that documentation becomes fragmented when | one is using many packages, so that it's harder to find what you want. | In fact, I'd classify that as the single biggest reason that I don't use | many packages now When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect. The docs for those packages would be available for packages installed via cabal (assuming the user did the optional haddock step) and would link to each other. What is missing from the local docs is a single integrated index page that lists all the modules and then links off to the various packages's docs like we have on the ghc website. The problem with generating one of those is what manages it? What package would it belong to etc. On some systems (windows, gnome) there are dedicated help viewers that can help with this contents/index issue. haddock supports both (mshelp, devhelp). I'm not sure everyone would find that a sufficient solution however. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] RE: Definition of the Haskell standard library
Duncan Coutts [EMAIL PROTECTED] wrote:
What is missing from the local docs is a single integrated index page
that lists all the modules and then links off to the various packages's
docs like we have on the ghc website.
The problem with generating one of those is what manages it? What
package would it belong to etc.
Locally, I've kludged things together to add to the documentation
package that GHC builds. That may be the wrong place, but it kinda
works anyway. This script gets you much of the way there (with some
unfortunate line wrapping at the end that you'd have to fix). Of
course, the script does more than just build haddock; and there are
several other quirks here to that were needed to get random stuff to
work for some packages, and unfortunately there are a number of packages
for which it seems that 'runhaskell Setup haddock' just doesn't work at
all due to use of features in the source that haddock can't parse.
What it doesn't do is fix up the links to contents and index from the
other packages so that they point back to the right place.
-- begin attached script --
#!/bin/sh
ghcver=`ls -d /usr/local/lib/ghc-* | sort`
ghcver=`expr match $ghcver '.*\(ghc-6.7.[0-9]*\)'`
sudo rm /usr/local/lib/${ghcver}/share
sudo ln -s /usr/local/share /usr/local/lib/${ghcver}/share
sudo cp ../ghc/libraries/libraries-*.txt /usr/local/share/ghc/doc/html
for ln in `cat packages.list`
do
d=${ln:0:1}
p=${ln:1}
echo ===
echo == BUILDING: $p
echo ===
echo $d $p
cd $p || exit 1
if [ -d _darcs ]
then
darcs pull || exit 1
fi
if [ -f configure.in -o -f configure.ac ]
then
autoreconf || exit 1
fi
if [ -f Setup.hs -o -f Setup.lhs ]
then
runhaskell Setup clean || exit 1
runhaskell Setup configure || exit 1
runhaskell Setup build || exit 1
if [ $d = + ]
then
runhaskell Setup haddock --html-location=/usr/local/share/ghc \
|| exit 1
fi
sudo runhaskell Setup install|| exit 1
elif [ -f Makefile -o -f Makefile.in -o -f Makefile.am ]
then
if [ $d = + ]
then
echo Don't know how to run haddock
exit 1
fi
make distclean || true
./configure || exit 1
make || exit 1
sudo make install|| exit 1
else
echo Don't know how to make $p
exit 1
fi
cd ..
done
ls /usr/local/share/*/doc/html/*/haddock.css \
| grep -v '/usr/local/share/ghc' \
| sed 's/\(\/usr\/local\/share\/.*\/doc\/html\/\([^/]*\)\)
\/haddock.css/cp -r \1 \/usr\/local\/share\/ghc\/doc\/html\/\2 ; echo \2
\/usr\/local\/share\/ghc\/doc\/html\/\2\/prologue.txt/' \
| sudo /bin/sh
ls ../ghc/libraries/*/prologue.txt \
| sed 's/\(\.\.\/ghc\/libraries\/\([^\/]*\)\/prologue.txt\)/cp \1
\/usr\/local\/share\/ghc\/doc\/html\/\2/' \
| sudo /bin/sh
cd /usr/local/share/ghc/doc/html
sudo ./gen_contents_index
--
Chris Smith
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
The problem with generating one of those is what manages it? What package would it belong to etc. the same package that provides us with our interactive hackage prompt rebuilding a central index will be a logical post-process for the installation function ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem implementing an EDSL in Haskell
Hi Daniil, oops -- i just noticed this response from you from weeks ago. i'm guessing your question is all resolved for you by now. if not, please say so. cheers, - Conal On 6/25/07, Daniil Elovkov [EMAIL PROTECTED] wrote: Hi Conal 2007/6/24, Conal Elliott [EMAIL PROTECTED]: By embedded DSL, we usually mean identifying meta-language (Haskell) expressions with object language (DSL) expressions, rather than having an Exp data type. Then you just use meta-language variables as object-language variables. The new data types you introduce are then domain-oriented rather than language-oriented. Is there a reason that this kind of embedded approach doesn't work for you? Hmm, sorry, I must admit I didn't quite get it. However, in the situation I described, I don't just have an Exp data type, rather have it (and probably some other data types) typeful. Which lets me leverage the meta-language's (Haskell's) typing rules to enforce correctness of my DS language's expression correctness. I absolutely didn't want to make an accent on embedded. Sorry, if that introduced some confusion. And that's not important or principal to me, it's just how I called it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Newbie question about Haskell skills progress
Having only a couple of days of practice programming Haskell (but having read lots of books and docs), I find myself writing very explicit low level code using inner aux functions (accumulators and loops). Then I force myself to revise the code, replacing these aux functions with suitable higher-order functions from the library. However, I would like to use these higher order functions right away, without using low-level aux constructs, which is most likely caused by my very long history of imperative programming. Is this the normal way of progressing in Haskell, or should I consider a different approach? Thanks, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Newbie question about automatic memoization
Thanks! Is this is also the case when using let and where, or is this just syntactic sugar? -Original Message- From: Jules Bean [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 5:09 PM To: Bryan Burgers Cc: peterv; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Newbie question about automatic memoization Bryan Burgers wrote: On 7/30/07, peterv [EMAIL PROTECTED] wrote: Does Haskell support any form of automatic memorization? For example, does the function iterate f x which expands to [x, f(x), f(f(x)), f(f(f(x))), . gets slower and slower each iteration, or can it take advantage of the fact that f is referentially transparent and hence can be memoized / cached? Thanks, Peter For 'iterate' the answer does not really need to be memoized. Or, another way of phrasing that answer is 'yes'. The definition of iteration does memoize - although normally one would say 'share' - the intermediate results. I imagine the definition of 'iterate' looks something like this: iterate f x = x : iterate f (f x) Haskell doesn't automatically memoize. But you are entitled to assume that named values are 'shared' rather than calculated twice. For example, in the above expression x, being a named value, is shared between (a) the head of the list and (b) the parameter of the function f inside the recursive call to iterate. Of course sharing x may not seem very interesting, on the outermost call, but notice that on the next call the new x is the old f x, and on the call after that the new x is f (f x) w.r.t the original x. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie question about Haskell skills progress
On 31/07/07, peterv [EMAIL PROTECTED] wrote: Having only a couple of days of practice programming Haskell (but having read lots of books and docs), I find myself writing very explicit low level code using inner aux functions (accumulators and loops). Then I force myself to revise the code, replacing these aux functions with suitable higher-order functions from the library. However, I would like to use these higher order functions right away, without using low-level aux constructs, which is most likely caused by my very long history of imperative programming… Seems sensible to me! It'll come with time, I'm sure. I often find it useful to think about general abstractions and then choose an approach from there: - many-to-one - fold - many-to-many - map - one-to-many - unfold And so on in a similar fashion. This might mean you do something stupid (as witnessed by my most recent visit to Haskell Cafe, where I said some very silly things [1] but also got some enormously clever/silly pointers [2]). But it's all part of life's rich pattern, and I can't think of a nicer place to make a fool of one's self than in this community. [1]: http://www.haskell.org/pipermail/haskell-cafe/2007-July/029274.html [2]: http://www.haskell.org/pipermail/haskell-cafe/2007-July/029285.html Is this the normal way of progressing in Haskell, or should I consider a different approach? There are probably some people here who were imbibing type theory and lambda calculus with their mammy's milk... but for the rest of us, it's just one small step at a time. Cheers D. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Knuth Morris Pratt for Lazy Bytestrings implementation
I've implemented KMP string searching for lazy bytestrings, and I'd like some help improving the performance of the code. I'd also like to know if it doesn't look correct - I've tested it pretty extensively but you never know ... I've been testing on a 7 MB file, where the search sequence is not found. Using strict byestrings, lazy bytestrings, and regular strings, I've found my algorithm is about twice as slow as the strict version. Surprisingly, the strict version is a little bit *slower* than the regular strings version. Thanks for any comments or help! Justin KMPSeq.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious hxt error
brad clawsie wrote: i am having a problem with hxt, i was wondering if anyone here has experience with it. in particular, i find that the xread function chokes on xml files with xml declarations, and i am not sure why. [...] This is intended. Generally, wherever the HXT manual says content (e.g., the description of xread says with the XML content parser), it means the (one and only) top level element, i.e., the foo.../foo. To parse a complete XML file, look for a parser that says document, which means the whole thing, e.g., parseXmlDocument. main = do xml - getContents print $ head $ parseXmlDocument test.xml xml ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] infinite list of random elements
No leak in sight. -- Lennart import Random import Array randomElts :: RandomGen g = g - [a] - [a] randomElts _ [] = [] randomElts g xs = map (a!) rs where a = listArray (1, n) xs rs = randomRs (1, n) g n = length xs main = do g - getStdGen let xs = randomElts g [10,2,42::Int] print $ sum $ take 100 xs On 7/31/07, Chad Scherrer [EMAIL PROTECTED] wrote: Thanks for your responses. Stefan, I appreciate your taking a step back for me (hard to judge what level of understanding someone is coming from), but the example you gave doesn't contradict my intuition either. I don't consider the output [IO a] a list of tainted a's, but, as you suggest, a list of IO actions, each returning an a. I couldn't return an IO [a], since that would force evaluation of an infinite list of random values, so I was using [IO a] as an intermediary, assuming I'd be putting it through something like (sequence . take n) rather than sequence alone. Unfortunately, I can't use your idea of just selecting one, because I don't have any way of knowing in advance how many values I'll need (in my case, that depends on the results of several layers of Map.lookup). Also, I'm using GHC 6.6, so maybe there have been recent fixes that would now allow my idea to work. Cale, that's interesting. I wouldn't have thought this kind of laziness would work in this context. Lennart, I prefer the purely functional approach as well, but I've been bitten several times by laziness causing space leaks in this context. I'm on a bit of a time crunch for this, so I avoided the risk. Sebastian, this seems like a nice abstraction to me, but I don't think it's the same thing statistically. If I'm reading it right, this gives a concatenation of an infinite number of random shuffles of a sequence, rather than sampling with replacement for each value. So shuffles [1,2] g would never return [1,1,...], right? Chad I was thinking the best way to do this might be to first write this function: randomElts :: [a] - [IO a] randomElts [] = [] randomElts [x] = repeat (return x) randomElts xs = repeat r where bds = (1, length xs) xArr = listArray bds xs r = do i - randomRIO bds return (xArr ! i) Then I should be able to do this in ghci: sequence . take 5 $ randomElts [1,2,3] [*** Exception: stack overflow ___ 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] infinite list of random elements
Ok, that looks good, but what if I need some random values elsewhere in the program? This doesn't return a new generator (and it can't because you never get to the end of the list). Without using IO or ST, you'd have to thread the parameter by hand or use the State monad, right? This is where I was leaking space before. Actually, this makes me wonder... I think what killed it before was that the state was threaded lazily through the various (= very many) calls. I suppose a State' monad, strict in the state, could help here. I wonder how performance for this would compare with IO or ST. Might have to try that sometime... Chad On 7/31/07, Lennart Augustsson [EMAIL PROTECTED] wrote: No leak in sight. -- Lennart import Random import Array randomElts :: RandomGen g = g - [a] - [a] randomElts _ [] = [] randomElts g xs = map (a!) rs where a = listArray (1, n) xs rs = randomRs (1, n) g n = length xs main = do g - getStdGen let xs = randomElts g [10,2,42::Int] print $ sum $ take 100 xs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] infinite list of random elements
On Jul 31, 2007, at 16:20 , Chad Scherrer wrote: calls. I suppose a State' monad, strict in the state, could help here. You mean Control.Monad.State.Strict ? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] infinite list of random elements
On 7/31/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On Jul 31, 2007, at 16:20 , Chad Scherrer wrote: calls. I suppose a State' monad, strict in the state, could help here. You mean Control.Monad.State.Strict ? Umm, yeah, I guess I do. Glad I hadn't started recoding it! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem building lambdabot
Can anybody shout out about the latest version of ghc compatible with building lambdabot? http://www.cse.unsw.edu.au/~dons/lambdabot.html shows it working on 6.4.1. can it build under anything more recent? t. Stefan O'Rear [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/30/2007 11:59 PM To Michael Vanier [EMAIL PROTECTED] cc haskell-cafe@haskell.org haskell-cafe@haskell.org Subject Re: [Haskell-cafe] problem building lambdabot On Mon, Jul 30, 2007 at 08:54:12PM -0700, Michael Vanier wrote: So, now that I've got all the libraries installed, the compile fails like this: Building lambdabot-4.0... [13 of 91] Compiling Lib.Parser ( Lib/Parser.hs, dist/build/lambdabot/lambdabot-tmp/Lib/Parser.o ) Lib/Parser.hs:19:39: Module `Language.Haskell.Syntax' does not export `as_name' Lib/Parser.hs:19:48: Module `Language.Haskell.Syntax' does not export `qualified_name' Lib/Parser.hs:19:64: Module `Language.Haskell.Syntax' does not export `hiding_name' Lib/Parser.hs:19:77: Module `Language.Haskell.Syntax' does not export `minus_name' Lib/Parser.hs:19:89: Module `Language.Haskell.Syntax' does not export `pling_name' I'm using the latest darcs pull of lambdabot along with ghc 6.6.1. Anyone have any ideas? Thanks in advance for all the help, Mike Lambdabot is incompatible with GHC 6.6.1, because of changes in undocumented internal modules that lambdabot really shouldn't be importing in the first place. I had an idea for how to avoid the nasty dependency a few days ago, *tries to implement it*. Stefan [attachment signature.asc deleted by Thomas Hartman/ext/dbcom] ___ 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
Re: [Haskell-cafe] problem building lambdabot
Stefan just got it working yesterday with ghc 6.6.1 and sent me the patch. I imagine it'll be in the darcs repo soon if it isn't already. Mike Thomas Hartman wrote: Can anybody shout out about the latest version of ghc compatible with building lambdabot? http://www.cse.unsw.edu.au/~dons/lambdabot.html shows it working on 6.4.1. can it build under anything more recent? t. *Stefan O'Rear [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 07/30/2007 11:59 PM To Michael Vanier [EMAIL PROTECTED] cc haskell-cafe@haskell.org haskell-cafe@haskell.org Subject Re: [Haskell-cafe] problem building lambdabot On Mon, Jul 30, 2007 at 08:54:12PM -0700, Michael Vanier wrote: So, now that I've got all the libraries installed, the compile fails like this: Building lambdabot-4.0... [13 of 91] Compiling Lib.Parser ( Lib/Parser.hs, dist/build/lambdabot/lambdabot-tmp/Lib/Parser.o ) Lib/Parser.hs:19:39: Module `Language.Haskell.Syntax' does not export `as_name' Lib/Parser.hs:19:48: Module `Language.Haskell.Syntax' does not export `qualified_name' Lib/Parser.hs:19:64: Module `Language.Haskell.Syntax' does not export `hiding_name' Lib/Parser.hs:19:77: Module `Language.Haskell.Syntax' does not export `minus_name' Lib/Parser.hs:19:89: Module `Language.Haskell.Syntax' does not export `pling_name' I'm using the latest darcs pull of lambdabot along with ghc 6.6.1. Anyone have any ideas? Thanks in advance for all the help, Mike Lambdabot is incompatible with GHC 6.6.1, because of changes in undocumented internal modules that lambdabot really shouldn't be importing in the first place. I had an idea for how to avoid the nasty dependency a few days ago, *tries to implement it*. Stefan [attachment signature.asc deleted by Thomas Hartman/ext/dbcom] ___ 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
Re: [Haskell-cafe] problem building lambdabot
On Tue, Jul 31, 2007 at 04:46:30PM -0400, Thomas Hartman wrote: Can anybody shout out about the latest version of ghc compatible with building lambdabot? http://www.cse.unsw.edu.au/~dons/lambdabot.html shows it working on 6.4.1. can it build under anything more recent? It works under GHC 6.6.1, if you pull the patch that I sent yesterday. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Newbie question about automatic memoization
Hello peterv, Tuesday, July 31, 2007, 11:06:23 PM, you wrote: it is property of explicit *name* given to result of some expression. for example, when you write f x = g (x*x) (x*x) result of x*x isn't stored because it may be very large and compiler exactly follows your instruction - calculate x*x two times without trying to do optimization that may turn out to pessimization (of course, i mean that with *lazy* evaluation x*x is calculated only when needed and it may become a pessimization to save value between its usages as first and second argument) when you write f x = g t t where t=x*x compiler gets an instruction to calculate x*x only once and share calculated value between two parameters and it does just what you said Thanks! Is this is also the case when using let and where, or is this just syntactic sugar? -Original Message- From: Jules Bean [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 5:09 PM To: Bryan Burgers Cc: peterv; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Newbie question about automatic memoization Bryan Burgers wrote: On 7/30/07, peterv [EMAIL PROTECTED] wrote: Does Haskell support any form of automatic memorization? For example, does the function iterate f x which expands to [x, f(x), f(f(x)), f(f(f(x))), . gets slower and slower each iteration, or can it take advantage of the fact that f is referentially transparent and hence can be memoized / cached? Thanks, Peter For 'iterate' the answer does not really need to be memoized. Or, another way of phrasing that answer is 'yes'. The definition of iteration does memoize - although normally one would say 'share' - the intermediate results. I imagine the definition of 'iterate' looks something like this: iterate f x = x : iterate f (f x) Haskell doesn't automatically memoize. But you are entitled to assume that named values are 'shared' rather than calculated twice. For example, in the above expression x, being a named value, is shared between (a) the head of the list and (b) the parameter of the function f inside the recursive call to iterate. Of course sharing x may not seem very interesting, on the outermost call, but notice that on the next call the new x is the old f x, and on the call after that the new x is f (f x) w.r.t the original x. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exiting GLUT application
in old glut, the main loop was the core of the single threaded program. exiting it did mean to exit the program completely. in freeglut, you have alternatives. but for compatibility, it defaults to the old behaviour. http://haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT-Begin.html#v%3AExit - marc Am Dienstag, 31. Juli 2007 19:16 schrieb Dave Tapley: Hi everyone, I have the following skeleton GLUT code: import Graphics.UI.GLUT main = do getArgsAndInitialize createWindow mainLoop It loads into both hugs and ghci fine and when 'main' is evaluated an empty window opens as expected. However when closing the window (clicking the window manager's x button) both hugs and ghci exit with the window, as opposed to returning to the the 'Main' prompt. I suspect I need some callback to exit the GUI cleanly? Cheers, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe pgplzVStD22ul.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] View patterns in GHC: Request?for?feedback
On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
ChrisK [EMAIL PROTECTED] writes:
And the readability is destroyed because you cannot do any type inference in
your head.
If you see
{
Matrix m = ;
Matrix x = m * y;
...;
}
Then you know very little about the possible types of y
since can only conclude that:
[snippage] This is all very horrid, but as far as I can tell
what I was proposing wouldn't lead to such a mess, except
possibly via defaulting, which, as the least important
aspect of the idea could easily be abandoned.
What your suggestion would do would be to make the type inferred for every
pattern-matched function polymorphic, which means that in order to
determine the correctness of a function you'd need to examine all other
modules. Similarly, if you fail to include a type signature in some simple
pattern-matched function in a where clause, adding an import of another
module could make that function fail to compile (with an undeterminable
type error).
This isn't so horrid as C++, but also isn't nearly so beautiful as Haskell.
Admittedly, adding a type signature will make a function verifiably
correct, and avoid any of these ambiguities, but we really like type
inference, and it'd be a shame to introduce code that makes type inference
less powerful.
True, one could always forbid people to use the View class, but that sort
of defeats the purpose, and starts sounding once more like C++, where there
are language features that shouldn't be used... but just imagine what
would happen to your type checking, if someone decided that it'd be clever
to use [a] as a view for Integer using a Peano representation? Yikes! (Or
Integer as a view for [a] describing the length?)
Admittedly, havoc would also be wreaked if someone declared [a] to be an
instance of Num, and that's the risk one takes when using type
classes... but that's why it's nice that there is a convenient way to write
code that *doesn't* use type classes.
--
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] Re: HDBC or HSQL
On 7/30/07, John Goerzen [EMAIL PROTECTED] wrote: On 2007-07-25, david48 [EMAIL PROTECTED] wrote: HDBC Supports Mysql only through ODBC :( This is true, unless some MySQL hacker would like to contribute a native module. I don't use MySQL myself and haven't had the time to write an interface to it. I'd be glad to do it but I'm a newbie in haskell, so I don't know where to get started. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] View patterns in GHC: Request?for?feedback
On Tue, Jul 31, 2007 at 04:04:17PM -0700, Stefan O'Rear wrote:
On Tue, Jul 31, 2007 at 03:31:54PM -0700, David Roundy wrote:
On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
ChrisK [EMAIL PROTECTED] writes:
And the readability is destroyed because you cannot do any type
inference in
your head.
If you see
{
Matrix m = ;
Matrix x = m * y;
...;
}
Then you know very little about the possible types of y
since can only conclude that:
[snippage] This is all very horrid, but as far as I can tell
what I was proposing wouldn't lead to such a mess, except
possibly via defaulting, which, as the least important
aspect of the idea could easily be abandoned.
What your suggestion would do would be to make the type inferred for every
pattern-matched function polymorphic, which means that in order to
determine the correctness of a function you'd need to examine all other
modules. Similarly, if you fail to include a type signature in some simple
pattern-matched function in a where clause, adding an import of another
module could make that function fail to compile (with an undeterminable
type error).
Excuse me? One of the most critical properties of type classes is that
adding new instances can never make old code that uses old instances
stop compiling; the worst you could get is a definition conflict.
I see that I was wrong. I was thinking of something like
foo :: C a = Int - a
bar :: C a = a - Int
baz :: Int - Int
baz = bar . foo
and that this would compile if there was only one instance of class C. But
I see that in fact it will fail to compile regardless, which makes sense.
--
David Roundy
Department of Physics
Oregon State University
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: Re: Re[4]: [Haskell-cafe] i need wxHaskell compiled for ghc 6.6.1 on Windows
Oops, I made mistake to send this mail only for Bulat. --- Forwarded message --- From: shelarcy [EMAIL PROTECTED] To: Bulat Ziganshin [EMAIL PROTECTED] Subject: Re: Re[4]: [Haskell-cafe] i need wxHaskell compiled for ghc 6.6.1 on Windows Date: Wed, 01 Aug 2007 09:03:52 +0900 Hello Bulat, On Wed, 25 Jul 2007 22:18:58 +0900, Bulat Ziganshin [EMAIL PROTECTED] wrote: Tuesday, July 24, 2007, 2:32:01 AM, you wrote: So I put newer Windows binary on my project's file space. http://sourceforge.net/project/showfiles.php?group_id=168626 thank you very much!!! now i'm really happy - it works without any problems. the only question that remains - does this version supports unicode? Yes. Current darcs repository version support only unicode enabled version. http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/198 So you can use UTF-8 string in your program. Best Regards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Knuth Morris Pratt for Lazy Bytestrings implementation
Now I wonder what that 7MB file might be? :-) We (team TNT) implemented KMP over lazy bytestrings as part of our icfp 2007 contest entry. As I remember, for the DNA evaluator it gave modest speed improvements over more naïve searching. Our implementation was based upon this blog post: http://twan.home.fmf.nl/blog/ Tim I've implemented KMP string searching for lazy bytestrings, and I'd like some help improving the performance of the code. I'd also like to know if it doesn't look correct - I've tested it pretty extensively but you never know ... I've been testing on a 7 MB file, where the search sequence is not found. Using strict byestrings, lazy bytestrings, and regular strings, I've found my algorithm is about twice as slow as the strict version. Surprisingly, the strict version is a little bit *slower* than the regular strings version. Thanks for any comments or help! Justin ___ 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] Knuth Morris Pratt for Lazy Bytestrings implementation
On Wed, 2007-08-01 at 01:51 +0100, Tim Docker wrote: Now I wonder what that 7MB file might be? :-) We (team TNT) implemented KMP over lazy bytestrings as part of our icfp 2007 contest entry. As I remember, for the DNA evaluator it gave modest speed improvements over more naïve searching. Our implementation was based upon this blog post: http://twan.home.fmf.nl/blog/ If anyone can come up with a fast search implementation for strict and/or lazy ByteStrings I'll include it in the bytestring package. The current Data.ByteString search uses a rather under-optimised KMP implementation. I say under-optimised as I think it typically gets beaten by a naive search. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Backpatching
Hi All, One of the things I've been working on lately is some ASN.1 stuff.One of the first things I wrote in Haskell was an ASN.1 parser. It only worked for a subset, and I'm revisiting it to make it handle a larger subset. One of the things that gets messy is that in lots of places you can put either a thing or a reference to a thing (i.e. the name of a thing defined elsewhere). For example, consider the production: NamedNumber ::= identifier ( SignedNumber ) | identifier ( DefinedValue ) If we ignore the second alternative, the natural translation into a Parsec parser would look like: namedNumber = do name - identifier val - parens signedNumber return (name, val) Now to handle the second alternative is easy enough: namedNumber = do name - identifier val - parens (fmap Left signedNumber | fmap Right definedValue) return (name, val) however because names can be used before they are defined the result typegoes from being type NamedNumber = (Name,Integer) to type NamedNumber = (Name,Either Integer Name) Nothing too terrible so far. The messiness comes in when you considerthe number of places that you have to replace a type 't' with (Either t Name). I'd really like to avoid having to do this. If I were using Prolog, I could finesse the problem by introducing afree variable and filling it in when I come across the definition[*]. Logic variable backpatching. :-) So one possibility would be to return a closure: ... return $ \bindings - (name,resolve val bindings) resolve :: (Either t Name) - Map Name t - t or something like that. Then when you get to the end, you apply the bindings and voila, out pops the simple type. I'm not sure this will work quite as well as it sounds. This sounds like a common problem type. Is there a well known solution to this sort of problem? cheers, Tom [*] And then at the end use var/1 to look for undefined names. Urk. Actually, if I were using Prolog in the way most Prolog programmers use it, I wouldn't be thinking about the types. -- Dr Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] OS swapping and haskell data structures
If you create a Data.Map or Data.Set larger than fits in physical memory, will OS level swapping enable your app to behave reasonably or will things just die catastrophically as you hit a memory limit? -Alex- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[6]: [Haskell-cafe] i need wxHaskell compiled for ghc 6.6.1 on Windows
Hello shelarcy, Wednesday, August 1, 2007, 4:03:52 AM, you wrote: problems. the only question that remains - does this version supports unicode? Yes. Current darcs repository version support only unicode enabled version. great, it's all what i need. but i'm still curious about other features enabled when building this package. can i see config.gcc or build.cfg or setup.h or any other file that shows feature list? also it will be useful to include such file with the next builds of wxHaskell -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS swapping and haskell data structures
On Tue, Jul 31, 2007 at 10:45:56PM -0700, Alex Jacobson wrote:
If you create a Data.Map or Data.Set larger than fits in physical memory,
will OS level swapping enable your app to behave reasonably or will things
just die catastrophically as you hit a memory limit?
Data.{Set,Map} uses balanced binary trees. So if you have a 1 billion
element data set which is so large that no significant fraction of it
fits into cache, you can expect to access a random element in ~9 seeks,
which is less than a second... good enough?
This is a lot worse than it could be because memory access is too
transparent. When GHC triggers a page fault, the Right Thing to do is
for Linux to somehow put *that haskell thread* to sleep; but instead it
will put the entire capability (or your whole program on the
non-threading rts) to sleep.
Linux's filesystems (which use various kinds of trees internally) avoid
this issue by using asynchronous IO requests, but that's not an option
for VM since there's only so much room for callbacks in a MOV
instruction!
There is much fertile territory for OS design space exploration here!
Stefan
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
